1 / 52

Software Configuration Management

Software Configuration Management. Sudipto Ghosh CS 406 Fall 99 October 26, 1999 Revised: Aditya Mathur Fall 2001. Learning objectives. What are versions, releases, variations? What is version control? What is configuration management? Need for configuration management

sandro
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 Sudipto Ghosh CS 406 Fall 99 October 26, 1999 Revised: Aditya Mathur Fall 2001

  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 CS 406 Testing

  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? CS 406 Testing

  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 CS 406 Testing

  5. Revisions - why? • Corrective maintenance • fix faults • Perfective maintenance • write new modules • change existing modules • Adaptive maintenance • change modules CS 406 Testing

  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? CS 406 Testing

  7. Why should we keep versions? • Revision n+1 is not necessarily more correct 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. CS 406 Testing

  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 CS 406 Testing

  9. Configuration management • Multiple versions have to be managed • Need a CASE tool for configuration control • Many tools available commercially CS 406 Testing

  10. Forms of code • Source code • Object code • Executable load image Run-time routine Executable load image Object File 1 Object File 2 Object File n • • • • • • Source File 1 Source File 2 Source File n CS 406 Testing

  11. 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? • Bad method • Compile all versions and compare object code with the object code that went into the executable • Good method • Use version control CS 406 Testing

  12. 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 CS 406 Testing

  13. Multiple revisions acknowledgeMessage / 1 acknowledgeMessage / 2 acknowledgeMessage / 3 acknowledgeMessage / 4 Revisions CS 406 Testing

  14. 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 CS 406 Testing

  15. Version control for variations printerDriver (inkjet) / 2 printerDriver (laser) / 12 printerDriver (laser) / 13 printerDriver (laser) / 14 CS 406 Testing

  16. 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 • Data and time of construction CS 406 Testing

  17. 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? CS 406 Testing

  18. 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? CS 406 Testing

  19. 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 CS 406 Testing

  20. Configuration control during maintenance • Suppose 2 programmers, P1 and P2, are assigned 2 different fault reports. • Both faults 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 CS 406 Testing

  21. 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 CS 406 Testing

  22. 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. CS 406 Testing

  23. 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 CS 406 Testing

  24. Configuration Management Configuration Management Configuration Identification Configuration Audits Configuration Control / Change Management Configuration Status Accounting CS 406 Testing

  25. 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 • Change management: • Control changes to a product and its configuration documentation CS 406 Testing

  26. Configuration management terms • Configuration Status Accounting: • Provide status and information about a product and its configuration documentation • Configuration Audits: • Verify consistency of configuration CS 406 Testing

  27. 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 CS 406 Testing

  28. 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 that is explicitly placed under configuration control • Regarded as a basic unit of modification CS 406 Testing

  29. 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 CS 406 Testing

  30. Identification of SCI • Requirements SCI - requirements document or chapters / paragraphs of document. • Design SCI - usually design document • Code level - multiple SCI’s • Each separately compileable module • Each file consisting of modules CS 406 Testing

  31. 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. CS 406 Testing

  32. 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? CS 406 Testing

  33. 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. CS 406 Testing

  34. Change control (contd.) • If SCI is considered stable enough, it is given to the CCB to review. • 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 under SCM. • Once in the library, it cannot be modified by anyone without permission of CCB. CS 406 Testing

  35. Change request (CR) • Reasons for a change: • requirement changes, bugs, 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 CS 406 Testing

  36. 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 CS 406 Testing

  37. 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 bugs • Description of the fault • Severity of the fault • Item suspected of being faulty • Effect of the fault CS 406 Testing

  38. Fault report (contd.) • FR also contains: • Circumstances and environment data that caused the fault to manifest itself • Possible fixes • Originator • Comments from CCB • Approved/reject • Priority • Fault fixing information • Items changed CS 406 Testing

  39. Status accounting • Incorporating changes takes time. • Mechanisms are required to record the current status of a change request or fault report. • Answer questions like: • What is the status of CR? Approved or not • What is the frequency of CR’s? • What is the average time and effort for fixing a CR? • What is the number of CRs per SCI? CS 406 Testing

  40. Status accounting (contd.) • Source of information • CR and FR • Both CR and FR have fields to show the status • Information about dates and efforts can be added to the CR’s and FR CS 406 Testing

  41. Auditing • Objective: • Determine if the specified process is being followed and whether the specified process satisfies the goals of the process • Past changes are evaluated by the auditor to determine if SCM procedures are followed. • Procedures are evaluated to ensure that SCM goals are met CS 406 Testing

  42. Auditing (contd) • While performing SCM, enough information has to be recorded such that an SCM audit can be performed. • Auditing is done periodically. • Period may be small in the beginning • Increases later after processes are well established and institutionalized. • Auditors are different from those implementing the process. CS 406 Testing

  43. Configuration management team • Maintain a correspondence among the requirements, design, implementation and tests. • Tells what changes to make in something when something else changes. • Coordinate between variations of the system, so that functionality is consistent. CS 406 Testing

  44. Things the team should know • Synchronization: When was it changed? • Identification: Who made the change? • Naming: What components were changed • Authentication: Was the change made correctly? • Authorization: Who authorized the change? • Routing: Who was notified of the change? • Cancellation: Who can cancel the request for change? • Delegation: Who is responsible for the change? • Valuation: What is the priority of the change? CS 406 Testing

  45. CASE tools for SCM • Unix version control • SCCS (Source code control system) • RCS (Revision control system) • CVS (Concurrent versions system) • Configuration control tools • CCC • PVCS • Aide-de-Camp • Microsoft Source Safe • ClearCase CS 406 Testing

  46. Build Tools • Suppose that you don’t want to have a full configuration tool. • You should at least have a Build tool with a version control tool. • Build tool assists in selecting the correct version of object-code module to be linked to form a specific version of the product. • Usually version control tools do not attach revision numbers to object versions. CS 406 Testing

  47. Unix make • Avoid unnecessary compilations • Use Unix make • Create Makefile specifying the hierarchy of source and object files. • Complex dependencies can be handled by make. • Timestamps of source file and object file compared. • Task of building object file simplified. CS 406 Testing

  48. Rational ClearCase • Meets the challenge of team-based software development • Provides • Version control • Workspace management • Build management • Process control CS 406 Testing

  49. Features of ClearCase • Acceleration of development process • Accuracy of releases • No need to change environment or tools • Powerful graphical merge tools • Automatically merge up to 32 contributors • Additive and subtractive merging • Editable synchronized windows • Transparent workspace management • No need to leave the native Windows or UNIX development environment CS 406 Testing

  50. Features of ClearCase (contd.) • Powerful version control • Not just source code control • Every object in the s/w development lifecycle • Tracks changes to files, directories • Annotated histories of source, binaries, executables, documentations, test suites, libraries, user-defined objects • Allows identification and roll-back to earlier versions. • Check-in/check-out model • Interleaved delta compression CS 406 Testing

More Related