Informatics 211 configuration management coordination
Download
1 / 105

Informatics 211: Configuration Management & Coordination - PowerPoint PPT Presentation


  • 92 Views
  • Uploaded on

Informatics 211: Configuration Management & Coordination. Andr é van der Hoek University of California, Irvine Donald Bren School of Information and Computer Sciences Department of Informatics andre@ics.uci.edu. A Simplified Development Scenario. Pete’s workspace. Ellen’s workspace.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Informatics 211: Configuration Management & Coordination' - dyanne


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Informatics 211 configuration management coordination

Informatics 211:Configuration Management & Coordination

André van der HoekUniversity of California, IrvineDonald Bren School of Information and Computer SciencesDepartment of Informaticsandre@ics.uci.edu

(c) 2007 University of California, Irvine – André van der Hoek


A simplified development scenario
A Simplified Development Scenario

Pete’s workspace

Ellen’s workspace

CM repository

Pete

Ellen

(c) 2007 University of California, Irvine – André van der Hoek


Direct conflicts
Direct Conflicts

Pete’s workspace

Ellen’s workspace

CM repository

changes

changes

Pete

Ellen

Conflicting changes to the same artifact

(c) 2007 University of California, Irvine – André van der Hoek


Indirect conflicts
Indirect Conflicts

Pete’s workspace

Ellen’s workspace

CM repository

changes

changes

Pete

Ellen

Conflicting changes to different artifacts

(c) 2007 University of California, Irvine – André van der Hoek


Configuration management
Configuration Management

  • “Configuration management (CM) is a discipline whose goal is to control changes to large software through the functions of: component identification, change tracking, version selection and baselining, software manufacture, and managing simultaneous updates (team work).”

Walter Tichy, SCM-1, 1988

(c) 2007 University of California, Irvine – André van der Hoek


Cm spectrum of functionality
CM Spectrum of Functionality

  • Components

  • Versions

  • Configurations

  • Baselines

  • Project contexts

  • Structure

  • System model

  • Interfaces

  • Consistency

  • Selection

  • Construction

  • Building

  • Snapshots

  • Regeneration

  • Optimization

  • Controlling

  • Access control

  • Change requests

  • Bug tracking

  • Partitioning

  • Accounting

  • Statistics

  • Status

  • Reports

  • Auditing

  • History

  • Traceability

  • Logging

  • Process

  • Lifecycle support

  • Task mgmt.

  • Communication

  • Documentation

  • Team

  • Workspaces

  • Merging

  • Families

Susan Dart, SCM-3, 1991

(c) 2007 University of California, Irvine – André van der Hoek


Three generations of cm systems
Three Generations of CM Systems

Continuus

DaSC

ClearCase

Perforce

NUCM

Asgard

CCC/Harvest

TRUEchange

Proteus

ICE

Serena

Vesta

Endevor

Functionality

NSE

PVCS

EPOS

DSEE

Source Integrity

Adele

VOODOO

CVS

RCS

Odin

ShapeTools

Sablime

Jasmine

Research

Development

SCCS

Time

(c) 2007 University of California, Irvine – André van der Hoek


First generation
First Generation

  • Focused on:

    • archiving individual elements

    • strictly avoiding conflicts

  • Characterized by:

    • simple, separate tools

    • development orientation

  • Canonical examples

    • SCCS

    • RCS

    • Make

(c) 2007 University of California, Irvine – André van der Hoek


First generation version graphs
First Generation: Version Graphs

1.0

1.1

Author = “André v/d Hoek”Date = 01/12/2001Time = 7:52amComment = “Trying new stuff”Lock = “andre@ics.uci.edu”

1.2

1.2.1.0

2.0

1.2.1.1

2.1

(c) 2007 University of California, Irvine – André van der Hoek


