Download presentation
Presentation is loading. Please wait.
1
June 17, 2015 – 14:03:501 (c) 2007 University of California, Irvine – André van der Hoek 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
2
June 17, 2015 – 14:03:502 (c) 2007 University of California, Irvine – André van der Hoek A Simplified Development Scenario Pete Pete’s workspaceEllen’s workspace Ellen CM repository
3
June 17, 2015 – 14:03:503 (c) 2007 University of California, Irvine – André van der Hoek Direct Conflicts Conflicting changes to the same artifact Pete Pete’s workspaceEllen’s workspace Ellen CM repository changes
4
June 17, 2015 – 14:03:504 (c) 2007 University of California, Irvine – André van der Hoek Indirect Conflicts Conflicting changes to different artifacts Pete Pete’s workspaceEllen’s workspace Ellen CM repository changes
5
June 17, 2015 – 14:03:505 (c) 2007 University of California, Irvine – André van der Hoek 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
6
June 17, 2015 – 14:03:506 (c) 2007 University of California, Irvine – André van der Hoek Construction Building Snapshots Regeneration Optimization Construction Building Snapshots Regeneration Optimization Auditing History Traceability Logging Auditing History Traceability Logging Components Versions Configurations Baselines Project contexts Components Versions Configurations Baselines Project contexts CM Spectrum of Functionality Susan Dart, SCM-3, 1991 Accounting Statistics Status Reports Accounting Statistics Status Reports Process Lifecycle support Task mgmt. Communication Documentation Process Lifecycle support Task mgmt. Communication Documentation Controlling Access control Change requests Bug tracking Partitioning Controlling Access control Change requests Bug tracking Partitioning Team Workspaces Merging Families Team Workspaces Merging Families Structure System model Interfaces Consistency Selection Structure System model Interfaces Consistency Selection
7
June 17, 2015 – 14:03:507 (c) 2007 University of California, Irvine – André van der Hoek CCC/Harvest Three Generations of CM Systems Functionality Proteus Jasmine EPOS VOODOO ShapeTools Asgard NUCM DaSC Vesta Adele ICE Odin Time Source Integrity Continuus CVS PVCS DSEE SCCS NSE ClearCase TRUEchange Serena Endevor Perforce RCS Sablime Research Development
8
June 17, 2015 – 14:03:508 (c) 2007 University of California, Irvine – André van der Hoek First Generation Focused on: –archiving individual elements –strictly avoiding conflicts Characterized by: –simple, separate tools –development orientation Canonical examples –SCCS –RCS –Make
9
June 17, 2015 – 14:03:509 (c) 2007 University of California, Irvine – André van der Hoek First Generation: Version Graphs 1.0 1.1 2.0 1.2 2.1 1.2.1.0 1.2.1.1 Author = “André v/d Hoek” Date = 01/12/2001 Time = 7:52am Comment = “Trying new stuff” Lock = “andre@ics.uci.edu”
10
June 17, 2015 – 14:03:5010 (c) 2007 University of California, Irvine – André van der Hoek Construction Building Snapshots Regeneration Optimization Construction Building Snapshots Regeneration Optimization Auditing History Traceability Logging Auditing History Traceability Logging Components Versions Configurations Baselines Project contexts Components Versions Configurations Baselines Project contexts First Generation Accounting Statistics Status Reports Accounting Statistics Status Reports Process Lifecycle support Task mgmt. Communication Documentation Process Lifecycle support Task mgmt. Communication Documentation Controlling Access control Change requests Bug tracking Partitioning Controlling Access control Change requests Bug tracking Partitioning Team Workspaces Merging Families Team Workspaces Merging Families Structure System model Interfaces Consistency Selection Structure System model Interfaces Consistency Selection
11
June 17, 2015 – 14:03:5011 (c) 2007 University of California, Irvine – André van der Hoek Second Generation Focused on: –archiving compound elements –different version models Characterized by: –integrated versioning & build tools –development orientation Canonical examples: –CVS –Subversion –PVCS –SourceSafe
12
June 17, 2015 – 14:03:5012 (c) 2007 University of California, Irvine – André van der Hoek Four Canonical Version Models State-based extensional –version tree State-based intensional –conditional compilation Change-based extensional –change packages Change-based intensional –change sets
13
June 17, 2015 – 14:03:5013 (c) 2007 University of California, Irvine – André van der Hoek Conditional Compilation … #ifdef UNIX #include #endif #ifdef GRAPHICS #include #ifdef SMARTGRAPHICS #include #endif #endif …
14
June 17, 2015 – 14:03:5014 (c) 2007 University of California, Irvine – André van der Hoek Change Packages 1.0 1.1 2.0 1.2 2.1 1.2.1.0 1.2.1.1 1.0 2.0 2.2 2.1 2.3 1.0 1.1 1.3 1.2 2.0 2.0.1.0 1.0 1.1 1.2
15
June 17, 2015 – 14:03:5015 (c) 2007 University of California, Irvine – André van der Hoek Change Sets Baseline Bug fix #16 Feature addition #103 Bug fix #17 Feature addition #104 Bug fix #8 Bug fix #16 Bug fix #6 Bug fix #21 AVAILABLE CHANGE SETS SYSTEM SELECTION
16
June 17, 2015 – 14:03:5016 (c) 2007 University of California, Irvine – André van der Hoek Construction Building Snapshots Regeneration Optimization Construction Building Snapshots Regeneration Optimization Auditing History Traceability Logging Auditing History Traceability Logging Components Versions Configurations Baselines Project contexts Components Versions Configurations Baselines Project contexts Second Generation Accounting Statistics Status Reports Accounting Statistics Status Reports Process Lifecycle support Task mgmt. Communication Documentation Process Lifecycle support Task mgmt. Communication Documentation Controlling Access control Change requests Bug tracking Partitioning Controlling Access control Change requests Bug tracking Partitioning Team Workspaces Merging Families Team Workspaces Merging Families Structure System model Interfaces Consistency Selection Structure System model Interfaces Consistency Selection
17
June 17, 2015 – 14:03:5017 (c) 2007 University of California, Irvine – André van der Hoek 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
18
June 17, 2015 – 14:03:5018 (c) 2007 University of California, Irvine – André van der Hoek Construction Building Snapshots Regeneration Optimization Construction Building Snapshots Regeneration Optimization Auditing History Traceability Logging Auditing History Traceability Logging Components Versions Configurations Baselines Project contexts Components Versions Configurations Baselines Project contexts Third Generation Accounting Statistics Status Reports Accounting Statistics Status Reports Process Lifecycle support Task mgmt. Communication Documentation Process Lifecycle support Task mgmt. Communication Documentation Controlling Access control Change requests Bug tracking Partitioning Controlling Access control Change requests Bug tracking Partitioning Team Workspaces Merging Families Team Workspaces Merging Families Structure System model Interfaces Consistency Selection Structure System model Interfaces Consistency Selection
19
June 17, 2015 – 14:03:5019 (c) 2007 University of California, Irvine – André van der Hoek A Fourth Generation ?
20
June 17, 2015 – 14:03:5020 (c) 2007 University of California, Irvine – André van der Hoek 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
21
June 17, 2015 – 14:03:5021 (c) 2007 University of California, Irvine – André van der Hoek 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
22
June 17, 2015 – 14:03:5022 (c) 2007 University of California, Irvine – André van der Hoek 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?
23
June 17, 2015 – 14:03:5023 (c) 2007 University of California, Irvine – André van der Hoek Classic Versioning for Product Lines
24
June 17, 2015 – 14:03:5024 (c) 2007 University of California, Irvine – André van der Hoek Creating the Baseline
25
June 17, 2015 – 14:03:5025 (c) 2007 University of California, Irvine – André van der Hoek Creating the Baseline
26
June 17, 2015 – 14:03:5026 (c) 2007 University of California, Irvine – André van der Hoek Creating the Baseline
27
June 17, 2015 – 14:03:5027 (c) 2007 University of California, Irvine – André van der Hoek Creating the Baseline
28
June 17, 2015 – 14:03:5028 (c) 2007 University of California, Irvine – André van der Hoek Creating the Baseline
29
June 17, 2015 – 14:03:5029 (c) 2007 University of California, Irvine – André van der Hoek Creating the Baseline
30
June 17, 2015 – 14:03:5030 (c) 2007 University of California, Irvine – André van der Hoek Creating the Baseline
31
June 17, 2015 – 14:03:5031 (c) 2007 University of California, Irvine – André van der Hoek Viewing the Baseline
32
June 17, 2015 – 14:03:5032 (c) 2007 University of California, Irvine – André van der Hoek Excluding the Baseline
33
June 17, 2015 – 14:03:5033 (c) 2007 University of California, Irvine – André van der Hoek Including the Baseline
34
June 17, 2015 – 14:03:5034 (c) 2007 University of California, Irvine – André van der Hoek Creating the Record Support
35
June 17, 2015 – 14:03:5035 (c) 2007 University of California, Irvine – André van der Hoek Creating the Record Support
36
June 17, 2015 – 14:03:5036 (c) 2007 University of California, Irvine – André van der Hoek Viewing the Record Support
37
June 17, 2015 – 14:03:5037 (c) 2007 University of California, Irvine – André van der Hoek Removing Old Elements
38
June 17, 2015 – 14:03:5038 (c) 2007 University of California, Irvine – André van der Hoek Removing Old Elements
39
June 17, 2015 – 14:03:5039 (c) 2007 University of California, Irvine – André van der Hoek Removing Old Elements
40
June 17, 2015 – 14:03:5040 (c) 2007 University of California, Irvine – André van der Hoek Removing Old Elements
41
June 17, 2015 – 14:03:5041 (c) 2007 University of California, Irvine – André van der Hoek Adding New Elements
42
June 17, 2015 – 14:03:5042 (c) 2007 University of California, Irvine – André van der Hoek Viewing the CD Writer
43
June 17, 2015 – 14:03:5043 (c) 2007 University of California, Irvine – André van der Hoek Trial Product
44
June 17, 2015 – 14:03:5044 (c) 2007 University of California, Irvine – André van der Hoek Pro Product
45
June 17, 2015 – 14:03:5045 (c) 2007 University of California, Irvine – André van der Hoek All Music Player Change Sets
46
June 17, 2015 – 14:03:5046 (c) 2007 University of California, Irvine – André van der Hoek Visualizing Relationships Change Set CD Writer MP3 Encoder Pro Version Record Support Purchase Reminder
47
June 17, 2015 – 14:03:5047 (c) 2007 University of California, Irvine – André van der Hoek Example Relationships
48
June 17, 2015 – 14:03:5048 (c) 2007 University of California, Irvine – André van der Hoek Product Compositions
49
June 17, 2015 – 14:03:5049 (c) 2007 University of California, Irvine – André van der Hoek Additional Relationships
50
June 17, 2015 – 14:03:5050 (c) 2007 University of California, Irvine – André van der Hoek Violated Relationships
51
June 17, 2015 – 14:03:5051 (c) 2007 University of California, Irvine – André van der Hoek 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
52
June 17, 2015 – 14:03:5052 (c) 2007 University of California, Irvine – André van der Hoek The Eclipse Platform Event Listeners CM Plug-in Workspace Visualization Extractor Internal State Palantír Client Analyzer Visualization Extractor Internal State Palantír Client Analyzer Possible Data Sources Event Database Palantír Server BootstrapCapture Workspace Wrapper The Eclipse Platform Event Listeners CM Plug-in Workspace CM System CM Server Repository Pete’s WorkspaceEllen’s Workspace Workspace Wrapper
53
June 17, 2015 – 14:03:5053 (c) 2007 University of California, Irvine – André van der Hoek Workspace Activity Viewer
54
June 17, 2015 – 14:03:5054 (c) 2007 University of California, Irvine – André van der Hoek Three-Dimensional Rotation for Different Perspectives
55
June 17, 2015 – 14:03:5055 (c) 2007 University of California, Irvine – André van der Hoek Some Advanced Features
56
June 17, 2015 – 14:03:5056 (c) 2007 University of California, Irvine – André van der Hoek GAIM
57
June 17, 2015 – 14:03:5057 (c) 2007 University of California, Irvine – André van der Hoek GAIM
58
June 17, 2015 – 14:03:5058 (c) 2007 University of California, Irvine – André van der Hoek Filters Artifact Developer Age Absolute date Artifact pattern Event type Parallelism
59
June 17, 2015 – 14:03:5059 (c) 2007 University of California, Irvine – André van der Hoek GAIM with Artifact Pattern Filter
60
June 17, 2015 – 14:03:5060 (c) 2007 University of California, Irvine – André van der Hoek GAIM with Additional Age Filter
61
June 17, 2015 – 14:03:5061 (c) 2007 University of California, Irvine – André van der Hoek GAIM with Additional Parallelism Filter
62
June 17, 2015 – 14:03:5062 (c) 2007 University of California, Irvine – André van der Hoek 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
63
June 17, 2015 – 14:03:5063 (c) 2007 University of California, Irvine – André van der Hoek (Scarab Videos)
64
June 17, 2015 – 14:03:5064 (c) 2007 University of California, Irvine – André van der Hoek Indirect Conflicts Conflicting changes to different artifacts Pete Pete’s workspaceEllen’s workspace Ellen CM repository changes
65
June 17, 2015 – 14:03:5065 (c) 2007 University of California, Irvine – André van der Hoek Traditional CM Approaches Coordination mechanism Direct conflicts Indirect conflicts PessimisticLocking before changes are made Avoided, at the expense of project delays Not addressed OptimisticAutomated merging after changes have been made Resolved, except for overlapping changes Not addressed
66
June 17, 2015 – 14:03:5066 (c) 2007 University of California, Irvine – André van der Hoek 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
67
June 17, 2015 – 14:03:5067 (c) 2007 University of California, Irvine – André van der Hoek 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)
68
June 17, 2015 – 14:03:5068 (c) 2007 University of California, Irvine – André van der Hoek 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
69
June 17, 2015 – 14:03:5069 (c) 2007 University of California, Irvine – André van der Hoek Workspace Awareness Pete Pete’s workspaceEllen’s workspace Ellen CM repository changes
70
June 17, 2015 – 14:03:5070 (c) 2007 University of California, Irvine – André van der Hoek Eclipse Visualization: Peripheral Integration
71
June 17, 2015 – 14:03:5071 (c) 2007 University of California, Irvine – André van der Hoek Eclipse Visualization: Peripheral Integration
72
June 17, 2015 – 14:03:5072 (c) 2007 University of California, Irvine – André van der Hoek Eclipse Visualization: Peripheral Integration
73
June 17, 2015 – 14:03:5073 (c) 2007 University of California, Irvine – André van der Hoek 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
74
June 17, 2015 – 14:03:5074 (c) 2007 University of California, Irvine – André van der Hoek 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
75
June 17, 2015 – 14:03:5075 (c) 2007 University of California, Irvine – André van der Hoek 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
76
June 17, 2015 – 14:03:5076 (c) 2007 University of California, Irvine – André van der Hoek 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
77
June 17, 2015 – 14:03:5077 (c) 2007 University of California, Irvine – André van der Hoek 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
78
June 17, 2015 – 14:03:5078 (c) 2007 University of California, Irvine – André van der Hoek 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 TextgroupdetectSCMchatotherstotal DCCntrl Exp 39 78 71 17 12 0202 95 85 ICCntrl Exp 5 38 7 30 4 11 0909 50
79
June 17, 2015 – 14:03:5079 (c) 2007 University of California, Irvine – André van der Hoek 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
80
June 17, 2015 – 14:03:5080 (c) 2007 University of California, Irvine – André van der Hoek 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
81
June 17, 2015 – 14:03:5081 (c) 2007 University of California, Irvine – André van der Hoek 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
82
June 17, 2015 – 14:03:5082 (c) 2007 University of California, Irvine – André van der Hoek Vision
83
June 17, 2015 – 14:03:5083 (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 OnlineStore name:String address:URL placeOrder(order:Order):void getQuantity(item:String):int scan(item:ID):boolean addItem(item:Item):void Class
84
June 17, 2015 – 14:03:5084 (c) 2007 University of California, Irvine – André van der Hoek OnlineStore name:String address:Address address:URL Store (Store) placeOrder(order:Order):void getQuantity(item:String):int (scan(item:ID):boolean) scan(item:ID):boolean addItem(item:Item):void Class 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
85
June 17, 2015 – 14:03:5085 (c) 2007 University of California, Irvine – André van der Hoek Which Changes by Whom and When? OnlineStore name:String address:Address address:URL Store (Store) placeOrder(order:Order):void getQuantity(item:String):int (scan(item:ID):boolean) scan(item:ID):boolean addItem(item:Item):void Class
86
June 17, 2015 – 14:03:5086 (c) 2007 University of California, Irvine – André van der Hoek Progression of Changes OnlineStore name:String address:Address address:URL Store (Store) placeOrder(order:Order):void getQuantity(item:String):int (scan(item:ID):boolean) scan(item:ID):boolean addItem(item:Item):void Class
87
June 17, 2015 – 14:03:5087 (c) 2007 University of California, Irvine – André van der Hoek Coordination Actions OnlineStore name:String address:Address address:URL Store (Store) placeOrder(order:Order):void getQuantity(item:String):int (scan(item:ID):boolean) scan(item:ID):boolean addItem(item:Item):void Class
88
June 17, 2015 – 14:03:5088 (c) 2007 University of California, Irvine – André van der Hoek
89
June 17, 2015 – 14:03:5089 (c) 2007 University of California, Irvine – André van der Hoek
90
June 17, 2015 – 14:03:5090 (c) 2007 University of California, Irvine – André van der Hoek
91
June 17, 2015 – 14:03:5091 (c) 2007 University of California, Irvine – André van der Hoek Default: Minimized Appearance
92
June 17, 2015 – 14:03:5092 (c) 2007 University of California, Irvine – André van der Hoek Two-Stage Auto-Expansion upon Changes
93
June 17, 2015 – 14:03:5093 (c) 2007 University of California, Irvine – André van der Hoek Radial Layout – Code Distance as “Coupling”
94
June 17, 2015 – 14:03:5094 (c) 2007 University of California, Irvine – André van der Hoek Radial Layout – Code Distance as “Coupling”
95
June 17, 2015 – 14:03:5095 (c) 2007 University of California, Irvine – André van der Hoek Radial Layout – Code Distance as “Coupling”
96
June 17, 2015 – 14:03:5096 (c) 2007 University of California, Irvine – André van der Hoek In Use
97
June 17, 2015 – 14:03:5097 (c) 2007 University of California, Irvine – André van der Hoek Future Plans #1: Design Devations
98
June 17, 2015 – 14:03:5098 (c) 2007 University of California, Irvine – André van der Hoek Future Plans #2: Project Management Base abstraction upon which to show design deviations, test coverage, code volatility, aging, … – for the entire system
99
June 17, 2015 – 14:03:5099 (c) 2007 University of California, Irvine – André van der Hoek Coordination Asynchronous communication Access to common set of artifacts, isolated workspaces and version control Parallel development, roles and access rights Passive awareness of development activities and developers, manage information overload Task allocation and assignment Communication archival along with artifacts Communication Collocation benefits to distributed development Organizational memory, knowledge acquisition and dissemination, social navigation Prescribed and defined coordination support Artifact ManagementTask Management Advanced conflict detection Basic Functionality Rigid Process Information Discovery Information Provision Fine grained versioning, conflict resolution Instant messaging, monitoring changes to artifacts
100
June 17, 2015 – 14:03:50100 (c) 2007 University of California, Irvine – André van der Hoek Layers: Coordination Paradigms Asynchronous communication Access to common set of artifacts, isolated workspaces and version control Parallel development, roles and access rights Passive awareness of development activities and developers, manage information overload Task allocation and assignment Communication archival along with artifacts Communication Collocation benefits to distributed development Organizational memory, knowledge acquisition and dissemination, social navigation Prescribed and defined coordination support Artifact ManagementTask Management Advanced conflict detection Basic Functionality Rigid Process Information Discovery Information Provision Fine grained versioning, conflict resolution Instant messaging, monitoring changes to artifacts
101
June 17, 2015 – 14:03:50101 (c) 2007 University of California, Irvine – André van der Hoek Strands: Technical Dimensions of Coordination Asynchronous communication Access to common set of artifacts, isolated workspaces and version control Parallel development, roles and access rights Passive awareness of development activities and developers, manage information overload Task allocation and assignment Communication archival along with artifacts Communication Collocation benefits to distributed development Organizational memory, knowledge acquisition and dissemination, social navigation Prescribed and defined coordination support Artifact ManagementTask Management Advanced conflict detection Basic Functionality Rigid Process Information Discovery Information Provision Fine grained versioning, conflict resolution Instant messaging, monitoring changes to artifacts
102
June 17, 2015 – 14:03:50102 (c) 2007 University of California, Irvine – André van der Hoek A New Paradigm: Provoked Behavior Continuous coordination, collaborative architecture, seamless development environments, Asynchronous communication Access to common set of artifacts, isolated workspaces and version control Parallel development, roles and access rights Passive awareness of development activities and developers, manage information overload Task allocation and assignment Communication archival along with artifacts Communication Collocation benefits to distributed development Organizational memory, knowledge acquisition and dissemination, social navigation Prescribed and defined coordination support Artifact ManagementTask Management Advanced conflict detection Basic Functionality Rigid Process Information Discovery Information Provision Provoked Behavior Fine grained versioning, conflict resolution Instant messaging, monitoring changes to artifacts
103
June 17, 2015 – 14:03:50103 (c) 2007 University of California, Irvine – André van der Hoek Configuration Management Continuous coordination, collaborative architecture, seamless development environments, Asynchronous communication Access to common set of artifacts, isolated workspaces and version control Parallel development, roles and access rights Passive awareness of development activities and developers, manage information overload Task allocation and assignment Communication archival along with artifacts Communication Collocation benefits to distributed development Organizational memory, knowledge acquisition and dissemination, social navigation Prescribed and defined coordination support Artifact ManagementTask Management Advanced conflict detection Basic Functionality Rigid Process Information Discovery Information Provision Fine grained versioning, conflict resolution Instant messaging, monitoring changes to artifacts Provoked Behavior
104
June 17, 2015 – 14:03:50104 (c) 2007 University of California, Irvine – André van der Hoek 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
105
June 17, 2015 – 14:03:50105 (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..and the rest of the Continuous Coordination research group at UC Irvine.
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.