SlideShare a Scribd company logo
Lessons Learned in Configuration Management CMMI Made Practical 29 th  April 2009 - London Eric Mariacher – Embedded Software Manager at Logitech
Configuration management definition IEEE Std-729-1983  “ Configuration is the process of identifying and defining the items in the system, controlling the change of these items throughout their lifecycle, recording and reporting the status of items and change requests, and verifying the completeness and correctness of items”  Identification  describes the system structure, the nature of its elements, their identity, and gives access to each item version  Control  organises versions and changes to system items while keeping coherency and consistency on the complete system. Files, Releases and Bugs Management
Agenda Configuration Management Questions Step 0:  no file, nor change management tools Step 1: file management tool only Step 2:  loosely linked file and change management tools Step 3:  strongly linked file and change management tools,  file  oriented release building Step 4:  strongly linked file and change management tools,  change request  oriented release building How CM steps help CMMi « compliance »
Basic File Management questions  What change did you make in this file? Which version of which files are included in this release?
Basic Change Requests Management questions  Have we finished implementing this change / bug fix? Which bug corrections are included in this release?
Not so Basic Configuration Management questions  Why was this change made in this file? Why do we release a new software version? Are we sure we did not forget to integrate a file in this release? Are we sure not to wrongly integrate a file that was not intended to be released yet?
Step 0:  no file, nor change management tools Files back-ups and releases/baselines are managed manually. Change Requests are manually managed. Someone else working low This is another short description Feature request CR2 description myself open high This is a short description bug CR1 description Owner Status Priority description type title
Step 0: Answering questions Basic File Management What change did you make in this file? Which version of which files are included in this release? Basic Change Request Management Have we finished implementing this change / bug fix? Which bug corrections are included in this release? Not so Basic Configuration Management   Why was this change made in this file? Why do we release a new software version? Are we sure we did not forget to integrate a file in this release?
Step 1: file management tool only Handle file versioning: ability to retrieve older  versions. Basic release/baseline generation: each release is made of  a list of file versions . Release 1 File1 v1 File2 v1 File3 v2 Release 2 File1  v2 File2 v1 File3  v3
Step 1: Answering questions Basic File Management What change did you make in this file? Which version of which files are included in this release? Basic Change Request Management Have we finished implementing this change / bug fix? Which bug corrections are included in this release? Not so Basic Configuration Management   Why was this change made in this file? Why do we release a new software version? Are we sure we did not forget to integrate a file in this release?
Step 2:  loosely linked file and change management tools Release note: list of file versions  as done in step 1. list of change requests  based on completion date. Release 1 File1 v1 File2 v1 File3 v2 Release 2 File1  v2 File2 v1 File3  v3 Bug 1 Bug 2 Bug 3
Step 2: Answering questions Basic File Management What change did you make in this file? Which version of which files are included in this release? Basic Change Request Management Have we finished implementing this change / bug fix? Which bug corrections are included in this release? Not so Basic Configuration Management   Why was this change made in this file? Why do we release a new software version? Are we sure we did not forget to integrate a file in this release?
Step 3:  strongly linked file and change management tools Each time a file check-in is done… Bug 1 File1 v1 File management tool  forces … Developer to motivate the check-in i.e.  link  the check-in with a change request File1  v2 Check-in
Step 3:  file oriented release building Release note: list of file versions  as done in step 1. list of change requests  based on completion date  and modified files versions . Bug 1 Bug 2 Bug 3 Release 1 File1 v1 File2 v1 File3 v2 Release 2 File1  v2 File2 v1 File3  v3
Step 3: Answering questions Basic File Management What change did you make in this file? Which version of which files are included in this release? Basic Change Request Management Have we finished implementing this change / bug fix? Which bug corrections are included in this release? Not so Basic Configuration Management   Why was this change made in this file? Why do we release a new software version? Are we sure we did not forget to integrate a file in this release?
Step 4:  strongly linked file and change management tools Each time a file check-in is done… Bug 1 File1 v1 File management tool  forces … Developer to motivate the check-in i.e.  link  the check-in with a change request File1  v2 Check-in
Step 4:  change request oriented release building Release note is a list of change requests. list of files versions based on integrated change requests. Release 1 File1 v1 File2 v1 File3 v2 Release 2 File1  v2 File2 v1 File3  v3 Bug 1 Bug 2 Bug 3
Step 4: Answering questions Basic File Management What change did you make in this file? Which version of which files are included in this release? Basic Change Request Management Have we finished implementing this change / bug fix? Which bug corrections are included in this release? Not so Basic Configuration Management   Why was this change made in this file? Why do we release a new software version? Are we sure we did not forget to integrate a file in this release? Are we sure not to wrongly integrate a file that was not intended to be released yet?
Step 4:  change request oriented release building Are we sure we did not forget to integrate a file in this release? Are we sure not to wrongly integrate a file that was not intended to be released yet? Release X FileA v1 FileB v1 FileC v2 FileA  v2 FileC  v3 Bug A Bug B Bug C Bug D
Size of involved teams  : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) 3 :  strongly linked tools, file oriented release building 4 :  strongly linked tools, change request oriented release building 2 :  loosely linked file and change management tools 1 : file management only 0 : no file, nor change management tester Change Control developer Files & Bugs Step
Measuring vs CMMi How the level of integration between file and bug management tools helps measuring Configuration Management practices vs CMMi
CMMI: Configuration Management Process Area SG 1 Establish Baselines SP 1.3 Create or Release Baselines SG 2 Track and Control Changes SP 2.1 Track Change Requests SP 2.2 Control changes to the configuration items SG 3 Integrity of baselines is established and maintained SP 3.1 Establish and maintain records describing configuration items SP 3.2 Perform configuration audits to maintain integrity of the configuration baselines
SG 1 Establish Baselines SP 1.3 Create or Release Baselines SubPractice 2.  Create or release baselines only using  the configuration management system  SubPractice 3.  Document the set of configuration items that are contained in a baseline  Use a Configuration Management tool (step 1) Release Notes (steps 0-3 but easier/more reliable with step 4)
SG 2 Track and Control Changes SP 2.1 Track Change Requests SubPractice 2.  Analyze the impact of changes proposed SubPractice 3.  Review change requests and get agreement from stakeholders Link file check-ins with bugs (step 3) List of bugs to integrate and impacts (step 3) A new role : CCB (step 4)
SG 2 Track and Control Changes SP 2.2 Control changes to the configuration items SubPractice 3.  do Check ins and check outs in a manner that maintains the integrity of the configuration items SubPractice 4.  Perform reviews to ensure that changes have not caused unintended effects on the baselines SubPractice 5.  Record changes to configuration items and the reasons for the changes as appropriate  (steps 1-3 but easier/more reliable with step 4) Integrate all the bugs and only the bugs (step 4) Link file check-ins with bugs (step 3)
SG 3 Integrity of baselines is established and maintained SP 3.1 Establish and maintain records describing configuration items Typical Work Product 1.  Revision history of configuration items Typical Work Product 5.  Differences between baselines   SP 3.2 Perform configuration audits to maintain integrity of the configuration baselines (steps 1-3 files) (step 4 bugs and files) The higher the step is achieved, the higher the  accuracy  is.
Conclusions Better integration between file and bug management tools means easier and more reliable CMMi Configuration Management measures. BUT implies « unnecessary » overhead for small projects when organization is not supporting CMMi
Size of involved teams  : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) 3 :  strongly linked tools, file oriented release building 4 :  strongly linked tools, change request oriented release building 2 :  loosely linked file and change management tools 1 : file management only 0 : no file, nor change management tester Change Control developer Files & Bugs Step
Step 5:  releases planning? Release 1 File1 v1 File2 v1 File3 v2 Release 2 File1  v2 File2 v1 File3  v3 Bug 1 CR 2 Bug 2
Product lifecycle Specify Develop Test Marketing: Doing the right thing Product QA: Checking thing is done right Management: Getting visibility Developers: Doing thing right Process QA: Checking how right thing is done
Document Flow Marketing / Users Requirements Files and Releases Test Plan Bugs Test Reports Functional Specification Configuration Management Requirement Management Test Management System/ Architecture Specification Test Execution