First generation1
First Generation

  • Components

  • Versions

  • Configurations

  • Baselines

  • Project contexts

  • Structure

  • System model

  • Interfaces

  • Consistency

  • Selection

  • Construction

  • Building

  • Snapshots

  • Regeneration

  • Optimization

  • Controlling

  • Access control

  • Change requests

  • Bug tracking

  • Partitioning

  • Accounting

  • Statistics

  • Status

  • Reports

  • Auditing

  • History

  • Traceability

  • Logging

  • Process

  • Lifecycle support

  • Task mgmt.

  • Communication

  • Documentation

  • Team

  • Workspaces

  • Merging

  • Families

(c) 2007 University of California, Irvine – André van der Hoek


Second generation
Second Generation

  • Focused on:

    • archiving compound elements

    • different version models

  • Characterized by:

    • integrated versioning & build tools

    • development orientation

  • Canonical examples:

    • CVS

    • Subversion

    • PVCS

    • SourceSafe

(c) 2007 University of California, Irvine – André van der Hoek


Four canonical version models
Four Canonical Version Models

  • State-based extensional

    • version tree

  • State-based intensional

    • conditional compilation

  • Change-based extensional

    • change packages

  • Change-based intensional

    • change sets

(c) 2007 University of California, Irvine – André van der Hoek


Conditional compilation
Conditional Compilation

…#ifdef UNIX

#include <stdio.h>#endif#ifdef GRAPHICS #include <graphics.h> #ifdef SMARTGRAPHICS #include <smart.> #endif#endif…

(c) 2007 University of California, Irvine – André van der Hoek


Change packages
Change Packages

1.0

1.0

1.0

1.0

2.0

1.1

1.1

1.1

2.1

1.2

1.2.1.0

1.2

2.2

2.0

1.2.1.1

1.3

2.0.1.0

1.2

2.3

2.1

2.0

(c) 2007 University of California, Irvine – André van der Hoek


Change sets
Change Sets

AVAILABLECHANGESETS

SYSTEMSELECTION

Bug fix #17

Feature addition#104

Bug fix #21

Feature addition#103

Bug fix #8

Bug fix #6

Bug fix #16

Baseline

Bug fix #16

(c) 2007 University of California, Irvine – André van der Hoek


Second generation1
Second Generation

  • Components

  • Versions

  • Configurations

  • Baselines

  • Project contexts

  • Structure

  • System model

  • Interfaces

  • Consistency

  • Selection

  • Construction

  • Building

  • Snapshots

  • Regeneration

  • Optimization

  • Controlling

  • Access control

  • Change requests

  • Bug tracking

  • Partitioning

  • Accounting

  • Statistics

  • Status

  • Reports

  • Auditing

  • History

  • Traceability

  • Logging

  • Process

  • Lifecycle support

  • Task mgmt.

  • Communication

  • Documentation

  • Team

  • Workspaces

  • Merging

  • Families

(c) 2007 University of California, Irvine – André van der Hoek


Third generation
Third Generation

  • Focused on:

    • providing process support

    • being all-encompassing

  • Characterized by:

    • large, complex tools

    • management orientation

  • Canonical examples:

    • ClearCase together with ClearGuide

    • CM/Synergy

(c) 2007 University of California, Irvine – André van der Hoek


Third generation1
Third Generation

  • Components

  • Versions

  • Configurations

  • Baselines

  • Project contexts

  • Structure

  • System model

  • Interfaces

  • Consistency

  • Selection

  • Construction

  • Building

  • Snapshots

  • Regeneration

  • Optimization

  • Controlling

  • Access control

  • Change requests

  • Bug tracking

  • Partitioning

  • Accounting

  • Statistics

  • Status

  • Reports

  • Auditing

  • History

  • Traceability

  • Logging

  • Process

  • Lifecycle support

  • Task mgmt.

  • Communication

  • Documentation

  • Team

  • Workspaces

  • Merging

  • Families

(c) 2007 University of California, Irvine – André van der Hoek


A fourth generation
A Fourth Generation

?

(c) 2007 University of California, Irvine – André van der Hoek


