Informatics 211 configuration management coordination
This presentation is the property of its rightful owner.
Sponsored Links
1 / 105

Informatics 211: Configuration Management & Coordination PowerPoint PPT Presentation


  • 77 Views
  • Uploaded on
  • Presentation posted in: General

Informatics 211: Configuration Management & Coordination. Andr é van der Hoek University of California, Irvine Donald Bren School of Information and Computer Sciences Department of Informatics [email protected] A Simplified Development Scenario. Pete’s workspace. Ellen’s workspace.

Download Presentation

Informatics 211: Configuration Management & Coordination

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 [email protected]

(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 = [email protected]

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


Informatics 211 configuration management coordination

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


Informatics 211 configuration management coordination

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


Informatics 211 configuration management coordination

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


Default minimized appearance

Default: Minimized Appearance

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


Two stage auto expansion upon changes

Two-Stage Auto-Expansion upon Changes

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


Radial layout code distance as coupling

Radial Layout – Code Distance as “Coupling”

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


Radial layout code distance as coupling1

Radial Layout – Code Distance as “Coupling”

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


Radial layout code distance as coupling2

Radial Layout – Code Distance as “Coupling”

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


In use

In Use

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


Future plans 1 design devations

Future Plans #1: Design Devations

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


Future plans 2 project management

Future Plans #2: Project Management

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

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

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

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

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

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

  • 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

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


  • Login