Software Configuration Management Fernando Brito e Abreu (fba@di.fct.unl.pt) Universidade Nova de Lisboa (http://www.unl.pt) QUASAR Research Group (http://ctp.di.fct.unl.pt/QUASAR) SWEBOK: the 10 Knowledge Areas � Software Requirements � Software Design � Software Construction � Software Testing � Software Maintenance � Software Configuration Management � Software Engineering Management � Software Engineering Process � Software Engineering Tools and Methods � Software Quality Software Engineering / Fernando Brito e Abreu 2 17-May-05 1
Summary � Deliverables and Their Dependencies � What is Configuration Management ? � Identification � Organization � Modification � IEEE C.M. Model � What Must A C.M. Plan Include? � C.M. In Project Control � C.M. Tools 3 17-May-05 Software Engineering / Fernando Brito e Abreu Software Deliverables � Examples � requirements specification � design model � source code module � test battery � user manual � executable program � ... � Called “ configuration items ” in this context Software Engineering / Fernando Brito e Abreu 4 17-May-05 2
Deliverable Dependencies defA.inc defB.inc defBibS.inc defBibD.inc bibliotecaD.src moduloA.src principal.src moduloB.src bibliotecaS.src moduloA.obj moduloB.obj principal.obj bibliotecaS.ob j bibliotecaD.ob j. Deliverables are not independent from each other; bibliotecaS.slib bibliotecaD.dlib Dependencies are known but seldom executavel.exe enforced! 5 17-May-05 Software Engineering / Fernando Brito e Abreu What Is Configuration Management? � Set of mechanisms and activities that allows software deliverables to be: � identified (know which is which) � organized (know their interdependencies) � modified under control (who, why, when) � Must be a part of the development process along all phases of the life-cycle Software Engineering / Fernando Brito e Abreu 6 17-May-05 3
CM along the lifecycle (in RUP) Inception Elaboration Construction Transition Process Disciplines Business Modeling Requirements Analysis and Design I mplementation Test Deployment Supporting Disciplines Configuration Mgmt Management Environment Iter. Preliminary Iter. Iter. Iter. Iter. Iter. Iter. #m+1 Iteration(s) #1 #2 #n #n+1 #n+2 #m 7 17-May-05 Software Engineering / Fernando Brito e Abreu Identification: Naming and Versions � Unique identifiers must be assigned to: � Each deliverable � Each baseline � Each version (either of deliverables or baselines) � a deliverable id can be composed of name + version number � There must be an explicit convention for versions and deliverables identifiers. Software Engineering / Fernando Brito e Abreu 8 17-May-05 4
Organization: Baselines � Baseline - set of deliverables that define a particular version of a system or subsystem � A baseline is often called a configuration � The minimum number of deliverables in a baseline are those needed to allow: � independent reuse � corrective and evolutive maintenance 9 17-May-05 Software Engineering / Fernando Brito e Abreu Organization: Branches � Are used when a product is to be deployed in multiple target platforms � Require diachronic traceability mechanisms : � storage and manipulation of “deltas” � forward and backward reversing facilities Greek Greek : : • dia • dia - - through through • • kronos kronos - - time time Software Engineering / Fernando Brito e Abreu 10 17-May-05 5
Other examples of CM tools 11 17-May-05 Software Engineering / Fernando Brito e Abreu Modification: Check-in � First version of deliverables is built in the “sandbox” � Kids, Soldiers or Cats? � Check-in allows deliverables to be put under CM � Usually requires information on: � Who is doing / who authorized the check-in � Who validated / verified the deliverable � Which is the updated version of the related deliverables � When the check-in event took place Software Engineering / Fernando Brito e Abreu 12 17-May-05 6
13 17-May-05 Software Engineering / Fernando Brito e Abreu Modification: Check-out � Check-out puts copies of deliverables in the sandbox (they are supposed to be checked-in again ...) � Usually requires information on: � Who did the check-out � Who authorized the check-out � Why is the check-out required � Who will be in charge of the deliverable � When the check-out event took place � “Read-only” check-out should be free from the previous constraints! Software Engineering / Fernando Brito e Abreu 14 17-May-05 7
Modification: Check-out (continued) � Checking-out an already checked-out deliverable � optimistic strategy : probability of this occurrence is small, so the deliverable is locked upon the first request � the second partner must wait until the lock is released (when the first checks-in the required deliverable) � this strategy is rigid but simple � pessimistic strategy : probability of this occurrence is not neglectable, so we must allow it � merging conflicts must be solved later � flexible but more complex � in both cases, partners should be notified: email is often used to do that when a partner is not logged on 15 17-May-05 Software Engineering / Fernando Brito e Abreu Modification: Conflict resolution � When two or more instances of the same deliverable are checked-out, a merging mechanism is required upon next check-in: � Differences must be identified and conciliated � Most differences can be merged automatically (no conflicts) � Some conflicts request human intervention � The same happens when we want to collapse two, or more, branches Software Engineering / Fernando Brito e Abreu 16 17-May-05 8
Modification: Authorization � Responsible must have experience and authority! � Modifications are only authorized with appropriate fundament, usually through an appropriate form - request for modifications or improvements (RFI) . � These forms should be distributed to final users � Users should be notified of the request follow-up (acceptation, postponement, refusal) � An Intranet can be used to submit requests [Monteiro99] � CM responsible should only allow a definitive change to a baseline if all interrelated deliverables are adequately modified (synchronic traceability enforcement) 17 17-May-05 Software Engineering / Fernando Brito e Abreu Modification: Request for Improvements Checklist � Which is the effort and cost required? � How complex is the change and what is the technological risk? � Are the components to be changed highly coupled with others? � What is likely to happen if the changes is not implemented properly or not implemented at all? � What is the relative importance of this change when compared with other pending requests? � Who will make the change? Software Engineering / Fernando Brito e Abreu 18 17-May-05 9
IEEE C.M. Library Model � Deliverables, while being developed and modified frequently, are kept in the Dynamic Library (“sandbox”) � Deliverables are "promoted" to the Controlled Library, when they are ready for V&V actions and integration � Operational components or full-system versions to install in the final client are "freezed" (in the Static Library) e b l a V&V r e v n l i o e i D a t actions c f i d i o m Check-in Dynamic library Controlled Static Freezing Client (sandbox) library actions library Installation • • ANSI/IEEE Standard 1042 ANSI/IEEE Standard 1042 Check-out 19 17-May-05 Software Engineering / Fernando Brito e Abreu What Must a CM Plan / System Include? � Tasks definition and responsibilities � Selected tools, techniques and methodologies � Synchronic traceability mechanisms � dependencies � executables automatic generation � Diachronic traceability mechanisms � branches � deltas Software Engineering / Fernando Brito e Abreu 20 17-May-05 10
What Must a CM Plan / System Include? � Register and storage procedures (“check-in” and “check-out”) � Modification and distribution procedures of deliverables (who authorizes, when and how?) � Updating strategy of catalogs of deliverables � Standards for documentation (to enforce reuse) � Procedures for security copies � Procedures for delivery generation 21 17-May-05 Software Engineering / Fernando Brito e Abreu The Support of CM in Project Control � Putting modules under a configuration management mechanism, managed by staff members distinct from developers enables project management control ! � Examples: � the percentage of modules, specified in detailed design, which were finished is easily verifiable, therefore avoiding the “90% syndrome” by allowing an evaluation of the real completion compared to the previewed one; � defects and failures in modules are registered because module modification implies their check-in in configuration management, which usually must be justified. Software Engineering / Fernando Brito e Abreu 22 17-May-05 11
Recommend
More recommend