Informatics 211 configuration management coordination
No…

  • CM core functionality is stable with well-understood choices

  • CM tool enhancement seems to be limited to feature creep, not fundamental new approaches

  • SCM workshop series has ended

  • Only a few pure CM papers are being published as of late

(c) 2007 University of California, Irvine – André van der Hoek


Maybe
Maybe…

  • CM functionality is now appearing in domains other than source code management

    • web content management

    • product data management

    • web services and components

    • software deployment

    • product line architectures

  • Mining software repositories

    • no better repository than the CM repository

  • Still some problems left

    • indirect conflicts

    • concern management

  • Coordination

(c) 2007 University of California, Irvine – André van der Hoek


Product line architectures the problem
Product Line Architectures: The Problem

  • “A software product line (SPL) is a strategic software-based asset that explicitly recognizes, optimizes, and manages variability towards current and future feature changes.” [van der Hoek]

  • But how to manage this asset?

(c) 2007 University of California, Irvine – André van der Hoek


Classic versioning for product lines
Classic Versioning for Product Lines

(c) 2007 University of California, Irvine – André van der Hoek


Creating the baseline
Creating the Baseline

(c) 2007 University of California, Irvine – André van der Hoek


Creating the baseline1
Creating the Baseline

(c) 2007 University of California, Irvine – André van der Hoek


Creating the baseline2
Creating the Baseline

(c) 2007 University of California, Irvine – André van der Hoek


Creating the baseline3
Creating the Baseline

(c) 2007 University of California, Irvine – André van der Hoek


Creating the baseline4
Creating the Baseline

(c) 2007 University of California, Irvine – André van der Hoek


Creating the baseline5
Creating the Baseline

(c) 2007 University of California, Irvine – André van der Hoek


Creating the baseline6
Creating the Baseline

(c) 2007 University of California, Irvine – André van der Hoek


Viewing the baseline
Viewing the Baseline

(c) 2007 University of California, Irvine – André van der Hoek


Excluding the baseline
Excluding the Baseline

(c) 2007 University of California, Irvine – André van der Hoek


Including the baseline
Including the Baseline

(c) 2007 University of California, Irvine – André van der Hoek


Creating the record support
Creating the Record Support

(c) 2007 University of California, Irvine – André van der Hoek


Creating the record support1
Creating the Record Support

(c) 2007 University of California, Irvine – André van der Hoek


Viewing the record support
Viewing the Record Support

(c) 2007 University of California, Irvine – André van der Hoek


Removing old elements
Removing Old Elements

(c) 2007 University of California, Irvine – André van der Hoek


Removing old elements1
Removing Old Elements

(c) 2007 University of California, Irvine – André van der Hoek


Removing old elements2
Removing Old Elements

(c) 2007 University of California, Irvine – André van der Hoek


Removing old elements3
Removing Old Elements

(c) 2007 University of California, Irvine – André van der Hoek


Adding new elements
Adding New Elements

(c) 2007 University of California, Irvine – André van der Hoek


Viewing the cd writer
Viewing the CD Writer

(c) 2007 University of California, Irvine – André van der Hoek


Trial product
Trial Product

(c) 2007 University of California, Irvine – André van der Hoek


Pro product
Pro Product

(c) 2007 University of California, Irvine – André van der Hoek


All music player change sets
All Music Player Change Sets

(c) 2007 University of California, Irvine – André van der Hoek


Visualizing relationships
Visualizing Relationships

(c) 2007 University of California, Irvine – André van der Hoek


Example relationships
Example Relationships

(c) 2007 University of California, Irvine – André van der Hoek


Product compositions
Product Compositions

(c) 2007 University of California, Irvine – André van der Hoek


Additional relationships
Additional Relationships

(c) 2007 University of California, Irvine – André van der Hoek


Violated relationships
Violated Relationships

(c) 2007 University of California, Irvine – André van der Hoek


Mining software repositories
Mining Software Repositories

  • Configuration management repositories are traditionally a “depot”

    • occasional roll-back

    • occasional search for relevant information

  • But what if we used the information captured by configuration management repositories to our advantage

    • understanding software developers

    • helping software developers

