Configuration Management What is CM? CM processes in practice - - PDF document

• Prof. Yoram Reich, Faculty of Engineering, Tel Aviv University, 6/15/2006, [CM overview.doc]

972-3-6407385 (tel), 972-3-6407617 (fax) email: yoram@eng.tau.ac.il, URL: http://or.eng.tau.ac.il:7777,

1

Configuration Management

฀ What is CM? ฀ CM processes in practice ฀ CM and organizational context ฀ CM technology ฀ Configurations ฀ How are versions created? ฀ Versions ฀ SCM vs. PDM CM: a process for maintaining the integrity of products as they evolve from specifications through design, development, production, maintenance, and even retrofit. Exercise the right level of CM: too little the product vanishes, too much no product is produced

• 1. CM processes in practice

CM processes: 1. Planning 2. Identification 3. Change control 4. Status accounting 5. Audits Buckley figs: 1-2: overall process 2-1: result of planning: 4 last stages

• 1. Planning

What will be managed (objects and attributes [identification, where used, when released, …])? In which format will be managed? What will be the management process? How a release is managed?

• 2. Identification

Actually going and identifying all items to be managed.

• 3. Control

Identify problem Review report

• Prof. Yoram Reich, Faculty of Engineering, Tel Aviv University, 6/15/2006, [CM overview.doc]

972-3-6407385 (tel), 972-3-6407617 (fax) email: yoram@eng.tau.ac.il, URL: http://or.eng.tau.ac.il:7777,

2 Determine cause Determine corrective action Propose changes (ECP-engineering change proposal) Evaluate changes Coordinate proposed changes Approve/disapprove proposed changes Implement approved changes

• 4. Accounting

Identify reporting needs Establish/update CM database Produce status accounting reports

• 5. Auditing

Functional configuration audits - configuration object's function (as-developed) adheres to specs. Physical configuration audits - configuration object's function (as-built) adheres to specs. Be able to track milestones and get back to a known stable configuration. Figures: Buckley figs: 2-6: example of a change to hardware caused by loading software 3-1: 4-1: 4-8: 9-1: 13-1: 14-1: 15-1: 15-2: Fruhauf (Dart) Fig 1 Table 1

• 2. CM and organizational context

CM impacts development processes. It can intervene into or impair work. Consequently, any adoption of CM must address organizational issues (e.g., be adapted to the particular

• rganization culture and practices), for example, an organization employing Rapid

Application Development (RAD). RAD: Rapid Application Development Properties: New tasks emerge Developers work closely Quick prototyping cycles

• Prof. Yoram Reich, Faculty of Engineering, Tel Aviv University, 6/15/2006, [CM overview.doc]

972-3-6407385 (tel), 972-3-6407617 (fax) email: yoram@eng.tau.ac.il, URL: http://or.eng.tau.ac.il:7777,

3 No exhaustive testing SCM seems to slow down! Solutions: Add test stages as needed Develop less formal change management (tracking, notification, and incorporation) Work offline and reconcile changes Share completed and partial changes Share work areas Don’t stop developers’ work when product is being tested.

• 3. CM technology