More Related Content

Viewers also liked (7)

PPTX
Lessons Learned For NERC CIPv5 Compliance & Configuration Change Management
EnergySec
 
PPTX
Concur vs SAP on premise Travel Management
Sven Ringling
 
DOCX
Travel management configuration steps
Abhijeet Walke
 
PPSX
Leadership In Project Management
guest484a666
 
PPT
Software Configuration Management
Chandan Chaurasia
 
PPT
Software Process Models
Jesse Manalansan
 
PDF
The Perfect Travel and Expense Management Checklist
SAP Ariba
 
Lessons Learned For NERC CIPv5 Compliance & Configuration Change Management
EnergySec
 
Concur vs SAP on premise Travel Management
Sven Ringling
 
Travel management configuration steps
Abhijeet Walke
 
Leadership In Project Management
guest484a666
 
Software Configuration Management
Chandan Chaurasia
 
Software Process Models
Jesse Manalansan
 
The Perfect Travel and Expense Management Checklist
SAP Ariba
 

Similar to 5 STEPS OF CONFIGURATION MANAGEMENT FUNCTIONALITIES (20)

PPT
Configuration Management
Rajesh Kumar
 
PDF
Configuration Management Best Practices
TechWell
 
PPT
A Brief Introduction to Software Configuration Management
Md Mamunur Rashid
 