(c) 2007 University of California, Irvine – André van der Hoek


Possible data sources

PalantírClient

Palantír Client

Visualization

Visualization

Extractor

Extractor

Internal State

Internal State

Analyzer

Analyzer

The Eclipse Platform

Event Listeners

Workspace

CM Plug-in

Possible Data Sources

Pete’s Workspace

Ellen’s Workspace

Palantír Server

Capture

Bootstrap

Event Database

Workspace Wrapper

Workspace Wrapper

CM System

CM Server

The Eclipse Platform

Event Listeners

Workspace

Repository

CM Plug-in

(c) 2007 University of California, Irvine – André van der Hoek


Workspace activity viewer
Workspace Activity Viewer

(c) 2007 University of California, Irvine – André van der Hoek


Three dimensional rotation for different perspectives
Three-Dimensional Rotation for Different Perspectives

(c) 2007 University of California, Irvine – André van der Hoek


Some advanced features
Some Advanced Features

(c) 2007 University of California, Irvine – André van der Hoek


Informatics 211 configuration management coordination
GAIM

(c) 2007 University of California, Irvine – André van der Hoek


Informatics 211 configuration management coordination
GAIM

(c) 2007 University of California, Irvine – André van der Hoek


Filters
Filters

  • Artifact

  • Developer

  • Age

  • Absolute date

  • Artifact pattern

  • Event type

  • Parallelism

(c) 2007 University of California, Irvine – André van der Hoek


Gaim with artifact pattern filter
GAIM with Artifact Pattern Filter

(c) 2007 University of California, Irvine – André van der Hoek


Gaim with additional age filter
GAIM with Additional Age Filter

(c) 2007 University of California, Irvine – André van der Hoek


Gaim with additional parallelism filter
GAIM with Additional Parallelism Filter

(c) 2007 University of California, Irvine – André van der Hoek


Replaying history
Replaying History

  • Extends the usefulness of Workspace Activity Viewer from just understanding the present moment to also beginning to understand how projects evolve

  • In the following videos, history is partially simulated based on CM archive data

(c) 2007 University of California, Irvine – André van der Hoek


Scarab videos
(Scarab Videos)

(c) 2007 University of California, Irvine – André van der Hoek


Indirect conflicts1
Indirect Conflicts

Pete’s workspace

Ellen’s workspace

CM repository

changes

changes

Pete

Ellen

Conflicting changes to different artifacts

(c) 2007 University of California, Irvine – André van der Hoek


Traditional cm approaches
Traditional CM Approaches

(c) 2007 University of California, Irvine – André van der Hoek


Key observations
Key Observations

  • CM workspaces in reality provide two kinds of isolation

    • “good” isolation (insulation)

      • shields developers from parallel changes to artifacts

    • “bad” isolation (seclusion)

      • hides knowledge of what artifacts other developers are changing

  • Opportunities for breaking “bad” isolation are limited

    • based on repository information only

    • initiated by developer only

    • addressing direct conflicts only

  • In essence, a specific form of coordination is enforced and limited by the process underlying the CM system

(c) 2007 University of California, Irvine – André van der Hoek


Undesirable consequences field studies
Undesirable Consequences (Field Studies)

  • The more parallel work takes place, the lower the quality of the code that is delivered

  • Developers recognize the significance of direct conflicts

    • direct conflicts are considered “a pain”

    • developers will race to be the first to commit their changes, just to avoid the task of merging

    • much informal communication takes place in order to attempt to avoid direct conflicts

  • Developers do not recognize the significance of indirect conflicts

    • considered to be a normal part of the work (e.g., integration, resolving test case failures, dealing with bugs)

(c) 2007 University of California, Irvine – André van der Hoek


Our objective
Our Objective

  • Support more effective coordination of parallel work by allowing “good” isolation but breaking “bad” isolation

  • Enable early detection and resolution of direct and indirect conflicts

    • while these conflicts emerge

  • Mitigate the impact of direct and indirect conflicts

    • through provoked self-coordination of developers

