More Related Content
Similar to Configuration management, what's it about
Similar to Configuration management, what's it about (20)
Recently uploaded
Recently uploaded (20)
Configuration management, what's it about
- 2. Configuration Management Defined It’s all about changes
- 3. “Configuration Management (CM) is the practice of handling changes systematically so that a system maintains its integrity over time.”
- 4. CM is about change control … change is inevitable!! And you’ll have to deal with it! Unless you develop a system in a first-time-right effort …
- 5. CM is about change control “We’d better put that in a remote IO …” “I really need an extra ….” Changing customer requirements: Changes in design choices: Correction of errors: “Bugger! I’ve forgotten to put in a …”
- 6. CM is about change control Information
- 7. PRODUCT INFORMATION CM is about change control PROJECT INFORMATION
- 8. CM is about change control • drawings • designs • test reports • datasheets • … • schedules • correspondence • progress reports • contracts • … PRODUCT INFORMATION STOPPROJECT INFORMATION
- 9. CM is about change control PROJECT INFORMATION PRODUCT INFORMATION Issue 1 Issue 21 Issue 74 Issue 143 Issue 289 Doc.A.v1 Doc.A.v2 Doc.A.v3Doc.B.v1 Doc.B.v2
- 10. CM is about change control … a change will result in a change somewhere in your information flow… Since your system development process is, for a large part, actually an information processing process… It will emerge as a new ‘version’ of some document, purchase order, software code … even when you’re not working with version control at all…
- 11. CM is about change control Doc.A.v1 Doc.A.v2 Doc.A.v3 Doc.B.v1 Doc.B.v2 Version Control is part of CM
- 12. CM is about change control Imagine taking ‘snapshots’ of all documents at certain points during the development… It is up to you to decide when you take these snapshots. Depends on what moments you’d like to capture and keep for later
- 13. CM is about change control CM v1 Doc.A.v1 Doc.B.v1 CM v2 Doc.A.v2 Doc.B.v1 CM v3 Doc.A.v3 Doc.B.v1 CM v4 Doc.A.v3 Doc.B.v2
- 14. CM is about change control CM v1 Doc.A.v1 Doc.B.v1 CM v2 Doc.A.v2 Doc.B.v1 CM v3 Doc.A.v3 Doc.B.v1 CM v4 Doc.A.v3 Doc.B.v2 Requirements Module test FAT As built
- 15. CM is about change control • What information is affected? • How will it affect the final delivery? • How to make the change? • Who will make the change? • Who needs to know? • How to inform them? How to deal with change?
- 16. “CM implements the policies, procedures, techniques, and tools that are required to manage, evaluate proposed changes, track the status of changes, and to maintain an inventory of system and support documents as the system changes.” CM is about change control
- 17. Issue handling (examples) CM is about change control
- 18. CM v1 Doc.A.v1 Doc.B.v1 CM v2 Doc.A.v2 Doc.B.v1 CM v3 Doc.A.v3 Doc.B.v1 CM v4 Doc.A.v3 Doc.B.v2 Requirements Module test FAT As built Issue 1 Issue 21 Issue 74 Issue 143 Issue 289 CM is about change control
- 19. Why you need CM … any work that is done based on unreliable information is likely to cost you money and/or time! Since your system development process is, for a large part, actually an information processing process…
- 20. You need reliable information when someone asks: • “Can I have the ‘as build’ version of …?” • “Where’s that sensor and actor list?” • “Who has been working on that software?!” • “Are you sure about that nominal motor current?” • “Have all revisions been processed?” • “Is this Technical Construction File complete?” • “Who decided to put in a different type of contactor?” Why you need CM
- 22. How much CM do you need?
- 23. CM needs to be tailored to … … your company
- 24. … your type of business CM needs to be tailored to …
- 25. … your product CM needs to be tailored to …
- 26. … your project !! CM needs to be tailored to …
- 27. across disciplines CM maturity levels issue tracking versioning archiving Storing one single version: “the most recent one” Storing successive versions • Date-time-stamp • author • Version # • change note Track issues and relate them to new versions of documents Full blown CM
- 28. CM summary
Editor's Notes
- Changes come from: Changing customer requirements “I really need an extra ….” Changes in design choices “We’d better put that in a remote IO …” Correction of errors “Bugger! I’ve forgotten to put in a …”
- Changes come from: Changing customer requirements “I really need an extra ….” Changes in design choices “We’d better put that in a remote IO …” Correction of errors “Bugger! I’ve forgotten to put in a …”
- Since your system development process is, for a large part, actually an information processing process… … a change will result in a change somewhere in your information flow… It will emerge as a new ‘version’ of some document, purchase order, software code … even when you’re not working with version control at all…
- One can distinguish product information (technical) and project information (management)
- One can distinguish product information (technical) and project information (management) While the project ends, the product’s lifecycle has just began
- During the system development life cycle issues will trigger changes which in turn will result in new versions of all kinds of documents. You might, or might not, archive these versions; but they do, or have, existed for sure.
- Archiving these different versions in a structured manner is what we call ‘version control’, but not yet configuration management…
- Imagine taking ‘snapshots’ of all documents at certain points during the development… It is up to you to decide when you take these snapshots
- Some examples of issue handling, but … you have to draw your own…
- If you can proof that you’re able to manage your information, you can proof you’re able to manage your business process CM is about reliability!
- Unless all your projects follow the same process. This is what makes CM especially challenging for those who have a lot variation in type of projects. One might consider a few template’s, blueprints, for different type of projects. A simple form of CM for small projects. A full blown CM for large, tender, projects.