1 / 19

Software Configuration Management

Software Configuration Management. William W. McMillan. 21 March 2013. Goals of Configuration Management. Know state of system. Support quality standards: Documentation Regression testing Work efficiently. Minimize frustration. Archive project versions.

melita
Download Presentation

Software Configuration Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Software Configuration Management William W. McMillan 21 March 2013

  2. Goals of Configuration Management • Know state of system. • Support quality standards: • Documentation • Regression testing • Work efficiently. • Minimize frustration. • Archive project versions. • Facilitate and control change process. • Deliver versions of system to users.

  3. Included in Configuration Management • Common code storage. • Way to check out code and check back in. • Way to merge modules changed by multiple authors. • Assignment of version identifiers. • Record of component versions included in system versions. • Facilities to build system.

  4. Included in Configuration Management • Testing and reporting facilities. • Method to request and approve changes. • Change history. • Release planning.

  5. What examples can give you give from your own background where configuration management was a challenge?

  6. Version Control • Systems are composed of many interrelated modules. • Team of software developers required. • Members work on different parts and some common parts. • Need “master” copies of modules, e.g., on server. • Developers check out modules and work in own workspace. • Check modified code back in.

  7. What tools exist to support version control?What problems can arise in their use?

  8. Version Control • Changes made might be stored as “deltas”: • List of changes made by developer. • Conflicts if more than one updated version checked in of same module. • Might have to resolve manually. • System version defined as collection of specific versions of components. E.g., • Ver. 1.0 consists of H 1.7, J 2.0, K 1.3, and imports Q2 and Q5

  9. System Builds • Version control specifies components. • Build script, configuration spec., or manifest specifies dependencies and inclusions. • Build server compiles where it needs to and assembles executable. • Target system might be different platform. • Tests run automatically. • Reports and documentation produced.

  10. What can go wrong in a system build?

  11. System Releases • New versions add functionality, • … correct errors, • … improve security, • … adapt to new environments (like OS), • … improve usability and style, • … work better with new tech (like mobile, XML), • … make use of new hardware features (like touch screen, faster external connections).

  12. Give examples of changes across versions of real software products.

  13. What risks are there in releasing a new system version?

  14. System Releases • Need careful definition of component versions included. • Define changes in deployment needs. • Consider pluses and minuses of changed styles, formats, and functions. • Users will do cost-benefit analysis before adopting. • Keep lookout for open-source or low-cost competition. • E.g., IBM-PC Pascal compiler vs. Turbo Pascal

  15. What are some rules of thumb to guide release management?

  16. Change Management • New requirement: • Function, data • Performance issue or resource consumption • Interface • Security,… • Corrected requirement: • We got something wrong in the requirements analysis. • Bug report: • We got something wrong in design or implementation.

  17. What has been your experience in submitting bug reports?

  18. Change Management • Resource intensive. (Why?) • Changes across a host of artifacts. (Which?) • If things frequently shake off the shelves when a change is made … ? • Process needs to be controlled, with defined and documented authorization chain. • Need as formal a way to request a change as possible.

  19. List some items you would include in a change request web form.Would a bug report be a different form?

More Related