PPTX
Configuration management
Mohammed Abdallah
 
PPT
Bse 3105 lecture 6-configuration management
Alonzee Tash
 
PDF
software configuration management
Fáber D. Giraldo
 
PDF
SE2018_Lec 21_ Software Configuration Management (SCM)
Amr E. Mohamed
 
PPT
Voyager scm
SivaprasanthRentala1975
 
PPT
Voyager scm
sivaprasanth rentala
 
PPTX
Ch25-Software Engineering 9
Ian Sommerville
 
PPT
General SCM
Sretzer
 
PPT
Configuration Management
elliando dias
 
PPT
Software Configuration Management
elliando dias
 
PDF
Configuration Management Best Practices
TechWell
 
PDF
SE2_Lec 22_Software Configuration Management
Amr E. Mohamed
 
PPT
Software Configuration Management
elliando dias
 
PDF
Ch25modreiohgfjkl;sfda;kljfsda;jkldsaf.pdf
lam668956
 
PPTX
Software Engineering- Chapter 9.pptx
FarjanaParvin5
 
PPTX
Software Configuration Management.pptx
ShanmugapriyaSenthil3
 
Configuration Management
Rajesh Kumar
 
Configuration Management Best Practices
TechWell
 
A Brief Introduction to Software Configuration Management
Md Mamunur Rashid
 
Configuration management
Mohammed Abdallah
 
Bse 3105 lecture 6-configuration management
Alonzee Tash
 
software configuration management
Fáber D. Giraldo
 
SE2018_Lec 21_ Software Configuration Management (SCM)
Amr E. Mohamed
 
Ch25-Software Engineering 9
Ian Sommerville
 
General SCM
Sretzer
 
Configuration Management
elliando dias
 
Software Configuration Management
elliando dias
 
Configuration Management Best Practices
TechWell
 
SE2_Lec 22_Software Configuration Management
Amr E. Mohamed
 
Software Configuration Management
elliando dias
 
Ch25modreiohgfjkl;sfda;kljfsda;jkldsaf.pdf
lam668956
 
Software Engineering- Chapter 9.pptx
FarjanaParvin5
 
Software Configuration Management.pptx
ShanmugapriyaSenthil3
 
Ad