(c) 2007 University of California, Irvine – André van der Hoek


Workspace awareness
Workspace Awareness

Pete’s workspace

Ellen’s workspace

CM repository

changes

changes

Pete

Ellen

(c) 2007 University of California, Irvine – André van der Hoek


Eclipse visualization peripheral integration
Eclipse Visualization: Peripheral Integration

(c) 2007 University of California, Irvine – André van der Hoek


Eclipse visualization peripheral integration1
Eclipse Visualization: Peripheral Integration

(c) 2007 University of California, Irvine – André van der Hoek


Eclipse visualization peripheral integration2
Eclipse Visualization: Peripheral Integration

(c) 2007 University of California, Irvine – André van der Hoek


Three laboratory experiments
Three Laboratory Experiments

  • Text-based evaluation of the effectiveness of the user interface

    • Palantír versus no Palantír

  • Code-based evaluation of the effectiveness of providing awareness information

    • Palantír versus no Palantír

  • Code-based evaluation of the effectiveness of providing awareness information on indirect conflicts

    • Palantír with direct and indirect conflicts versus Palantír with direct conflicts only

(c) 2007 University of California, Irvine – André van der Hoek


Experiment design
Experiment Design

  • Confederate-based design

    • ensured consistency in number and nature of conflicts

    • introduced direct and indirect conflicts

    • controlled individual differences in project activities

  • Dependent variables

    • number of conflicts detected (and resolved)

    • time-to-completion of tasks

    • number of coordination attempts

(c) 2007 University of California, Irvine – André van der Hoek


Result 1 early conflict detection and resolution
Result 1: Early Conflict Detection and Resolution

  • More direct conflicts were identified and resolved before check-in

  • More indirect conflicts were identified

  • More indirect conflicts were resolved

(c) 2007 University of California, Irvine – André van der Hoek


Result 2 indirect conflict notification
Result 2: Indirect Conflict Notification

  • More indirect conflicts were detected and resolved when potential indirect conflicts were highlighted

    • the indirect conflicts we seeded were easy

  • Developers’ knowledge of the structure of the code is inadequate to just rely on direct conflict notification

(c) 2007 University of California, Irvine – André van der Hoek


Result 3 time to completion
Result 3: Time-to-Completion

  • Direct conflicts

    • group using Palantír is faster

    • resolution time for conflict is less

  • Indirect conflicts

    • group using Palantír is a little slower

    • more conflicts are detected and resolved

(c) 2007 University of California, Irvine – André van der Hoek


Result 4 amount of communication
Result 4: Amount of Communication

  • The use of awareness leads to fewer coordination attempts and less time spent in those attempts

    • not statistically significant

    • but sufficiently indicative and sufficiently provocative to warrant additional study

(c) 2007 University of California, Irvine – André van der Hoek


Interpreting the results
Interpreting The Results

  • Direct and indirect conflicts are detected as they emerge

  • Developers undertake action upon noticing a potential conflict

  • Fewer conflicts grow “out of hand”

  • The resulting code is of higher quality

  • The penalty may be a small increase in time now

    • but the experiments do not account for the time later that developers must otherwise spend on resolving conflicts that are committed to the CM repository

(c) 2007 University of California, Irvine – André van der Hoek


Limitations to palant r
Limitations to Palantír

  • Disconnect between awareness and action

  • Potential for information overload

  • Effective, but not a rich work context

    • further examination is required

  • Opportunities for further improvement and extension are limited by the directory/file metaphor

    • does not map very well to our mental model of the code

(c) 2007 University of California, Irvine – André van der Hoek


Lighthouse approach
Lighthouse Approach

  • Leverage a secondary monitor to provide developers with a coordination platform that integrates awareness and action

  • Center the platform on the metaphor of emerging design

  • Contextualize the awareness information based on the changes currently being made

(c) 2007 University of California, Irvine – André van der Hoek


Vision
Vision

(c) 2007 University of California, Irvine – André van der Hoek


Awareness information basics

