1 / 69

Software Configuration Management

Software Configuration Management. Yashvardhan Sharma. Learning objectives. What are versions, releases, variations?. What is version control?. What is configuration management?. Need for configuration management. Steps in configuration management. Configuration management tools.

raisie
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 Yashvardhan Sharma

  2. Learning objectives • What are versions, releases, variations? • What is version control? • What is configuration management? • Need for configuration management • Steps in configuration management • Configuration management tools Software Engineering

  3. Software versions • Consider the maintenance phase • at least two versions exist • old • new • product consists of modules, so • 2 or more versions of component modules • Version control also applies to other phases – Why? Software Engineering

  4. Variations Revisions Printer driver for PC Driver for Ink-jet printer Version n+1 (fixed) Revisions and Variations Version n (with fault) Driver for Laser printer Software Engineering

  5. Revisions - why? • Corrective maintenance • fix faults • Perfective maintenance • write new modules • change existing modules • Adaptive maintenance • change modules Software Engineering

  6. Problem with revisions • Multiple versions of the same module • New version should replace the old one • Simple solution: • Just throw the old version away!!! • Will this work? Software Engineering

  7. Why should we keep versions? • Revision n+1 is not necessarily “better” than revision n • Is everyone using revision n+1? • Not necessarily • What if a site using revision n sends a fault report? • We need to maintain all the revisions for all kinds of maintenance. • Actually, all versions from the implementation phase need to be kept. Software Engineering

  8. Variations • A variation does not replace another • Variations co-exist • Examples: • Two printer drivers - laser, ink-jet for a PC supporting both laser and ink-jet printers • Same product ported to a variety of: • operating systems • hardware • Multiple revisions of each variation may exist Software Engineering

  9. Versions/variants/releases • Version An instance of a system which is functionally distinct in some way from other system instances • Variant An instance of a system which is functionally identical but non-functionally distinct from other instances of a system • Release An instance of a system which is distributed to users outside of the development team Software Engineering

  10. Configuration management • Multiple versions need to be managed • CASE tool needed for configuration control • Many commercial tools available Software Engineering

  11. Run-time routine Executable load image Object File 1 Object File 2 Object File n • • • • • • Source File 1 Source File 2 Source File n Forms of code • Source code • Object code • Executable load image Software Engineering

  12. Scenario 1 • Report from SQA: module failed on a specific set of data • How does the programmer determine which revision of which variation went into the version? • Method-1 • Compile all versions and compare object code with the object code that went into the executable • Method-2 • Use version control Software Engineering

  13. Version control for revisions • Operating system may provide version control, otherwise, use a separate tool • Maintain file name as • The file name itself • Revision number • Module that acknowledges receipt of message will have revisions: • acknowledgeMessage / 1 • acknowledgeMessage / 2 Software Engineering

  14. Multiple revisions acknowledgeMessage / 1 acknowledgeMessage / 2 acknowledgeMessage / 3 acknowledgeMessage / 4 Revisions Software Engineering

  15. Version control for variations • Notation • Have a basic file name • Followed by a variation name in parenthesis • Printer driver for inkjet and laser • printerDriver (inkjet) • printerDriver (laser) • Multiple versions of each variation • printerDriver (laser) / 12 • printerDriver (laser) / 13 • printerDriver (inkjet) / 2 Software Engineering

  16. Version control for variations printerDriver (inkjet) / 2 printerDriver (laser) / 12 printerDriver (laser) / 13 printerDriver (laser) / 14 Software Engineering

  17. Managing multiple versions • Use a version control tool • Keep a detailed record or derivation of every version of the product • Derivation contains: • Name of each source code element, including the variation and revision • Versions of source code compilers and linker • Name of person who constructed the product • Date and time of construction Software Engineering

  18. Is maintaining multiple revisions enough? • No, problems with maintaining variations • Often a fault occurs in a variation and may have to be fixed for all the variations, in the same way. • Just store one variation, printDriver(inkjet), other variations are stored in terms of the list of changes to be applied to the original to get that variation – delta • For n variations, store • one variation • n-1 deltas • Can there be problems with deltas? Software Engineering

  19. Problem with deltas • What if the main version is lost or corrupted? • More important: • Sometimes it is difficult to express each variation as a transformation from the main version • What about conditional compilation as an alternative to deltas? Software Engineering

  20. More on configuration control • Configuration control can automatically manage different variations and do a lot more. • Handle problems caused by • Development and • Maintenance by teams Software Engineering

  21. Configuration control during maintenance • Suppose programmers P1 and P2, are assigned two different fault reports. • Both faults are localized to the same module. • Each programmer makes a copy of the module mMod / 16 and starts fixing the fault • P1 fixes the fault first and replaces the module with mMod / 17. • Then P2 fixes the fault and installs mMod / 18 Software Engineering

  22. Problems in previous example • All changes made by the first programmer are lost! • Only one user should be allowed to change a module at a time Software Engineering

  23. Configuration Management ... During the development of software, change must be managed and controlled in order to improve quality and reduce error. Software Configuration Management (SCM) is an umbrella activity that is applied throughout the software process Software Engineering

  24. Configuration Management ... • Software Configuration Management (SCM) - is the art of identifying, organizing and controlling modifications to the software being built by a development team Software Engineering

  25. Configuration Management ... Software Configuration Management is a quality assurance activity that manages change throughout the software process Software Engineering

  26. Formal definition (IEEE) SCM is the process of identifying and defining the items in the system, controlling the change of these items throughout their life cycle, recording and reporting the status of items and change requests and verifying the completeness and correctness of the items. Software Engineering

  27. Configuration management • Pfleeger: • It is used throughout the life cycle • It is a set of procedures that track • Requirements that define what the system should do • Design modules that are generated from the requirements • Program code that implements the design • Tests that verify the functionality of the system • Documents that describe the system • Provides threads that tie parts of system together • Coordinate development activities Software Engineering

  28. Configuration Identification Configuration Audits Configuration Control / Change Management Configuration Status Accounting Configuration Management Configuration Management Software Engineering

  29. Configuration management terms • Configuration: • Functional and Physical characteristics of hardware and software as set forth in technical documentation or achieved in a product • Configuration Identification: • Define the product and its configuration documentation identification • Configuration Item • Information output of the Software Process • Change management: • Control changes to a product and its configuration documentation Software Engineering

  30. Configuration management terms • Configuration Status Accounting: • Provide status and information about a product and its configuration documentation • Configuration Audits: • Verify consistency of configuration Software Engineering

  31. Configuration identification • Agree on a basis for change • i.e. to what are changes applied? • Requires that baselines are established • Baselines can be defined for many phases • Functional or requirements baseline • Design baseline • Product or system baseline • Makes sense to establish baseline when product is relatively stable Software Engineering

  32. Configuration identification • The current version is “frozen” • No one may make changes to the frozen version. • A baseline can consist of many Software Configuration Items (SCI) • Documents or artifacts explicitly placed under configuration control • Regarded as a basic unit of modification • IEEE Definition- baseline • A Specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. Software Engineering

  33. Baselines Software Engineering

  34. Configuration Management ... Information output of the Software Process - Software Configuration Items ( SCI ): • computer programs • source • executable • documents describing the programs • technical manual • users manual • data • within program • external Software Engineering

  35. Configuration Management ... • As the Software Process progresses more and more SCI’s are spawned creating a hierarchy of information • Change may occur at any time for any reason Software Engineering

  36. Configuration identification (contd) • How do you get a consistent system from the SCI’s? • when SCI’s may be getting changed • when there are many versions • Makefiles may be used Software Engineering

  37. Identification of SCI • Requirements SCI - requirements document or chapters / paragraphs of document. • Design SCI - usually design document • Code level - multiple SCI’s • Each separately compile able module • Each file consisting of modules Software Engineering

  38. Dependencies of SCI’s • One SCI X may “depend” on another SCI Y, if a change in Y might require a change in X for X to remain correct or for baselines to be consistent. • Change request may require changes to some other SCIs. Software Engineering

  39. SCI’s System Specification Project Plan Requirements Specs graphical models process specs prototypes maths specs Prelim User Manual Source Code Listing Design Spec data design architectural design module design interface design object descriptions Test Specs test plan and procedures test cases and recorded results Configuration Management ... Software Engineering

  40. SCI’s … Operation and Installation Manuals Executable Program module executable code linked modules Database Description schema and file structure initial content User Manual Maintenance Documents problem reports maintenance requests engineering change orders Standards/Procedures Software Tools editors compilers CASE tools Configuration Management ... Software Engineering

  41. Configuration Management ... SCI’s are organized to form a database of Configuration Objects with: • name • attributes • relationships and are either: • basic objects or aggregate objects (components) Software Engineering

  42. Configuration Management ... If a change is made to one configuration object it is possible to determine which other Configuration Objects are affected Software Engineering

  43. Configuration Management ... Version Control Configuration Objects are baselined • before object is baselined it changes many times • after baseline all modifications are controlled • at baseline it becomes Version 1.0 Subsequent changes become new versions • > Version 1.1 -> Version 1.1.1 then 1.1.2 • > Version 1.2 etc. • >Version 2.0 etc. Software Engineering

  44. Configuration Management ... Version Control combines procedures and tools to manage different versions of configuration objects whereas Configuration Management allows a user to specify alternative configurations of a system through the selection of appropriate versions Software Engineering

  45. Maintaining modules • One version is frozen as the baseline. • Programmer takes a copy, makes changes and tests. • The new version is installed, thereby modifying the baseline. • The previous version is not altered, but is still retained. • How does this fix the problem of two programmers trying to work on fixing two faults? Software Engineering

  46. Change control • SCI’s have been identified and dependencies are understood. • Decisions regarding change are taken by the configuration control board (CCB) • If an SCI is under development and not visible to other SCI’s, it is in the working state. • That SCI is not under SCM and can be changed. Software Engineering

  47. Change control (contd.) • An SCI is given to the CCB for review once it is considered stable. • It is considered as frozen and any changes made privately by the developer are not recognized. • It is entered in a library, after which it is formally placed under SCM. • Once in the library, it cannot be modified by anyone without the approval of the CCB. Software Engineering

  48. Change request (CR) • Reasons for a change: • requirement changes, errors, enhancements… • What does the CR contain? • First part • Description • Reason for change • Priority of the change • The SCI’s that are affected • Second part (filled by CCB): • Decision taken by the CCB (approved/not) • Actions needed to implement the change Software Engineering

  49. Change request (contd.) • What does it contain? • Third part (filled by the implementer): • Status of change implementation • Change log to facilitate undoing of the change • CR has a unique number for reference • Evaluation of CR by considering • Effect of change on cost, schedule • Quality of project • Benefits • Evaluation may be recorded on the CR itself Software Engineering

  50. Fault report (FR) • Common reason for a CR is the discovery of a bug or a problem • These are frequently on a different kind of form (FR) - High priority CR-- Assigned unique ID • FR also tracks the status of known errors • Description of the fault • Severity of the fault • Item suspected of being faulty • Effect of the fault Software Engineering

More Related