5 STEPS OF CONFIGURATION MANAGEMENT FUNCTIONALITIES

  • 1. Lessons Learned in Configuration Management CMMI Made Practical 29 th April 2009 - London Eric Mariacher – Embedded Software Manager at Logitech
  • 2. Configuration management definition IEEE Std-729-1983 “ Configuration is the process of identifying and defining the items in the system, controlling the change of these items throughout their lifecycle, recording and reporting the status of items and change requests, and verifying the completeness and correctness of items” Identification describes the system structure, the nature of its elements, their identity, and gives access to each item version Control organises versions and changes to system items while keeping coherency and consistency on the complete system. Files, Releases and Bugs Management
  • 3. Agenda Configuration Management Questions Step 0: no file, nor change management tools Step 1: file management tool only Step 2: loosely linked file and change management tools Step 3: strongly linked file and change management tools, file oriented release building Step 4: strongly linked file and change management tools, change request oriented release building How CM steps help CMMi « compliance »
  • 4. Basic File Management questions What change did you make in this file? Which version of which files are included in this release?
  • 5. Basic Change Requests Management questions Have we finished implementing this change / bug fix? Which bug corrections are included in this release?
  • 6. Not so Basic Configuration Management questions Why was this change made in this file? Why do we release a new software version? Are we sure we did not forget to integrate a file in this release? Are we sure not to wrongly integrate a file that was not intended to be released yet?
  • 7. Step 0: no file, nor change management tools Files back-ups and releases/baselines are managed manually. Change Requests are manually managed. Someone else working low This is another short description Feature request CR2 description myself open high This is a short description bug CR1 description Owner Status Priority description type title
  • 8. Step 0: Answering questions Basic File Management What change did you make in this file? Which version of which files are included in this release? Basic Change Request Management Have we finished implementing this change / bug fix? Which bug corrections are included in this release? Not so Basic Configuration Management Why was this change made in this file? Why do we release a new software version? Are we sure we did not forget to integrate a file in this release?
  • 9. Step 1: file management tool only Handle file versioning: ability to retrieve older versions. Basic release/baseline generation: each release is made of a list of file versions . Release 1 File1 v1 File2 v1 File3 v2 Release 2 File1 v2 File2 v1 File3 v3
  • 10. Step 1: Answering questions Basic File Management What change did you make in this file? Which version of which files are included in this release? Basic Change Request Management Have we finished implementing this change / bug fix? Which bug corrections are included in this release? Not so Basic Configuration Management Why was this change made in this file? Why do we release a new software version? Are we sure we did not forget to integrate a file in this release?
  • 11. Step 2: loosely linked file and change management tools Release note: list of file versions as done in step 1. list of change requests based on completion date. Release 1 File1 v1 File2 v1 File3 v2 Release 2 File1 v2 File2 v1 File3 v3 Bug 1 Bug 2 Bug 3
  • 12. Step 2: Answering questions Basic File Management What change did you make in this file? Which version of which files are included in this release? Basic Change Request Management Have we finished implementing this change / bug fix? Which bug corrections are included in this release? Not so Basic Configuration Management Why was this change made in this file? Why do we release a new software version? Are we sure we did not forget to integrate a file in this release?
  • 13. Step 3: strongly linked file and change management tools Each time a file check-in is done… Bug 1 File1 v1 File management tool forces … Developer to motivate the check-in i.e. link the check-in with a change request File1 v2 Check-in
  • 14. Step 3: file oriented release building Release note: list of file versions as done in step 1. list of change requests based on completion date and modified files versions . Bug 1 Bug 2 Bug 3 Release 1 File1 v1 File2 v1 File3 v2 Release 2 File1 v2 File2 v1 File3 v3
  • 15. Step 3: Answering questions Basic File Management What change did you make in this file? Which version of which files are included in this release? Basic Change Request Management Have we finished implementing this change / bug fix? Which bug corrections are included in this release? Not so Basic Configuration Management Why was this change made in this file? Why do we release a new software version? Are we sure we did not forget to integrate a file in this release?
  • 16. Step 4: strongly linked file and change management tools Each time a file check-in is done… Bug 1 File1 v1 File management tool forces … Developer to motivate the check-in i.e. link the check-in with a change request File1 v2 Check-in
  • 17. Step 4: change request oriented release building Release note is a list of change requests. list of files versions based on integrated change requests. Release 1 File1 v1 File2 v1 File3 v2 Release 2 File1 v2 File2 v1 File3 v3 Bug 1 Bug 2 Bug 3
  • 18. Step 4: Answering questions Basic File Management What change did you make in this file? Which version of which files are included in this release? Basic Change Request Management Have we finished implementing this change / bug fix? Which bug corrections are included in this release? Not so Basic Configuration Management Why was this change made in this file? Why do we release a new software version? Are we sure we did not forget to integrate a file in this release? Are we sure not to wrongly integrate a file that was not intended to be released yet?
  • 19. Step 4: change request oriented release building Are we sure we did not forget to integrate a file in this release? Are we sure not to wrongly integrate a file that was not intended to be released yet? Release X FileA v1 FileB v1 FileC v2 FileA v2 FileC v3 Bug A Bug B Bug C Bug D
  • 20. Size of involved teams : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) 3 : strongly linked tools, file oriented release building 4 : strongly linked tools, change request oriented release building 2 : loosely linked file and change management tools 1 : file management only 0 : no file, nor change management tester Change Control developer Files & Bugs Step
  • 21. Measuring vs CMMi How the level of integration between file and bug management tools helps measuring Configuration Management practices vs CMMi
  • 22. CMMI: Configuration Management Process Area SG 1 Establish Baselines SP 1.3 Create or Release Baselines SG 2 Track and Control Changes SP 2.1 Track Change Requests SP 2.2 Control changes to the configuration items SG 3 Integrity of baselines is established and maintained SP 3.1 Establish and maintain records describing configuration items SP 3.2 Perform configuration audits to maintain integrity of the configuration baselines
  • 23. SG 1 Establish Baselines SP 1.3 Create or Release Baselines SubPractice 2. Create or release baselines only using the configuration management system SubPractice 3. Document the set of configuration items that are contained in a baseline Use a Configuration Management tool (step 1) Release Notes (steps 0-3 but easier/more reliable with step 4)
  • 24. SG 2 Track and Control Changes SP 2.1 Track Change Requests SubPractice 2. Analyze the impact of changes proposed SubPractice 3. Review change requests and get agreement from stakeholders Link file check-ins with bugs (step 3) List of bugs to integrate and impacts (step 3) A new role : CCB (step 4)
  • 25. SG 2 Track and Control Changes SP 2.2 Control changes to the configuration items SubPractice 3. do Check ins and check outs in a manner that maintains the integrity of the configuration items SubPractice 4. Perform reviews to ensure that changes have not caused unintended effects on the baselines SubPractice 5. Record changes to configuration items and the reasons for the changes as appropriate (steps 1-3 but easier/more reliable with step 4) Integrate all the bugs and only the bugs (step 4) Link file check-ins with bugs (step 3)
  • 26. SG 3 Integrity of baselines is established and maintained SP 3.1 Establish and maintain records describing configuration items Typical Work Product 1. Revision history of configuration items Typical Work Product 5. Differences between baselines SP 3.2 Perform configuration audits to maintain integrity of the configuration baselines (steps 1-3 files) (step 4 bugs and files) The higher the step is achieved, the higher the accuracy is.
  • 27. Conclusions Better integration between file and bug management tools means easier and more reliable CMMi Configuration Management measures. BUT implies « unnecessary » overhead for small projects when organization is not supporting CMMi
  • 28. Size of involved teams : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) : ) 3 : strongly linked tools, file oriented release building 4 : strongly linked tools, change request oriented release building 2 : loosely linked file and change management tools 1 : file management only 0 : no file, nor change management tester Change Control developer Files & Bugs Step
  • 29. Step 5: releases planning? Release 1 File1 v1 File2 v1 File3 v2 Release 2 File1 v2 File2 v1 File3 v3 Bug 1 CR 2 Bug 2
  • 30. Product lifecycle Specify Develop Test Marketing: Doing the right thing Product QA: Checking thing is done right Management: Getting visibility Developers: Doing thing right Process QA: Checking how right thing is done
  • 31. Document Flow Marketing / Users Requirements Files and Releases Test Plan Bugs Test Reports Functional Specification Configuration Management Requirement Management Test Management System/ Architecture Specification Test Execution

Editor's Notes

  • #18: Another abstraction level on which you can rely.
  • #19: Which version of which files are included in this release? Step4 low level answer (don’t care?) replaced by Which bug corrections are included in this release?
  • #21: Make a poll in the assistance to know at which levels engineers are working. In Bilbao 2008, most present organizations where working at level 2 and 3. CCB or Builder becomes necessary when SW becomes so complex that developers do not have enough detailed insights in all proposed change requests and their impact.
  • #26: SubPractices 3 and 4: help review only closely file/code related impacts, other impacts have to be reviewed using other tools/method i.e this helps in a very file/code centric way.
  • #27: J’ajouterais, au sujet des audits physique, que la majorité des non conformités proviennent d’activités manuelles. Plus il y a là d’activités pour lesquelles on se fie à la discipline des membres du groupe de développement, plus on trouvera de manquements à l’intégrité. Ex. : multiples librairies / répertoires pour lesquels la copie se fait manuellement ou scripts perso vs un système intégré de gestion de conf qui gère les demandes de changement, les promotions et les builds et en assure l’intégrité.
  • #28: When engineers are trained to follow these CM techniques, overhead becomes minimal.
  • #29: Conclusion slide
  • #31: Link also with tests and requirements.