Emerging design is the design as it resides in the code

Continuously kept up to date with every code change

UML-like diagrams

Keeps the developer abreast of how the code changes at the interface level

Class

OnlineStore

name:String

address:URL

placeOrder(order:Order):void

addItem(item:Item):void

getQuantity(item:String):int

scan(item:ID):boolean

Awareness Information: Basics

(c) 2007 University of California, Irvine – André van der Hoek


Awareness information basics1

Emerging design is the design as it resides in the code

Continuously kept up to date with every code change

UML-like diagrams

Keeps the developer abreast of how the code changes at the interface level

Class

Store

(Store)

OnlineStore

name:String

address:Address

address:URL

placeOrder(order:Order):void

addItem(item:Item):void

getQuantity(item:String):int

(scan(item:ID):boolean)

scan(item:ID):boolean

Awareness Information: Basics

(c) 2007 University of California, Irvine – André van der Hoek


Which changes by whom and when

Class

Store

(Store)

OnlineStore

name:String

address:Address

address:URL

placeOrder(order:Order):void

addItem(item:Item):void

getQuantity(item:String):int

(scan(item:ID):boolean)

scan(item:ID):boolean

Which Changes by Whom and When?

(c) 2007 University of California, Irvine – André van der Hoek


Progression of changes

Class

Store

(Store)

OnlineStore

name:String

address:Address

address:URL

placeOrder(order:Order):void

addItem(item:Item):void

getQuantity(item:String):int

(scan(item:ID):boolean)

scan(item:ID):boolean

Progression of Changes

(c) 2007 University of California, Irvine – André van der Hoek


Coordination actions

Class

Store

(Store)

OnlineStore

name:String

address:Address

address:URL

placeOrder(order:Order):void

addItem(item:Item):void

getQuantity(item:String):int

(scan(item:ID):boolean)

scan(item:ID):boolean

Coordination Actions

(c) 2007 University of California, Irvine – André van der Hoek





Default minimized appearance
Default: Minimized Appearance Hoek

(c) 2007 University of California, Irvine – André van der Hoek


Two stage auto expansion upon changes
Two-Stage Auto-Expansion upon Changes Hoek

(c) 2007 University of California, Irvine – André van der Hoek


Radial layout code distance as coupling
Radial Layout – Code Distance as “Coupling” Hoek

(c) 2007 University of California, Irvine – André van der Hoek


Radial layout code distance as coupling1
Radial Layout – Code Distance as “Coupling” Hoek

(c) 2007 University of California, Irvine – André van der Hoek


Radial layout code distance as coupling2
Radial Layout – Code Distance as “Coupling” Hoek

(c) 2007 University of California, Irvine – André van der Hoek


In use
In Use Hoek

(c) 2007 University of California, Irvine – André van der Hoek


Future plans 1 design devations
Future Plans #1: Design Devations Hoek

(c) 2007 University of California, Irvine – André van der Hoek


Future plans 2 project management
Future Plans #2: Project Management Hoek

Base abstraction upon which to show design deviations,test coverage, code volatility, aging, … – for the entire system

(c) 2007 University of California, Irvine – André van der Hoek


Coordination
Coordination Hoek

Information

Passive awareness of

Provision

Collocation benefits to

development activities

Advanced conflict

distributed development

and developers, manage

detection

information overload

Information

Instant messaging,

Organizational memor

y

,

Discovery

Fine grained versioning,

monitoring changes

knowledge acquisition and

conflict resolution

to artifacts

dissemination, social navigation

Rigid

Process

Communication archival

Parallel development,

Prescribed and defined

along with artifacts

roles and access rights

coordination support

Basic

Functionality

Access to common set of artifacts,

Asynchronous communication

T

ask allocation and assignment

isolated workspaces and version control

Communication

Artifact Management

Task Management

(c) 2007 University of California, Irvine – André van der Hoek


Layers coordination paradigms
Layers: Coordination Paradigms Hoek

Information

Passive awareness of

Provision

Collocation benefits to