CM tools functionality: 1. Check-in/check-out process 2. History information 3. Version attributes 4. Possibility of finding differences between versions 5. Possibility of merging differences between two versions 6. Change and maintenance process (finding items belonging to a specific release, finding changes, ) 7. Scalability 8. Integration between CM and change request tools 9. Statistics and metrics (documentation size, # of changes, ) on saved data 10. Distributed development (multi-site development: replication of databases 11. Integration with software development environments 12. UI 13. Reliability We can use wiki technology to check these facilities.

• 4. Configuration

• Prof. Yoram Reich, Faculty of Engineering, Tel Aviv University, 6/15/2006, [CM overview.doc]

972-3-6407385 (tel), 972-3-6407617 (fax) email: yoram@eng.tau.ac.il, URL: http://or.eng.tau.ac.il:7777,

4 Figure 1: Product and its assembly configuration A product could have several configurations:

• 1. As specified
• 2. As designed
• 3. As produced
• 4. As maintained

Bridging these configurations is not an easy problem. Figure 2: Different kinds of assemblies of documents and products as exemplified by mechanical and software engineering products. The configuration can hold all available information about the product. The structuring might not be based on physical location but

• n design phases.

• Prof. Yoram Reich, Faculty of Engineering, Tel Aviv University, 6/15/2006, [CM overview.doc]

972-3-6407385 (tel), 972-3-6407617 (fax) email: yoram@eng.tau.ac.il, URL: http://or.eng.tau.ac.il:7777,

5 Figure 3: Klunover Figure Figure 4: Representations of a software product: objects and relations (compositional and dependencies) Figure 5: Compositional modeling: from models (b) to instances (d). Figure (d) allows to represent (and obtain information) specific instances.

• Prof. Yoram Reich, Faculty of Engineering, Tel Aviv University, 6/15/2006, [CM overview.doc]

972-3-6407385 (tel), 972-3-6407617 (fax) email: yoram@eng.tau.ac.il, URL: http://or.eng.tau.ac.il:7777,

6 Figure 6: Alternate and substitute relationships: Representing different variations of the product that are created during product design. Example of how configuration can be complicated and more informative. We have seen a number of examples showing that product description is composed of: Objects Relationships (compositional, dependencies) This reminds us of UML, knowledge level modeling in AI, and concept mapping. Figure 7: Different views of the product/configuration. Different people may have access to

• nly specific views.

• Prof. Yoram Reich, Faculty of Engineering, Tel Aviv University, 6/15/2006, [CM overview.doc]

972-3-6407385 (tel), 972-3-6407617 (fax) email: yoram@eng.tau.ac.il, URL: http://or.eng.tau.ac.il:7777,

7

• 5. How are versions created?

Figure 8: versions, workspaces, and configurations. Versions are created by checking-in-out from the repository. The configuration must be explicit; otherwise, there are an exponential number of options among the variations. The configuration thread records particular combinations that are defined as available configurations. Figure 9: Working with versions: version graph including offspring branches, parallel development and merging of branches. What is a version of a configuration? Different entities Same entities different versions

• Prof. Yoram Reich, Faculty of Engineering, Tel Aviv University, 6/15/2006, [CM overview.doc]

972-3-6407385 (tel), 972-3-6407617 (fax) email: yoram@eng.tau.ac.il, URL: http://or.eng.tau.ac.il:7777,

8 Different configurations Product space & version space: AND/OR graph. AND - composition of objects to system OR - alternative versions. Figure 10: Product first - composition and then alternative versions. Version first - versions and their particular compositions. Intertwined - layers of ANDs and Ors (or vice versa)

• Prof. Yoram Reich, Faculty of Engineering, Tel Aviv University, 6/15/2006, [CM overview.doc]

972-3-6407385 (tel), 972-3-6407617 (fax) email: yoram@eng.tau.ac.il, URL: http://or.eng.tau.ac.il:7777,

9 Figure 11: Example of configuration of software components: RCS: program with its parts

• versioned. At this time there is one consistent configuration shown in black.
• 6. Versioning

Versioning: Basic definitions Version - a state of an evolving object Object: anything from complete product to atomic entity Object invariants: common to all versions Version difference: delta Figure 12: Deltas: symmetric: difference in attributes, directed: sequence of modification steps. Extensional / Intensional versioning Extensional: A versioned item - a set of versions, no problem to construct versions. Intensional: for handling potentially large version space. The versioned item is defined by a set of constraints that need to be fulfilled

( ) { }

v c v V | =

. A version is constructed at the time of query. In the construction, consistency between version parts is enforced using a configurator.

• Prof. Yoram Reich, Faculty of Engineering, Tel Aviv University, 6/15/2006, [CM overview.doc]

972-3-6407385 (tel), 972-3-6407617 (fax) email: yoram@eng.tau.ac.il, URL: http://or.eng.tau.ac.il:7777,

10 Figure 13: Intensional versioning with a configurator. Using a configurator is hard. In most cases, consistent configurations are created manually (extensionally) Method of keeping track of versions: State-based: applies to extensional versioning: keeping all states. Change-based: a change is a function from V to V. Therefore, a sequence of changes can be replayed to obtain subsequent version. Objects to be managed: Atomic objects: Files CAD models Versioned controlled individually: extensional versioning Versions - one of this is the present version Variants - several options that co-exist Composite-structured objects: a collection of atomic objects and other configurations Libraries Systems CAD Assemblies Versions are constructed using selection mechanisms/rules: intentional selection # of possibilities is combinatorial -> use automated mechanisms Intentional:

• Prof. Yoram Reich, Faculty of Engineering, Tel Aviv University, 6/15/2006, [CM overview.doc]

972-3-6407385 (tel), 972-3-6407617 (fax) email: yoram@eng.tau.ac.il, URL: http://or.eng.tau.ac.il:7777,

11 Objects are represented implicitly by a base-line object and a set of operations. Representation on demand (similar to makefile, or C preprocessor) Consequences: Hard to find differences between versions since they cannot be deduced from rules. Hard to guarantee consistency (e.g., errors in rules) No guarantee that the same rules will result in the same configuration at a later time. Critical for releases! Extensional: Objects are represented explicitly. All versions are represented. Managing configurations and versions: Change-based: Store deltas between versions rather than versions. Deltas can be combined in many ways (e.g., for concurrent work use time stamps). Intentional for objects and configurations. State-based: Store explicit versions. Extensional for objects, intentional for configurations. Unified model All extensional as follows: Figure 14: Grammar specifying document structure

• Prof. Yoram Reich, Faculty of Engineering, Tel Aviv University, 6/15/2006, [CM overview.doc]

972-3-6407385 (tel), 972-3-6407617 (fax) email: yoram@eng.tau.ac.il, URL: http://or.eng.tau.ac.il:7777,

12 Figure 15 Figure 16

• Prof. Yoram Reich, Faculty of Engineering, Tel Aviv University, 6/15/2006, [CM overview.doc]

972-3-6407385 (tel), 972-3-6407617 (fax) email: yoram@eng.tau.ac.il, URL: http://or.eng.tau.ac.il:7777,

13 Figure 17: Left: original document structure. Middle: structure after one modification to D2 and D3. Right: D1 must be revised to have L’s point to the desired versions of the sub- documents.

Comparison between SCM and PDM

PDM: Product data management SCM: Software Control Management Figure 18: Mechanical versus software engineering products

• Prof. Yoram Reich, Faculty of Engineering, Tel Aviv University, 6/15/2006, [CM overview.doc]

972-3-6407385 (tel), 972-3-6407617 (fax) email: yoram@eng.tau.ac.il, URL: http://or.eng.tau.ac.il:7777,

14 Software: 1. Product resides in files - tree hierarchy (physical structure) 2. Architecture/objects are in a logical structure (e.g., UML diagrams) 3. No logical difference between design (source) and manufacture (compiled) PDM: 1. Products reside in databases - DAG structure 2. Major difference between designed and manufactured SCM/PDM product representation S No explicit data model Tool manage files PDM STEP/EXPRESS ISO standard - industry need to facilitate use of products developed by subcontractors. Object oriented (attributes and constraints) Static definition: no behavior, no care for efficiency issues Tools manage databases Information centered on composition hierarchy (BOM) (fig 1,2) SCM/PDM evolution model S Branch - variant Trunk - main release No distinction between versions (as opposed to alternate, substitute, etc. in PDM) PDM Historical versioning- revision concept Logical versioning - alternate, substitute, and option (asymmetric relation) (fig 3, 4) Domain versioning - views Workspace control Way the object is provided to be manipulated by tools S Present files rather than logical view Files can be multiplied -> need to reconcile changes. PDM Work directly on database + checking mechanisms Check-in/check-out mechanism: Transitive closure: check all related items by traversing the configuration graph. Concurrent engineering: everybody works on same database data Context can filter in relevant parts to work on.

• Prof. Yoram Reich, Faculty of Engineering, Tel Aviv University, 6/15/2006, [CM overview.doc]

972-3-6407385 (tel), 972-3-6407617 (fax) email: yoram@eng.tau.ac.il, URL: http://or.eng.tau.ac.il:7777,

15 SCM/PDM process model S Weak process support. PDM Approval concept: definition of objects, affectivity, change requests, etc. Requires: a person, a date, and an organization Has status. Figure 19

• 7. CM & Asynchronous development: Concurrent product

development

• Prof. Yoram Reich, Faculty of Engineering, Tel Aviv University, 6/15/2006, [CM overview.doc]

972-3-6407385 (tel), 972-3-6407617 (fax) email: yoram@eng.tau.ac.il, URL: http://or.eng.tau.ac.il:7777,

16 Synchronisation of activities FIFO Email- asynchronous Distributed DB- time stamps Protocol: Round robin: lock/unlock for one person at a time (good control, bad collaboration) Division of labor: 1 writer + reviewers, working on different parts Network updates version in short time periods using WYSIWIS (What you see is what I see), short lived versions - threads Visibility: show concurrent accesses Asynchronous work: Version control for synchronous part Change tours for keeping members updated on changes Shared workspaces: view official version, user’s X version

• 8. CM for dynamically changing configurations

Constructed while being executed Distributed systems WWW Continuously executing systems that requires on-line maintenance Hard to tell what the configuration is at a particular moment No static definition of composing the system CM must support different behaviors Issues: Some choices about configuration have not been done yet. Internet browser Display data dependent on its form Dynamically download components (plugins) Be aware of which actions could be performed on displayed data (clickable map) Full set of components cannot be specified and may evolve when encountering a need for a new plugin. Modeling: Objects manipulated by the system Constraints governing valid composition of objects Operations that can be done on objects Version families (versions of same objects, object belonging to the same release,

• bjects requiring the same resources, etc.) used to collect related objects

Selection rules dictating how to choose particular objects in version families PDM in-the-small: manage data about the physical product

• Prof. Yoram Reich, Faculty of Engineering, Tel Aviv University, 6/15/2006, [CM overview.doc]

972-3-6407385 (tel), 972-3-6407617 (fax) email: yoram@eng.tau.ac.il, URL: http://or.eng.tau.ac.il:7777,

17 1. Product structure 2. Quantities 3. Atomic objects PDM in-the-large: (Ball, EDC) 1. Same as PDM in-the-small + 2. Each product (sub-)assembly (internal structure node) is an object containing: Specification Function Attributes (material, …) Geometry Interface between this assembly and others 3. Product structure include design rationale representation (must be using item 2) 4. Product structure include compatible product decompositions and variant designs