development activities

Advanced conflict

distributed development

and developers, manage

detection

information overload

Information

Instant messaging,

Organizational memor

y

,

Discovery

Fine grained versioning,

monitoring changes

knowledge acquisition and

conflict resolution

to artifacts

dissemination, social navigation

Rigid

Process

Communication archival

Parallel development,

Prescribed and defined

along with artifacts

roles and access rights

coordination support

Basic

Functionality

Access to common set of artifacts,

Asynchronous communication

T

ask allocation and assignment

isolated workspaces and version control

Communication

Artifact Management

Task Management

(c) 2007 University of California, Irvine – André van der Hoek


Strands technical dimensions of coordination
Strands: Technical Dimensions of Coordination Hoek

Information

Passive awareness of

Provision

Collocation benefits to

development activities

Advanced conflict

distributed development

and developers, manage

detection

information overload

Information

Instant messaging,

Organizational memor

y

,

Discovery

Fine grained versioning,

monitoring changes

knowledge acquisition and

conflict resolution

to artifacts

dissemination, social navigation

Rigid

Process

Communication archival

Parallel development,

Prescribed and defined

along with artifacts

roles and access rights

coordination support

Basic

Functionality

Access to common set of artifacts,

Asynchronous communication

T

ask allocation and assignment

isolated workspaces and version control

Communication

Artifact Management

Task Management

(c) 2007 University of California, Irvine – André van der Hoek


A new paradigm provoked behavior
A New Paradigm: Provoked Behavior Hoek

Provoked

Continuous coordination,

Behavior

collaborative architecture,

seamless development environments,

Information

Passive awareness of

Provision

Collocation benefits to

development activities

Advanced conflict

distributed development

and developers, manage

detection

information overload

Information

Instant messaging,

Organizational memor

y

,

Discovery

Fine grained versioning,

monitoring changes

knowledge acquisition and

conflict resolution

to artifacts

dissemination, social navigation

Rigid

Process

Communication archival

Parallel development,

Prescribed and defined

along with artifacts

roles and access rights

coordination support

Basic

Functionality

Access to common set of artifacts,

Asynchronous communication

T

ask allocation and assignment

isolated workspaces and version control

Communication

Artifact Management

Task Management

(c) 2007 University of California, Irvine – André van der Hoek


Configuration management1
Configuration Management Hoek

Provoked

Continuous coordination,

Behavior

collaborative architecture,

seamless development environments,

Information

Passive awareness of

Provision

Collocation benefits to

development activities

Advanced conflict

distributed development

and developers, manage

detection

information overload

Information

Instant messaging,

Organizational memor

y

,

Discovery

Fine grained versioning,

monitoring changes

knowledge acquisition and

conflict resolution

to artifacts

dissemination, social navigation

Rigid

Process

Communication archival

Parallel development,

Prescribed and defined

along with artifacts

roles and access rights

coordination support

Basic

Functionality

Access to common set of artifacts,

Asynchronous communication

T

ask allocation and assignment

isolated workspaces and version control

Communication

Artifact Management

Task Management

(c) 2007 University of California, Irvine – André van der Hoek


Conclusion
Conclusion Hoek

  • CM is a long-standing field which has seen numerous contributions

    • some highly influential (sometimes delayed by as much as 20 years)

    • others indirectly shaping

    • others utterly useless

  • While the core ideas of CM have been well developed, there is still much room for improvement

    • particularly if one considers CM to be a coordination problem

    • particularly if one brings together CM with other disciplines

  • Software engineering can be cool 

(c) 2007 University of California, Irvine – André van der Hoek


Acknowledgments

David Redmiles Hoek

Ban Al-Ani

Isabella Almeida

Marcelo Alvim

Anita Sarma

Chris Van der Westhuizen

Ping Chen

Erik Trainer

Stephen Quirk

Roger Ripley

Acknowledgments

..and the rest of the Continuous Coordinationresearch group at UC Irvine.

(c) 2007 University of California, Irvine – André van der Hoek