Final Report on Collaborative Software Engineering Tools Workshop and Follow-Up

Project NAG2-1555

Edited by

David F. Redmiles, PhD

Institute for Software Research and Department of Informatics

University of California, Irvine Irvine, CA 92697-3425 USA

redmiles@ics.uci.edu

ISR Technical Report # UCI-ISR-03-14

December 2003 Abstract: This report documents the project “Collaborative Software Engineering Tools Workshop and Follow-Up.” Under this project, a workshop was held at NASA/Ames on August 5 and 6, 2002. Additional research followed up on the workshop. Hence, the report contains these two components: materials from the workshop and a series of research papers that document our follow-up activities. The workshop brought together technical staff of NASA/Ames and faculty and staff researchers from University of California's Institute for Software Research (ISR). The goal of the workshop was to generate a joint understanding of collaborative software engineering tools informed from four perspectives: 1) technology, 2) theory, 3) field studies, and 4) specific NASA problems. The follow-up work included an intern working at NASA and providing some analysis of observations during the course of that work. The analysis was carried out collaboratively between personnel at NASA/Ames and UCI/ISR. Additional experimental software development was performed at UCI examining the role and architecture of event notification servers and awareness. Also, some initial explorations about extending field study methods were done.

Since the workshop, a web site has been maintained at http://www.isr.uci.edu/events/NASA-Workshop/

Table of Contents Part 1: Workshop Materials Part 2: Follow-up Materials

Part 1: Workshop Materials

Agenda Monday, August 5 10:30 - 12:00 Scope of Collaborative Software Engineering

Introductions all around (15 mins) Introductory Remarks David Redmiles, UCI/ISR Faculty and John Penix, Computer Scientist, NASA Ames Challenges in Distributed Collaborative Space Mission Design Gloria Mark, ISR Faculty ScienceOrganizer: A Collaborative Information Management Tool for Scientific Teams Richard M. Keller, Senior Computer Scientist, NASA Ames Discussion (15 mins)

12:00 - 1:00 Lunch 1:00 - 2:15 Quantification and Visualization

Palantír: Increasing Awareness among Distributed Workspaces André van der Hoek, ISR Faculty Visualizing Software Instability Jennifer Bevan, UC Santa Cruz Graduate Student Source Code Instrumentation and Quantification of Events Robert Filman, Computer Scientist, NASA Ames Visualization of Software and Development Paul Dourish, ISR Faculty Discussion (15 mins)

2:15 - 2:30 Break 2:30 - 3:45 Collaboration Studies and Tools

Exploring the Relationship between Project Selection and Requirements Analysis Mark Bergman, ISR Graduate Student

Past and Future of Postdoc Chris Knight, NASA Ames A Field Study of Collaborative Software Development Teams Cleidson de Souza, ISR Graduate Student, NASA Ames Summer Intern How do we go where no one has gone before? Issues in the development of Autonomous Operations for Space Kanna Rajan, NASA Ames Discussion (15 mins)

3:45 - 4:00 Break 4:00 - 5:00 Architecture and Synthesis

US/France Coalition Warfare as a Model of Dynamic Architectures for Cross-Organizational Software Engineering Richard N. Taylor, ISR Director and Faculty (no slides available) Formal Peer Inspection Information Architecture Gilda Pour, Faculty, San Jose State University Software Design Modelling and Code Generation Tools Jon Whittle, Computer Scientist, NASA Ames (no slides available) Discussion (15 mins)

Tuesday, August 6 9:30 - 11:30 Event Infrastructure and Wrap up

From Simulation to Implementation - An overview of the Brahms Research and its application to Work Practice Analysis and Software Agents Maarten Sierhuis, Senior Scientist, NASA Ames Event-notification and Messaging Architectures for Real-time Science Coordination Elias Sinderson, UC Santa Cruz Graduate Student, NASA Ames Summer Intern Using Event Notification Servers to Support Awareness David Redmiles, ISR Faculty

Discussion on Common Themes (1 hr 15 mins) Moderated by David Redmiles and John Penix

11:30 - 12:30 Lunch

After lunch, a subset of people will meet to make future plans. Subset includes David Redmiles, John Penix, Michael Kantor, Susan Knight, Debra Brodbeck, at least 1 more UCI faculty, and 1 or more NASA or JPL people.

Participants NASA Ames

• Martha DelAlto, md@ptolemy.arc.nasa.gov • David Bell, dbell@arc.nasa.gov • Robert Filman, Computer Scientist, rfilman@arc.nasa.gov • Rich Keller, Senior Computer Scientist, rkeller@arc.nasa.gov • Chris Knight, Computer Scientist, cknight@mail.arc.nasa.gov • Jeff Lee, jmlee@arc.nasa.gov • Kenneth I. Laws, klaws@email.arc.nasa.gov • Masoud Mansouri-Samani, masoud@email.arc.nasa.gov • Larry Markosian, zaven@email.arc.nasa.gov • Peter Mehlitz, pcmehlitz@email.arc.nasa.gov • Owen O'Malley, Computer Scientist, owen@email.arc.nasa.gov • Joan Pallix, jpallix@mail.arc.nasa.gov • John Penix, Computer Scientist and Workshop Organizer,

jpenix@ptolemy.arc.nasa.gov • Tom Pressburger, ttp@email.arc.nasa.gov • Kanna Rajan, Senior Researcher, kanna@ptolemy.arc.nasa.gov • David Roland, droland@mail.arc.nasa.gov • John Shupe, jshupe@mail.arc.nasa.gov • Maarten Sierhuis, Senior Scientist, msierhuis@mail.arc.nasa.gov • Jon Whittle, Computer Scientist, jonathw@ptolemy.arc.nasa.gov

ISR/UCI

• Mark Bergman, Graduate Student, mbergman@ics.uci.edu • Debra Brodbeck, ISR Technical Relations Director, brodbeck@uci.edu • Eric Dashofy, Graduate Student, edashofy@ics.uci.edu • Cleidson R. B. de Souza, Graduate Student, cdesouza@ics.uci.edu (currently on

summer Internship at NASA Ames) • Paul Dourish, Faculty, jpd@ics.uci.edu • Roberto S.S. Filho, Graduate Student, rsilvafi@ics.uci.edu • Michael Kantor, Post-Doctoral Researcher, mkantor@ics.uci.edu • Susan Knight, ISR Corporate Relations Officer, sknight@uci.edu • Gloria Mark, Faculty, gmark@ics.uci.edu

• David Redmiles, Faculty and Workshop Organizer, redmiles@ics.uci.edu

• Richard Taylor, ISR Director and Faculty, taylor@uci.edu • André van der Hoek, Faculty, andre@ics.uci.edu

ISR/UC Santa Cruz

• Jennifer Bevan, Graduate Student, jbevan@cse.ucsc.edu • Elias Sinderson, Graduate Student and NASA Ames Summer Intern (2002),

elias@cse.ucsc.edu Other

• Dale Martin, Clifton Labs, Inc., dmartin@cliftonlabs.com • Lantz Moore, Senior Software Engineer, Clifton Labs, Inc.,

lmoore@cliftonlabs.com • Gilda Pour, Faculty, San Jose State University and NRC Research Associate,

NASA Ames, gpour@email.sjsu.edu • Jason Robbins, Collab.Net, Inc., jrobbins@collab.net

Wo

rksh

op

on

Co

lla

bo

rati

ve

So

ftw

are

En

gin

ee

rin

g T

oo

ls

John

Pen

ixCo

mpu

ter

Scie

ntis

tN

ASA

Am

es

Dav

id R

edm

iles

Ass

ocia

te P

rofe

ssor

UC

Irvi

ne /

ISR

Deb

ra B

rodb

eck

Tech

nica

l Rel

atio

ns D

irec

tor

UC

Irvi

ne /

ISR

Goals

and

Scop

e of

the

Wor

ksho

p

�U

nder

stan

ding

Col

labo

rati

on a

nd S

oftw

are

Tool

s�

Real

wor

ld s

etti

ng in

form

ed b

y re

sear

ch�

Mut

ual E

duca

tion

�A

spec

ts o

f th

e Sc

ope

�D

iffi

cult

ies

in s

tudy

ing

and

supp

orti

ng c

olla

bora

tion

�N

ASA

Pro

blem

s an

d O

ppor

tuni

ties

�U

CI R

esea

rch

Tech

nolo

gy, S

tudi

es, a

nd O

ppor

tuni

ties

Logist

ics

�Se

ssio

ns�

Usu

ally

1 h

our

15 m

inut

es�

Talk

s ar

e 15

min

utes

incl

udin

g cl

arif

ying

ques

tion

s�

15 m

inut

es o

f di

scus

sion

�Br

eak

for

mor

e di

scus

sion

To a

dvan

ce s

oftw

are

and

info

rmat

ion

tech

nolo

gy t

hrou

ghre

sear

ch p

artn

ersh

ips.

ISR

is t

he o

nly

orga

niza

tion

foc

used

on

Soft

ware

Res

earc

hwi

thin

the

Uni

vers

ity

of C

alif

orni

a sy

stem

.

http

://w

ww.is

r.uc

i.ed

u/

Within

the

Unive

rsity

Cont

ext…

�15

Fac

ulty

Ass

ocia

tes

�40

Ph.

D. s

tude

nts

�2

Visi

ting

Sch

olar

s�

~9 S

taff

mem

bers

(tec

hnic

al a

ndad

min

istr

ativ

e)

Facu

lty

•Ri

char

d N.

Taylor

UCI

/ICS

and

Dir

ecto

r of

ISR

•M

ark

Ack

erman

Uni

vers

ity

of M

ichi

gan

•Pa

ul D

ourish

UCI

/ICS

•Alfon

so F

ugge

tta

Polit

ecni

co d

i Mila

no•Le

s Ga

sser

Uni

vers

ity

of I

llino

is a

t U

rban

a-Ch

ampa

ign

•Alfre

d Ko

bsa

UCI

/ICS

•Gl

oria M

ark

UCI

/ICS

•Si

mon

Pen

nyU

CI/S

choo

l of

the

Art

s an

d th

e Sc

hool

of

Engi

neer

ing.

Dav

id F

. Re

dmile

sU

CI/I

CSDeb

ra J

. Ri

char

dson

UCI

/ICS

and

ICS

Dep

t. C

hair

Dav

id S

. Ro

senb

lum

UCI

/ICS

Scot

t Sa

mue

lsen

UCI

/Sch

ool o

f En

gine

erin

g an

dD

irec

tor,

Adv

ance

d Po

wer

and

Ener

gyPr

ogra

m (A

PEP)

Walt

Scac

chi

UCI

/ICS

And

ré v

an d

er H

oek

UCI

/ICS

E. J

ames

White

head

UC

Sant

a Cr

uz

Rese

arch

Emph

ases

http

://w

ww.isr

.uci.e

du/r

esea

rch.

html

�Ana

lysis

and

Tes

ting

Deb

ra J

. Ric

hard

son

Dav

id S

. Ros

enbl

um

�Co

mpu

ter

Supp

orte

d Co

oper

ative

Wor

kM

ark

Ack

erm

anPa

ul D

ouri

shA

lfre

d Ko

bsa

Glor

ia M

ark

Dav

id R

edm

iles

�Co

nfigur

ation

Man

agem

ent

And

ré v

an d

er H

oek

Jim

Whi

tehe

ad

�Dev

elop

men

t En

viro

nmen

tsD

avid

F. R

edm

iles

Dav

id S

. Ros

enbl

umD

ebra

J. R

icha

rdso

n R

icha

rd N

. Tay

lor

And

ré v

an d

er H

oek

�Hum

an-C

ompu

ter

Inte

ract

ion

Paul

Dou

rish

A

lfre

d Ko

bsa

Sim

on P

enny

Dav

id F

. Red

mile

s

�Hyp

ermed

iaA

lfre

d Ko

bsa

Dav

id F

. Red

mile

s

Rich

ard

N. T

aylo

rJi

m W

hite

head

�In

tern

et-s

cale E

vent

Not

ificat

ion

Alf

onso

Fug

gett

a D

avid

S. R

osen

blum

�Ope

n So

urce

Mar

k A

cker

man

Alf

onso

Fug

gett

aLe

s Ga

sser

W

alt

Scac

chi

Jim

Whi

tehe

ad

�So

ftwa

re A

cquisition

and

Elect

ronic

Commer

ceW

alt

Scac

chi

�So

ftwa

re A

rchite

ctur

eD

avid

F. R

edm

iles

Dav

id S

. Ros

enbl

umRi

char

d N

. Tay

lor

Sco

tt S

amue

lson

And

ré v

an d

er H

oek

�So

ftwa

re E

nginee

ring

Edu

cation

And

ré v

an d

er H

oek

�So

ftwa

re U

nder

stan

ding

Paul

Dou

rish

Dav

id F

. Red

mile

s

How

can

com

panies

get

inv

olve

d?

�Re

sear

ch P

artn

ersh

ips

enab

ling

Colla

bora

tive

Rese

arch

Tea

ms

�Ex

tern

al f

undi

ng f

rom

Gov

ernm

ent

or I

ndus

try

sour

ces

(NSF

, DoD

/DA

RPA

, NA

SA, e

tc.)

�In

tern

al f

undi

ng f

rom

Cor

pora

te P

artn

er

�Re

sear

ch A

ffili

ates

�Co

rpor

ate

spon

sore

d re

sear

ch p

roje

ct�

Grad

uate

stu

dent

res

earc

h fe

llow

ship

�IS

R re

sear

ch p

rese

ntat

ions

on-

site

�Re

sear

ch S

pons

ors

�Co

rpor

ate

affi

liati

on o

n IS

R W

eb S

ite

and

Even

ts

http

://w

ww.is

r.uc

i.edu

/

For

Mor

e In

form

ation

Deb

ra A

. Bro

dbec

kTe

chni

cal R

elat

ions

Dir

ecto

rbr

odbe

ck@

uci.e

du(9

49) 8

24-2

260

Dr.

Sus

an J

. Kni

ght

Corp

orat

e Re

lati

ons

Off

icer

skni

ght@

uci.e

du(9

49) 8

24-5

927

Tabl

e of

Cont

ents

1

Colla

bora

tive

Soft

war

e En

gine

erin

g To

ols W

orks

hop

Dr. J

ohn

Peni

x

2

RSO

Mot

ivat

ion*

_Ov

er 1

0% o

f NAS

A’s

civi

l ser

vant

and

cont

ract

or w

orkf

orce

spe

nd th

e m

ajor

ity

of th

eir

tim

e m

anag

ing,

dev

elop

ing,

assu

ring

, ver

ifyin

g, a

nd/o

r m

aint

aini

ngso

ftw

are

_NA

SA h

as in

ope

rati

on u

se (a

nd m

aint

ains

)at

leas

t 200

mill

ion

lines

of s

ourc

e co

de_

Over

$1

billi

on d

olla

rs o

f NAS

A’s

annu

al $

15bi

llion

bud

get i

s so

ftw

are

cost

* B

ased

on

estim

ates

ext

rapo

late

d fr

om a

199

3 st

udy

– so

urce

NA

SA

Chi

ef E

ngin

eer’s

Offi

ce

3

RSO

Resi

lient

Sof

twar

e En

gine

erin

gPr

ojec

t Ove

rvie

w

High

Dep

enda

bilit

yCo

mpu

ting

Inte

llige

ntSo

ftw

are

Engi

neer

ing

Tool

s

NASA

/CIC

TNS

F

ECS

Resi

lient

Sof

twar

e En

gine

erin

g

Fund

amen

tal

New

Tec

hnol

ogie

sDe

pend

abili

ty M

etri

cs a

nd

Tech

nolo

gy V

alid

atio

nTo

ol D

evel

opm

ent

and

Inse

rtio

n

Ris

k-D

irec

ted

SE T

ools

COTS

Open

Source

Dep

enda

bilit

yR

esea

rch

NASA

Mis

sion

s and

Aero

spac

eIn

dust

ry

4

RSO

Inte

llige

nt S

oftw

are

Engi

neer

ing

Too

lsGo

al

_Re

duce

mis

sion

cri

tica

l ris

ks b

y de

velo

ping

tool

s and

met

hods

to id

enti

fy a

nd e

limin

ate

soft

war

e er

rors

_So

urce

s of c

riti

cal s

oftw

are

risk

:_

Mis

unde

rsta

ndin

g re

quir

emen

ts a

nd h

ardw

are

soft

war

e in

terf

ace

_Po

or c

omm

unic

atio

n be

twee

n te

ams

_In

suffi

cien

t des

ign

and

test

ing

_In

adeq

uate

or

inap

prop

riat

e m

etho

ds a

nd p

roce

sses

Mis

hap

Caus

e Cl

assi

ficat

ion:

1/3

aer

ospa

ce m

isha

ps a

re s

oftw

are

rela

ted

Mar

s Cl

imat

e Or

bite

r

Mar

s Po

lar

Land

er

Aria

ne 5

5

RSO

Inte

llige

nt S

oftw

are

Engi

neer

ing

Too

ls A

ppro

ach

_M

atur

e ad

vanc

ed m

odel

ing

and

anal

ysis

tool

s_

Adva

nced

Sof

twar

e Ve

rific

atio

n an

d Te

stin

g_

Inte

grat

ed F

orm

al/I

nfor

mal

Req

uire

men

tsEn

gine

erin

g_

Inte

grat

e an

d le

vera

ge st

ate

of a

rt to

ol te

chno

logy

_Co

mm

erci

al a

nd o

pen

sour

ce to

ols

_Di

stri

bute

d co

llabo

ratio

n fr

amew

orks

_W

ork

wit

h m

issi

ons t

o in

fuse

too

ls in

to sp

ecifi

cpr

oces

ses:

_Ad

d ea

rly

lifec

ycle

req

uire

men

ts a

naly

sis c

apab

iliti

es_

Impr

ove

test

ing

effe

ctiv

enes

s_

Enab

le to

ol-s

uppo

rted

, dist

ribu

ted

code

rev

iew

s

6

RSO

Colla

bora

tive

Soft

war

e En

gine

erin

g To

ols

_Pr

oble

m: M

isco

mm

unic

atio

n be

twee

n te

ams i

s aco

mm

on so

urce

of c

riti

cal e

rror

s_

NASA

sof

twar

e is

oft

en d

evel

oped

by

dist

ribu

ted

mul

tidi

scip

linar

y te

ams,

com

poun

ding

this

pro

blem

_Ex

isti

ng s

oftw

are

engi

neer

ing

tool

s do

not

pro

vide

stro

ng s

uppo

rt fo

r co

llabo

rati

on_

Solu

tion

: In

sert

adv

ance

d to

ols i

nto

NASA

mis

sion

proc

esse

s by

inte

grat

ing

wit

h co

llabo

rati

vefr

amew

orks

:_

Inte

grat

ion

of th

e Ve

rific

atio

n an

d Te

stin

g To

ols

into

aco

llabo

rati

ve e

nvir

onm

ent t

o su

ppor

t col

labo

rati

veso

ftw

are

desi

gn a

nd c

ode

revi

ews

(ARC

)

7

RSO

Dist

ribu

ted

Colla

bora

tive

Sof

twar

e Re

view

s

Wor

kflo

w-d

rive

nre

view

pro

cess

Rem

ote

Expe

rts

Auto

mat

edTo

ols

Loca

lDe

velo

pers

Even

t Se

rver

Rese

arch

Issu

eIn

tegr

atin

gan

alys

is to

ols

into

pro

cess

Rese

arch

Issu

eDi

stri

buti

nghu

man

-ce

nter

edre

view

pro

cess

88

99

8

RSO

Wor

ksho

p Go

al

_Im

prov

e th

is p

rese

ntat

ion!

_W

hat a

re N

ASA’

s pr

oble

ms?

_W

hat a

re s

ome

pote

ntia

l sol

utio

ns?

_W

hat t

echn

olog

y do

we

have

that

can

pla

y a

role

?_

Wha

t res

earc

h ne

eds

to b

e do

ne?

_Ho

w d

o w

e do

that

res

earc

h?

Chal

leng

es in

Col

labo

rati

veCh

alle

nges

in C

olla

bora

tive

Spac

e M

issi

on D

esig

nSp

ace

Mis

sion

Des

ign

Glor

ia M

ark

Univ

ersi

ty o

f Cal

iforn

ia, I

rvin

e

My

Rese

arch

Inte

rest

s

•Di

stri

bute

d an

d co

lloca

ted

grou

p de

sign

wor

k

•Ho

w c

an th

e af

ford

ance

s of

a “

war

room

”in

fluen

ce c

olla

bora

tive

des

ign?

•W

hat t

echn

olog

ies c

an b

enef

it c

olla

bora

tive

desi

gn fo

r co

lloca

ted

and

dist

ribu

ted

wor

k: e

.g.

life-

size

, wal

l-si

ze H

DTV

•W

hat e

ffect

s on

des

ign

does

gro

up-t

o-gr

oup

dist

ribu

ted

colla

bora

tion

hav

e?

Two

tren

ds: d

istr

ibut

ed a

ndco

lloca

ted

desi

gn•

Colla

bora

tive

des

ign

acro

ss d

ista

nce

–Ex

ampl

es: C

AD s

hare

d ap

p: T

elef

ly s

yste

m, “

roun

d-th

e-cl

ock”

soft

war

e de

velo

pmen

t–

Empi

rica

l stu

dies

: coo

rdin

atio

n pr

oble

ms:

tran

siti

onin

g,in

tegr

atio

n, c

omm

unic

atio

n (H

erbs

leb

et a

l., 1

999;

Gri

nter

,19

98)

•Co

llabo

rati

ve d

esig

ning

in sa

me

phys

ical

envi

ronm

ent

–Ex

ampl

es: n

ew g

ener

atio

n of

ele

ctro

nic

mee

ting

roo

ms

(e.g

. i-l

and:

Str

eitz

, 199

9; in

tera

ctiv

e w

orks

pace

s:St

anfo

rd; D

isco

very

Col

labo

rato

ry: A

rias

et a

l.)–

Empi

rica

l stu

dies

: rad

ical

col

loca

tion

(Tea

sley

et a

l., 2

000;

2002

; Mar

k, 2

002)

Dyna

mic

Gro

up W

ork

Stru

ctur

es

•Fr

amew

ork

for

cons

ider

ing

grou

p w

ork

ofte

nas

sum

es “

stab

le”

team

mem

bers

hip/

stru

ctur

es

•Di

stri

bute

d an

d co

lloca

ted

grou

p w

ork

is fa

r m

ore

com

plex

:–

team

bou

ndar

ies a

re fu

zzy

–pe

ople

bel

ong

to m

ulti

ple

team

s, w

orki

ng sp

here

s–

mul

tipl

e ro

les

–so

cial

rel

atio

nshi

ps a

re d

ynam

ic

•In

“w

arro

oms”

, eve

n lo

cale

can

not d

efin

e a

team

stru

ctur

e

Som

e Ba

ckgr

ound

The

ory

•So

cial

wor

lds (

Stra

uss,

Shi

buta

ni, G

idde

ns)

•Co

-pre

senc

e (G

idde

ns)

•In

tera

ctio

n w

hen

collo

cate

d: m

onit

orin

g,ad

just

ing

beha

vior

s, c

omm

on u

se o

f art

ifact

s,et

c. –(e

.g. H

eath

and

Luf

f, Su

chm

an, H

arpe

r et

al.,

Robe

rtso

n, R

ounc

efie

ld e

t al.,

Sch

mid

t and

Wag

ner)

•So

cial

net

wor

ks

Dyna

mic

net

wor

ks w

ithi

n a

grou

p•

Som

e ty

pes

of s

ocia

l net

wor

ks–

inte

nsio

nal n

etw

orks

(Nar

di e

t al.,

in p

ress

)–

“kno

ts”

(Eng

estr

om e

t al,

1999

)–

acto

r-ne

twor

k th

eory

(Lat

our,

199

6)–

coal

itio

ns (Z

ager

, 200

0)–

virt

ual c

omm

unit

y ne

twor

ks (W

ellm

an, 1

998)

•Al

so:

–ne

twor

ks to

exc

hang

e an

d pr

oces

s in

form

atio

n ev

enw

hen

peop

le a

re c

ollo

cate

d, a

lso

dist

ribu

ted

•An

alys

is: w

ho in

tera

cts

wit

h w

ho, i

n m

ain

and

side

bar

chan

nels

of c

omm

unic

atio

n

Exam

ple

of c

ollo

cate

d de

sign

wor

kw

ith

dyna

mic

net

wor

ks•

In 1

995,

Tea

m X

form

ed a

t the

JPL

to s

erve

as

inte

rnal

cons

ulta

nts t

o NA

SA in

des

igni

ng n

ew s

pace

mis

sion

prop

osal

s, e

.g. M

ars P

robe

•Te

am X

des

igns

a c

ompl

ex sp

ace

mis

sion

in a

bout

nin

eho

urs

•Ho

w c

an p

hysi

cal c

ollo

cati

on a

nd te

chno

logy

toge

ther

ena

ble

a te

am t

o pr

oduc

e a

spac

e m

issi

onpr

opos

al in

such

a r

emar

kabl

y sh

ort t

ime?

Met

hodo

logy

Firs

t stu

dy:

•Fi

eldw

ork

obse

rvin

g w

arro

om fo

r th

ree

mon

ths

–Si

deba

r co

nver

sati

ons c

oded

–Se

vent

een

in-d

epth

sem

i-st

ruct

ured

inte

rvie

ws

–Ar

tifa

cts

colle

cted

–HD

TV e

xper

imen

t: vi

deot

apin

g, q

uest

ionn

aire

s, g

roup

inte

rvie

w

Curr

ent s

tudy

:•

Fiel

dwor

k ob

serv

ing

rem

ote

site

s–

vide

o &

aud

io ta

pes

of e

ach

rem

ote

site

, wav

e fil

es o

fre

mot

e co

nver

sati

ons

Exte

rnal

Rep

rese

ntat

ions

Used

in th

e W

arro

omRe

pres

enta

tion

Indi

vidu

alw

orks

tati

ons

Publ

ish-

subs

crib

e

Spre

adsh

eet

Orbi

t vis

ualiz

atio

npr

ogra

m

Publ

ic d

ispl

ay

Pape

r w

hite

boar

ds

Crea

tor/

Driv

er

Team

mem

ber

Enti

re te

am

Enti

re te

am

Team

lead

er

Team

lead

er

Team

mem

ber

H: F

unct

ion

Mon

itor

oth

ers’

wor

k

Info

flow

Focu

sing

age

nt

Visu

aliz

ing

info

rmat

ion

Shar

ed v

iew

Visu

aliz

ing

info

rmat

ion

Soci

al n

etw

orki

ng: s

ideb

ars

•Av

g. n

umbe

r co

ded

duri

ng th

ree-

hour

sess

ion:

98 (l

arge

var

iabi

lity)

•Ha

ve la

sted

from

few

seco

nds t

o 53

min

utes

•Av

g. e

ngin

eer

spea

ks 2

0 m

inut

es in

sid

ebar

,ra

nge

is 7

-110

min

utes

in a

thre

e-ho

ur s

essi

on.

•Si

deba

rs u

sed

to p

roce

ss in

form

atio

n fr

omsp

read

shee

t: qu

esti

on a

ssum

ptio

ns, n

egot

iate

,fin

d ot

her

opti

ons,

etc

.

Exam

ple:

Init

iati

ng N

etw

orki

ngfo

r Sp

onta

neou

s Si

deba

r

•Po

wer

to C

onfig

. Gra

phic

s: C

an w

e ge

t any

pow

er d

urin

gth

e fli

ght?

Will

the

cells

be

poin

ted

out?

Oth

erw

ise

we’

llne

ed b

ig m

onst

er b

atte

ries

.

•M

issi

on D

esig

n, T

eam

Lea

der,

Inst

rum

ents

are

spea

king

acro

ss r

oom

to e

ach

othe

r

•St

ruct

ures

ove

rhea

rs P

ower

and

Con

fig. G

raph

ics

and

join

s the

m

•AC

S ov

erhe

ars

and

join

s co

nver

sati

on fr

om a

cros

s th

ero

om.

•…

……

.

An E

xplo

rato

ry S

tudy

Usi

ng L

ife-

size

HDT

V w

ith

Team

X•

Larg

e 12

8” x

72”

scre

en sh

owin

g HD

TV a

s a “

win

dow

”to

show

act

ivit

y be

twee

n ro

oms +

aud

io

•Te

am X

split

into

two

room

s

•Re

al sp

ace

shut

tle

mis

sion

pro

posa

l

•Te

leph

ones

, wit

h ph

one

num

bers

, to

supp

ort s

ideb

ars

•Da

y 1:

aud

io d

irec

tly

sent

in, v

ideo

sen

t thr

ough

Gig

abit

E

ther

net (

.8 se

cond

lag)

•Da

y 2:

bot

h au

dio

and

vide

o se

nt th

roug

h Gi

gabi

tEt

hern

et

(d

egra

ded

audi

o)

The

Pote

ntia

l of H

igh

Tele

pres

ence

•Vi

deo

used

as m

eans

for

obse

rvin

g ac

tivi

ty in

rem

ote

room

: not

as g

ood

for

supp

orti

ng“n

etw

orki

ng”

–<

20%

of t

he ti

me,

vid

eo u

sed

for

side

bars

–“D

iffic

ult t

o ho

ld a

loca

l sid

ebar

with

out d

istu

rbin

g pe

ople

in o

ther

roo

m”

–A

lear

ning

cur

ve m

ay e

xist

–Re

quir

emen

ts fo

r si

deba

rs a

cros

s dis

tanc

e:•

Need

to u

nder

stan

d w

ho to

spea

k w

ith

•Ne

ed se

amle

ss w

ay to

con

nect

Netw

orks

at w

ork

in c

ollo

cate

den

viro

nmen

ts

•Ne

twor

ks in

col

loca

ted

wor

k ea

sily

bre

ak d

own

over

dis

tanc

e w

ith

the

wro

ng te

chno

logy

supp

ort

•De

licat

e ba

lanc

e of

aut

om

atio

n an

d hu

man

proc

essi

ng

•To

o m

uch

auto

mat

ion

ease

s loa

d, b

ut m

ayre

mov

e op

port

unit

y fo

r cr

eati

vity

in d

esig

n

•Fl

exib

ility

is k

ey: t

o m

ove

back

and

fort

h be

twee

nel

ectr

onic

and

soci

al n

etw

ork

Curr

ent W

ork:

Gro

up-t

o-Gr

oup

Dist

ribu

ted

Colla

bora

tive

Des

ign

•W

here

as d

istr

ibut

ed te

ams m

ight

be

cons

ider

ed a

“sp

here

of w

ork”

, wha

t hap

pens

whe

n di

ffere

nt “

sphe

res o

f wo

rk”

colla

bora

te?

•St

udyi

ng J

PL, M

arsh

all,

Glen

n, S

andi

a, b

egan

Apri

l 200

2

•Fo

ur fo

cii:

–Re

quir

emen

ts: c

once

ptio

n as

wel

l as

func

tion

–In

form

atio

n flo

w–

Soci

al n

etw

orki

ng–

Tech

nolo

gy u

se

Oppo

rtun

itie

s fo

r Ne

wTe

chno

logi

es to

Sup

port

Dist

ribu

ted

Wor

k

•Ho

w c

an w

e le

vera

ge p

eopl

e’s a

bilit

y to

mon

itor

othe

rs’ w

ork?

•Se

amle

ss su

ppor

t for

side

bar

conv

ersa

tion

s(i

nten

tion

al a

nd s

pont

aneo

us) w

itho

ut o

verl

oad

of in

form

atio

n

•Ex

tern

al r

epre

sent

atio

ns th

at c

aptu

re th

e de

sign

ratio

nale

, not

just

the

resu

lt

•…

….s

till

wor

king

…

Than

ks to

….

•Pa

ul D

eFlo

rio,

Bob

Obe

rto,

Reb

ecca

Whe

eler

,JP

L

•Te

am X

•Cu

rren

t stu

dy: S

teve

Abr

ams,

Dou

g Gr

imes

,Na

yla

Nass

if

Co

llab

ora

tive

So

ftw

are

En

gin

eeri

ng

Wo

rksh

op

Ric

har

d M

. Kel

ler,

Ph

.D.

Sci

ence

Org

aniz

er:

A C

olla

bora

tive

Info

rmat

ion

Man

agem

ent T

ool f

or S

cien

tific

Tea

ms

Info

rmat

ion

Sh

arin

g a

nd

Inte

gra

tio

n G

rou

pC

olla

bo

rati

ve a

nd

Ass

ista

nt

Sys

tem

s T

ech

Are

aC

om

pu

tati

on

al S

cien

ces

Div

isio

nN

AS

A A

mes

Res

earc

h C

ente

r

Rich

Kel

ler

Shaw

n W

olfe

Davi

d Ha

ll, Q

SSRo

bert

Car

valh

oSt

eve

Rich

, SAI

CDe

epak

Kul

karn

iDa

n Be

rrio

s, R

IACS

Sci

ence

Des

k P

roje

ct S

taff

Com

puta

tiona

l Sci

ence

s D

ivis

ion

NA

SA

Am

es R

esea

rch

Cen

ter

Serg

ey Y

entu

s, Q

SSKe

ith

Swan

son

Ian

Stur

ken,

QSS

Ling

-Jen

Chi

ang,

QSS

Davi

d Ni

shik

awa

Lind

a An

drew

s, R

IACS

WW

W

Info

rmat

ion

arch

ivin

g an

dsh

arin

gIm

ages

, Mod

els,

Doc

umen

ts, D

ata,

Not

es, p

lus

orga

niza

tion

, ret

riev

al, i

ndex

ing,

ann

otat

ion,

and

thre

adin

g se

rvic

es

Colla

bora

tion

/Coo

rdin

atio

n/Co

mm

unic

ati

on

Serv

ices

Cons

ulta

tion

tool

s, W

orkf

low

, Cal

enda

rs, G

roup

and

Res

ourc

eSc

hedu

ling,

Aw

aren

ess,

Em

ail d

istr

ibut

ion

and

arch

ivin

g,Vi

deo/

audi

o co

nfer

enci

ng, C

hat

Rem

ote

cont

rol o

fSc

ient

ific

Inst

rum

ents

Mon

itor

ing,

con

trol

, and

exp

erim

enta

tion

WW

WW

WW

WW

W

Inte

rnetIn

tern

et

Inte

rnet

Inte

rnet

Sci

ence

Des

k P

roje

ct:

Sci

ence

Des

k P

roje

ct: I

nfr

astr

uct

ure

Infr

astr

uct

ure

sup

po

rt f

or

dis

trib

ute

d s

cien

tifi

c te

ams

sup

po

rt f

or

dis

trib

ute

d s

cien

tifi

c te

ams

Res

earc

h A

reas

•• S

cien

tifi

c K

no

wle

dg

e M

anag

emen

t S

cien

tifi

c K

no

wle

dg

e M

anag

emen

t ::ca

ptu

re,

cap

ture

,

pre

serv

atio

n, t

race

abili

ty o

f sc

ien

tifi

c kn

ow

led

ge

pre

serv

atio

n, t

race

abili

ty o

f sc

ien

tifi

c kn

ow

led

ge

••In

telli

gen

t In

form

atio

n A

cces

sIn

telli

gen

t In

form

atio

n A

cces

s ::in

telli

gen

t in

dex

ing

,in

telli

gen

t in

dex

ing

,

visu

aliz

atio

n, a

nd

nav

igat

ion

visu

aliz

atio

n, a

nd

nav

igat

ion

••C

olla

bo

rato

ries

Co

llab

ora

tori

es::

asyn

chro

no

us

and

syn

chro

no

us

asyn

chro

no

us

and

syn

chro

no

us

colla

bo

rati

ve s

cien

tifi

c te

amw

ork

colla

bo

rati

ve s

cien

tifi

c te

amw

ork

••A

gen

t-as

sist

ed R

emo

te E

xper

imen

tati

on

Ag

ent-

assi

sted

Rem

ote

Exp

erim

enta

tio

n::

inte

llig

ent

mo

nit

ori

ng

an

d c

on

tro

lin

telli

gen

t m

on

ito

rin

g a

nd

co

ntr

ol

htt

p:/

/sci

ence

des

k.ar

c.n

asa.

go

v

Fiel

d R

esea

rch

Site

s

Hom

e In

stitu

tions

Fie

ld D

ata

Col

lect

ion

&

Pre

limin

ary

Dat

a A

naly

sis

U. C

onn

Am

es R

esea

rch

Cen

ter

Fiel

dSa

mpl

esG

eolo

gica

lSa

mpl

es

Biol

ogic

alSa

mpl

es

Mic

robi

al C

ultu

res

Oth

er c

ultu

reco

llect

ions

Yel

low

ston

eN

atio

nal P

ark

Mic

rosc

op

y L

ab

Gre

enh

ou

se

Baj

a C

alif

orni

a,M

exic

o

Hig

hbor

ne C

ay,

Bah

amas

U. M

iam

i

Ari

zona

Sta

te

Por

tlan

d St

ate

Mic

rob

ial

Cu

ltu

re F

acili

ty

Mic

rob

iolo

gy

Lab

Mo

tiva

tio

n:

Dis

trib

ute

d S

cien

tifi

cF

ield

an

d L

ab W

ork

U. o

f O

rego

n

• fi

eld

no

tes

• im

ages

• m

easu

rem

ents

• se

nso

r d

ata

• la

b n

ote

s an

d e

xper

imen

t d

ata

• el

ectr

on

mic

rosc

op

e im

ages

• an

alys

is r

esu

lts

• p

ub

licat

ion

s

Scie

nceO

rgan

izer

Info

rmat

ion

Repo

sito

ryFi

eld

Res

earc

h Si

tes

Hom

e In

stitu

tions

U. C

onn

Am

es R

esea

rch

Cen

ter

Yel

low

ston

eN

atio

nal P

ark

Mic

rosc

op

y L

ab

Gre

enh

ou

se

Baj

a C

alif

orni

a,M

exic

o

Hig

hbor

ne C

ay,

Bah

amas

U. M

iam

i

Ari

zona

Sta

te

Por

tlan

d St

ate

Mic

rob

ial

Cu

ltu

re F

acili

ty

Mic

rob

iolo

gy

Lab

U. o

f O

rego

n

Ce

ntra

l

Re

posi

tory

• Im

ages

• M

easu

rem

ents

• Cu

ltur

es•

Data

sets

• Do

cum

ents

• Re

cord

s

Wh

at is

Sci

ence

Org

aniz

er?

• A

n in

form

atio

n r

epo

sito

ry /

dig

ital

lib

rary

fo

r d

istr

ibu

ted

scie

nti

fic

pro

ject

tea

ms:

sto

res

hete

roge

neou

s pr

ojec

tin

form

atio

n pr

oduc

ts -

- im

ages

, dat

aset

s, d

ocum

ents

, and

vario

us ty

pes

of s

cien

tific

rec

ords

(des

crib

ing

sam

ples

, fie

ld s

ites,

mea

sure

men

ts, i

nstr

umen

ts, m

icro

bial

cul

ture

s, e

tc.)

• A

hyb

rid

to

ol c

om

bin

ing

th

e fu

nct

iona

lity

of:

• a

data

base

• a

docu

men

t-sh

arin

g sy

stem

• a

hype

rmed

ia in

form

atio

n sp

ace

• a

sem

antic

net

wor

k

• F

eatu

res

cro

ss-l

inka

ge:

ena

bles

rap

id a

cces

s to

inte

rrel

ated

info

rmat

ion

• A

“p

roje

ct m

emo

ry”

syst

em:

trac

ks h

isto

ry o

f pro

ject

team

’s fi

eldw

ork,

labw

ork,

and

ass

ocia

ted

data

col

lect

ion

activ

ities

Th

e S

cien

ceO

rgan

izer

“Pro

ject

Info

rmat

ion

Web

”

Sci

ence

Org

aniz

er m

ain

tain

s p

roje

ct in

form

atio

n in

an in

terc

on

nec

ted

net

wo

rk o

r “i

nfo

rmat

ion

web

”

pro

ject

imag

e

mea

sure

men

tsi

te

inst

rum

ent

sam

ple

do

cum

ent

• N

odes

: inf

orm

atio

n re

sour

ces

• Li

nks:

rela

tions

hips

am

ong

reso

urce

s

Sem

antic

hyp

erm

edia

sys

tem

Info

rmat

ion

Res

ou

rces

(“n

od

es”)

• De

scri

be v

ario

us ty

pes o

f pro

ject

-spe

cific

info

rmat

ion:

Peop

le, P

lace

s, E

vent

s, D

evic

es, M

easu

rem

ents

(e.g

., fie

ld s

ites

, lab

s, tr

ips,

sam

ples

, im

ages

, doc

umen

ts, i

nstr

umen

ts e

tc.)

• Co

ntai

n m

etad

ata

(cat

egor

ical

, tex

t, or

num

eric

)•

Can

have

“at

tach

ed”

files

(e.g

., im

ages

, doc

umen

ts, d

atas

ets)

Mic

robi

al-M

at-S

ampl

e -6

54C

olle

cted

-by:

S. J

ones

Col

lect

ion

date

: 1/

24/0

0C

olle

ctio

n si

te:

Pon

d 6:

fiel

d4:

…M

icro

bial

-Cul

ture

-123

Cul

tiva

ted-

by:

R. S

mit

h

Gen

us:

mic

roco

leus

ch.

Gro

wth

med

ium

: A

SN

Dat

e is

olat

ed:

03-0

4-00

fiel

d5:

...

SEM

-Im

age

-654

Tak

en-b

y: R

.Sm

ith

Imag

e da

te:

1/24

/00

Equ

ipm

ent:

Imag

e F

ile:

Exa

mp

les

of

Info

rmat

ion

Res

ou

rces

:

Info

rmat

ion

Res

ourc

es

proj

ect

mea

sure

men

tno

teim

agedo

cum

entcu

ltur

e

pers

on

site

sam

ple

expe

rim

ent

equi

pmen

t

cam

era

gas

chro

mat

ogra

ph

stub

O2

mic

rose

nsor

N2

mic

rose

nsor

phot

ogra

phic

imag

e

SEM

imag

e

SEM

O2

conc

entr

atio

n

N2

conc

entr

atio

n

Typ

es o

f S

cien

ceO

rgan

izer

“In

form

atio

n R

eso

urc

es”

(par

tial

)

spec

trom

eter

spec

trog

raph

chro

mat

ogra

m

othe

r

othe

r

othe

r

mic

rogr

aph

Rel

atio

nsh

ips

amo

ng

Res

ou

rces

(“lin

ks”)

• In

form

atio

n Re

sour

ces

are

inte

rrel

ated

by

mea

ns o

f nam

ed li

nks

that

cha

ract

eriz

e th

e na

ture

of t

he r

elat

ions

hip

• Re

lati

onsh

ips

are

cust

omiz

ed to

a p

roje

ct te

am b

ased

on

an a

naly

sis

of th

e in

form

atio

n re

sour

ces

in th

e sc

ient

ific

dom

ain

Mic

robi

al-M

at-S

ampl

e -6

54

Col

lect

ed-b

y: S

. Jon

esC

olle

ctio

n da

te:

1/24

/00

Col

lect

ion

site

: P

ond

6:fi

eld4

: …

Mic

robi

al-C

ultu

re-1

23C

ulti

vate

d-by

: R

. Sm

ith

Gen

us:

mic

roco

leus

ch.

Gro

wth

med

ium

: A

SN

Dat

e is

olat

ed:

03-0

4-00

fiel

d5:

...

SEM

-Im

age

–123

x

Tak

en-b

y: R

.Sm

ith

Imag

e da

te:

1/24

/00

Equ

ipm

ent:

Imag

e F

ile:

culti

vate

d-fr

om

pic

ture

d-i

n

imag

esa

mpl

e

cult

ure

phot

ogra

phic

imag

e

SEM

imag

e

San

ctio

ned

Lin

ks b

etw

een

“cu

ltu

re”

and

oth

er t

ypes

of

reso

urc

es

stub

equi

pmen

t

mo

un

ted

-on

pic

ture

d-i

ncult

ivat

ed-f

rom

pers

on

imag

e (o

ther

)

docu

men

t

has

-med

ium

-rec

ipe

UR

L

has

-gen

etic

-seq

uen

ce-U

RL

iso

late

d-b

ype

rson

cult

ivat

ed-b

y

Evol

ving

Web

of P

roje

ctIn

form

atio

n

member-of

site-for

found-at

collected-by has-measurement

produced-by

cultivated-

from

pictured-in pr

oduced-by

has-recipe

pro

ject

:

site

:

do

cum

ent:

sam

ple

:

mea

sure

men

t:S

EM

imag

e:

equ

ipm

ent:

equ

ipm

ent:

per

son

:

: cu

ltu

re

EMER

G

Brad

B.

Pond

3 n

ear

4

ASN

med

ium

rec

ipe

O2 m

icro

sens

orSE

M

MC-

123

SEM

imag

e 12

3xO2

con

cent

rati

on 3

2B

Pro

ject

Info

rmat

ion

in c

onte

xt

Mat

654

Proj

ect

Info

rmat

ion

Reco

rd

Link

s to

Rela

ted

Reco

rds

• im

ages

• da

tase

ts•

cultu

res

• sa

mpl

es•

field

site

s•

mea

sure

men

ts•

inst

rum

ents

• la

b no

tes

• pu

blic

atio

ns•

spre

adsh

eets

• co

nven

ient

navi

gati

on•

pred

efin

edlin

ks•

info

rmat

ion

trac

ebac

k

cre

ate

new

links

cre

ate

new

reco

rds

mod

ify r

ecor

ds

data

field

s

icon

iden

tifie

sre

cord

type

clic

k to

nav

igat

e

Web

-bas

ed,

plat

form

inde

pend

ent a

cces

s

sear

ch fo

r re

cord

s

Scie

nceO

rgan

izer

Bro

wse

r

Inte

rfac

ing

So

ftw

are

Sci

ence

Org

aniz

er

Sh

ared

Imag

eA

nn

ota

tor

Mic

rose

nso

rR

emo

te C

on

tro

ller

sen

sor

imag

e

ann

ota

ted

imag

e

Mic

roso

ft O

ffic

e in

terf

ace

real

-tim

em

easu

rem

ents

,im

ages

Ag

ent-

assi

sted

Sci

enti

fic

Exp

erim

enta

tio

n S

yste

m

do

cum

ents

Mar

sE

xplo

rati

on

Sim

ula

tor

Sp

arro

w W

ebIn

terf

ace

imag

es,

mea

sure

men

ts

Sci

ence

Org

aniz

er

Sh

ared

Imag

e A

nn

ota

tor

Co

llab

ora

tive

Wh

iteb

oar

din

g &

An

no

tati

on

To

ol

Mic

rose

nso

rM

icro

sen

sor

Rem

ote

Co

ntr

olle

r R

emo

te C

on

tro

ller

O2

Mic

rose

nso

r &

po

siti

on

ing

tab

le

Sci

ence

Org

aniz

er

1

2

3

Sav

e to

Org

aniz

er

Low

nut

rient

Mat

fro

m P

ond

1A

Scie

nceO

rgan

izer

agen

t

Expe

rim

ent D

ata

Repo

sito

ry

Expe

rim

enta

tion

ag

ent

Scie

nce

team

Rem

ote

cont

rol

posi

tion

ing

tabl

e w

/in

stru

men

t pac

kage

Ag

ent-

assi

sted

Sci

enti

fic

Exp

erim

enta

tio

n S

yste

m

• ov

eral

l e

xper

imen

t c

oord

inat

ion

Scie

ntis

t’s

agen

t

Gree

nhou

seag

ent

• sc

hedu

ling

• er

ror

mon

itor

ing

• ex

peri

men

t req

uest

s •

user

not

ifica

tion

• us

er p

refe

renc

es

• da

ta s

tora

ge•

logg

ing

Scie

nce

Orga

nize

r

Expe

rim

ent

Setu

p/M

onit

orin

g In

terf

ace

Pilo

t Use

rs:

• AR

C M

icro

bial

Eco

syst

ems G

roup

• NA

I Eco

geno

mic

s Foc

us G

roup

• EC

S M

isha

p In

vest

igat

ion

• AR

C El

ectr

on M

icro

scop

y La

b•

JSC

Astr

obio

logy

Inst

itut

e fo

r th

e St

udy

ofBi

omar

kers

• NI

H/NA

SA M

alar

ia C

ontr

ol S

tudy

(via

Fund

amen

tal B

iolo

gy P

rogr

am)

• M

ars s

imul

atio

n an

d an

alog

stu

dies

(via

Mob

ile A

gent

s Pro

ject

)•

ASU/

NSF

Dese

rt M

icro

bial

Sur

vey

Sci

ence

Org

aniz

er C

ust

om

ers

mo

rem

atu

re

less

mat

ure

2510

125

Use

rs•F

requ

ent

•Mod

erat

e•I

nfre

quen

t

95

Pala

ntír

: Inc

reas

ing

Aw

aren

ess

amon

g D

istr

ibut

ed C

MW

orks

pace

s

Pala

ntír

: Inc

reas

ing

Aw

aren

ess

amon

g D

istr

ibut

ed C

MW

orks

pace

s

Andr

é va

n de

r Ho

ek, A

nita

Sar

ma

Inst

itut

e fo

r So

ftw

are

Rese

arch

Univ

ersi

ty o

f Cal

iforn

ia, I

rvin

e{a

ndre

,asa

rma}

@ic

s.uc

i.edu

A T

ypic

al D

evel

opm

ent S

cena

rio

A T

ypic

al D

evel

opm

ent S

cena

rio

CMre

posi

tory

Pete

’s w

orks

paceC

BA

Elle

n’s w

orks

pace

EC

D

Dir

ect C

onfli

cts

Dir

ect C

onfli

cts

CMre

posi

tory

Pete

’s w

orks

paceC

BA

Elle

n’s w

orks

pace

EC

D

Over

lapp

ing

chan

ges t

o th

e sa

me

arti

fact

Indi

rect

Con

flict

sIn

dire

ct C

onfli

cts CM

repo

sito

ry

Pete

’s w

orks

paceC

BA

Elle

n’s w

orks

pace

EC

D

Chan

ges

to o

ne a

rtifa

ct m

odify

ing

the

beha

vior

of a

noth

er a

rtifa

ct

Tra

diti

onal

CM

App

roac

hes

Tra

diti

onal

CM

App

roac

hes

�Pe

ssim

isti

c–

An a

rtifa

ct c

an b

e ch

ange

d by

onl

yon

e pe

rson

at a

ny o

ne ti

me

–Li

mit

ed in

not

allo

win

g an

y pa

ralle

lw

ork

�Op

tim

isti

c–

An a

rtifa

ct c

an b

e ch

ange

d by

man

ype

rson

s at

the

sam

e ti

me

–Li

mit

ed in

lead

ing

to m

erge

pro

blem

sth

at n

eed

to b

e re

solv

ed m

anua

lly

Tra

diti

onal

CM

App

roac

hes

Tra

diti

onal

CM

App

roac

hes

�Pe

ssim

isti

c–

An a

rtifa

ct c

an b

e ch

ange

d by

onl

y on

epe

rson

at a

ny o

ne ti

me

–Li

mit

ed in

not

allo

win

g an

y pa

ralle

l wor

k

�Op

tim

isti

c–

An a

rtifa

ct c

an b

e ch

ange

d by

man

y pe

rson

sat

the

sam

e ti

me

–Li

mit

ed in

lead

ing

to m

erge

pro

blem

s tha

tne

ed to

be

reso

lved

man

ually

Neit

her

solu

tion

add

ress

es d

irec

t and

indi

rect

con

flict

s ver

y w

ell,

espe

cial

ly in

a d

istr

ibut

ed a

nd d

ecen

tral

ized

sett

ing

Key

Obs

erva

tion

Key

Obs

erva

tion

�A

CM w

orks

pace

in r

ealit

y pr

ovid

estw

o ki

nds

of is

olat

ion:

–Go

od is

olat

ion

�Hi

des a

ctua

l cha

nges

to a

rtifa

cts

–Ba

d is

olat

ion

�Hi

des k

now

ledg

e of

wha

t art

ifact

s oth

erde

velo

pers

are

cha

ngin

g

App

roac

hA

ppro

ach

�Co

ntin

uous

wor

kspa

ce a

war

enes

s–

Whi

ch a

rtifa

cts

are

bein

g ch

ange

d by

who

m?

–W

hat i

s the

sev

erity

of t

he c

hang

es?

(am

ount

/siz

e of

cha

nge

bein

g m

ade)

–W

hat i

s the

impa

ct o

f the

cha

nges

?(e

ffect

of c

hang

es o

n on

e’s

curr

ent

wor

k)�

Such

aw

aren

ess h

as t

he p

oten

tial

tosi

gnifi

cant

ly r

educ

e th

e nu

mbe

r of

dire

ct a

nd in

dire

ct c

onfli

cts

Pala

ntír

Arc

hite

ctur

ePa

lant

ír A

rchi

tect

ure

CMre

posi

tory

Pete

’s w

orks

pace

CB

AEl

len’

s wor

kspa

ceE

CD

CM c

lient

CM s

erve

rCM

clie

ntEv

ent w

rapp

erEv

ent w

rapp

erEv

ent w

rapp

er

Pete

’s V

iew

of th

e W

orld

Seve

rity

/im

pact

anal

ysis

Elle

n’s V

iew

of th

e W

orld

Pete

’sVi

sual

izat

ion

Elle

n’s

Visu

aliz

atio

n

Popu

lati

ng a

Wor

kspa

cePo

pula

ting

a W

orks

pace

Mak

ing

Cha

nges

in th

e W

orks

pace

Mak

ing

Cha

nges

in th

e W

orks

pace

Com

mit

ting

Cha

nges

Com

mit

ting

Cha

nges

Mor

e C

hang

es (b

y O

ther

Dev

elop

ers)

Mor

e C

hang

es (b

y O

ther

Dev

elop

ers)

Etc

., E

tc.,

Etc

…E

tc.,

Etc

., E

tc…

Vis

ualiz

atio

n Fe

atur

esV

isua

lizat

ion

Feat

ures

�Di

ffere

nt v

iew

s w

ith

diffe

rent

trad

e-of

fs–

Amou

nt o

f inf

orm

atio

n ve

rsus

leve

l of i

ntru

sive

ness

–Sc

roll-

bar,

tabu

lar,

fully

gra

phic

al�

Conf

igur

able

–Se

lect

ion

of r

elev

ant d

evel

oper

s, e

vent

s, ti

mef

ram

es�

Scal

able

–In

tern

al d

ata

stru

ctur

e ve

rsus

act

ual v

isua

lizat

ion

–Pa

ir-w

ise

wor

kspa

ces

–So

rtin

g pe

r se

veri

ty o

r ch

ange

impa

ct�

Exte

nsiv

e m

etad

ata

Seve

rity

Ana

lysi

sSe

veri

ty A

naly

sis

�Am

ount

(siz

e) o

f cha

nge

bein

g m

ade

�Pr

opos

ed a

lgor

ithm

s–

Num

ber

of fi

les

�Si

mpl

e, b

ut in

accu

rate

–Li

nes

of c

ode

�Si

mpl

e, b

ut in

accu

rate

–To

ken

base

d di

ffere

nce

�M

easu

res s

truc

tura

l cha

nges

, but

lang

uage

depe

nden

t–

Abst

ract

synt

ax tr

ee�

Very

det

aile

d an

alys

es, b

ut li

kely

too

expe

nsiv

e(a

nd la

ngua

ge d

epen

dent

)�

Curr

ent w

ork

in p

rogr

ess

Impa

ct A

naly

sis

Impa

ct A

naly

sis

�Ef

fect

of c

hang

es o

n on

e’s

curr

ent w

ork

�Pr

opos

ed a

lgor

ithm

s–

Over

lapp

ing

num

ber

of fi

les

�Si

mpl

e, b

ut in

accu

rate

–Ov

erla

ppin

g lin

es o

f cod

e�

Sim

ple,

but

inac

cura

te–

Chan

ged

inte

rfac

es�

Pote

ntia

lly a

ccur

ate

and

effe

ctiv

e, b

ut la

ngua

gede

pend

ent

–De

pend

ency

ana

lysi

s�

Very

pre

cise

, sem

anti

c re

sult

s, b

ut c

ompl

ex (a

ndla

ngua

ge d

epen

dent

)�

Curr

ent w

ork

in p

rogr

ess

Con

clus

ions

Con

clus

ions

�Pa

lant

ír is

a p

roto

type

that

…–

…br

ings

aw

aren

ess

to d

istr

ibut

ed C

M w

orks

pace

s–

…sh

ows

pair

-wis

e co

nflic

t–

…pr

ovid

es s

ever

ity

and

impa

ct a

naly

ses

�Pa

lant

ír is

inde

pend

ent o

f the

type

of C

Msy

stem

use

d�

Use

of P

alan

tír

resu

lts i

n fe

wer

dir

ect a

ndin

dire

ct c

onfli

cts

–Ca

se st

udy

to b

e pl

anne

d in

nea

r fu

ture

�Fu

ture

wor

k–

Inte

grat

e w

ith

diffe

rent

CM

sys

tem

s–

Impl

emen

t sev

erit

y an

d im

pact

ana

lysi

s al

gori

thm

sfo

r bo

th a

tom

ic a

nd c

ompo

und

arti

fact

s–

Deve

lop

addi

tion

al v

isua

lizat

ions

Res

earc

h Pr

ojec

tsR

esea

rch

Proj

ects

Impl

emen

tati

onIm

plem

enta

tion

Depl

oym

ent

Depl

oym

ent

Syst

em T

esti

ngSy

stem

Tes

ting

Run-

Tim

eRu

n-Ti

me

Desi

gnDe

sign

Com

pone

nts

Com

pone

nts

Sour

ce F

iles

Sour

ce F

iles

Feat

ures

Feat

ures

Syst

ems

Syst

ems

Exec

utab

les

Exec

utab

les

Vers

ione

d Co

mpo

nent

s (A

rchi

tect

ure)

SRM

xADL

2.0

Arch

View

Arch

Diff

NUCM

Wre

nTW

ICS

Émig

réM

énag

e

Pala

ntír

IVA:

Vis

ualiz

ing

Softw

are

Inst

abilit

y

Jenn

ifer B

evan

Uni

vers

ity o

f Cal

iforn

ia, S

anta

Cru

z

Jbev

an@

soe.

ucsc

.edu

Prob

lem

: Sof

twar

e D

ecay

•So

ftwar

e de

cays

as

a re

sult

of in

com

patib

ilites

betw

een

the

oper

atin

g en

viro

nmen

t and

the

impl

emen

ted

artif

act.

–Fa

ilure

to m

eet r

equi

rem

ents

, spe

cify

acc

urat

ere

quire

men

ts, o

r ant

icip

ate

chan

ges

in re

quire

men

ts.

•Th

e ex

istin

g so

ftwar

e ar

chite

ctur

e ca

n hi

nder

the

effe

ctiv

enes

s of

the

mai

nten

ance

pro

cess

.–

“gol

den

hand

cuffs

”, in

trans

igen

t cod

e.

Hyp

othe

sis

and

Prop

osal

•H

ypot

hesi

s: a

n an

alys

is o

f hist

oric

al m

odifi

catio

nda

ta c

an id

entif

y an

d cl

assi

fy p

robl

emat

ic, h

igh-

mai

nten

ance

sof

twar

e re

gion

s.–

Thes

e re

gion

s ca

n be

des

crib

ed a

s “in

stab

ilitie

s”.

–Su

ch k

now

ledg

e ca

n di

rect

sof

twar

e re

desi

gn e

fforts

.

•Pr

opos

al:

IVA,

a to

ol to

vis

ualiz

e an

d an

alyz

eso

ftwar

e in

stab

ilitie

s.–

The

visu

aliz

atio

n ca

n di

rect

focu

sed

anal

ysis

.

Rel

ated

Res

earc

h

•St

atic

sof

twar

e an

alys

is…

–U

ses

depe

nden

ce g

raph

s of

a s

ingl

e re

visi

on to

gene

rate

cod

e m

etric

s (c

ohes

ion,

cou

plin

g,co

mpl

exity

) or c

ondu

ct c

hang

e im

pact

ana

lyse

s.

•So

ftwar

e ev

olut

ion

eith

er…

–An

alyz

es s

oftw

are

mod

ifica

tion

data

to c

reat

epr

oces

s-le

vel m

etric

s an

d m

odel

s of

evo

lutio

n.

–At

tem

pts

to a

utom

atic

ally

evo

lve

softw

are.

IVA

Is D

iffer

ent B

ecau

se…

•IV

A di

stin

guis

hes

betw

een

depe

nden

ce-re

late

dch

ange

s an

d ch

ange

s m

ade

durin

g th

e sa

me

“com

mit”

.•

IVA

does

not

requ

ire a

dvan

ced

chan

gem

anag

emen

t dat

a fo

r bas

ic fu

nctio

nalit

y–

Onl

y re

quire

s w

hen,

whe

re, w

hat,

but n

ot w

hy.

•U

ser c

ontro

ls IV

A fil

terin

g an

d ag

greg

atin

g of

chan

ge d

ata.

–D

iffer

ent u

sers

are

inte

rest

ed in

diff

eren

t thi

ngs.

IVA

Arch

itect

ure

Prep

roce

ssor

Dae

mon

-

Dep

ende

nce

Gra

ph

Gen

erat

ion

- R

aw M

etric

Cal

cula

tion

Inst

abilit

y An

alyz

er

- Nor

mal

izat

ion

& Fi

lterin

g - I

nsta

bilit

y Id

entif

icat

ion

- Met

ric C

alcu

latio

n - I

nsta

bilit

y Pr

iorit

izat

ion

Visu

aliz

atio

nEn

gine

Rep

ort

Gen

erat

orSC

Mre

posi

tory

IVA

repo

sito

ry

Inst

abilit

y Vi

sual

izat

ion

(1 o

f 3)

•D

epen

denc

e gr

aph

node

s po

sitio

ned

usin

ghe

irarc

hica

l rel

atio

nshi

p.

•C

ause

s sp

atia

l clu

ster

ing

of re

late

d no

des:

–Pa

ckag

e, c

lass

, met

hod

–D

irect

ory,

file

, fun

ctio

n

Inst

abilit

y Vi

sual

izat

ion

(2 o

f 3)

•Su

rface

map

gen

erat

edfro

m d

epen

denc

e gr

aph

layo

ut.

•R

etai

ns g

loba

l con

text

of

data

(cod

e lo

catio

n, e

tc.)

•H

ides

edg

es, r

educ

escl

utte

r.

Inst

abilit

y Vi

sual

izat

ion

(3 o

f 3)

•C

lass

ified

inst

abilit

yre

gion

s ar

e ov

erla

id o

nth

e su

rface

map

.•

Inst

abilit

ies

follo

w e

dges

of u

nder

lyin

g de

pend

ence

grap

h.•

Col

or a

nd w

idth

den

ote

user

-con

trolla

ble

met

rics;

dist

ance

den

otes

spa

n of

coup

ling. Use

In C

olla

bora

tive

Dev

elop

men

t

•IV

A ca

n an

alyz

e an

d pr

ovid

e fe

edba

ck o

n a

give

n im

plem

enta

tion

of c

olla

bora

tive

deve

lopm

ent.

–D

oes

task

bre

akdo

wn

forc

e co

nten

tion?

•C

olor

atio

n ba

sed

on n

umbe

r of d

iffer

ent c

omm

itter

s.

–D

oes

syst

em a

rchi

tect

ure

forc

e co

nten

tion?

•H

igh

seve

rity

and

num

ber o

f diff

eren

t com

mitt

ers.

–U

ser c

an c

ontro

l vis

ualiz

atio

n by

dire

ctin

g co

lor,

line

wid

th, o

r agg

rega

tion

algo

rithm

s.

Con

clus

ion

•IV

A w

ill le

vera

ge th

e da

ta s

tore

d in

cha

nge

cont

rol s

yste

ms

(CVS

as

a m

inim

um) b

yid

entif

ying

and

cla

ssify

ing

hist

oric

al c

hang

epa

ttern

s.•

A pr

oof-o

f-con

cept

IVA

is u

nder

con

stru

ctio

n–

Will

hand

le J

ava

sour

ce c

ode

in S

ubve

rsio

nre

posi

tory

.–

Will

prov

ide

addi

tiona

l vis

ualiz

atio

ns fo

r in-

dept

hex

plor

atio

n of

spe

cific

inst

abilit

y re

gion

s.

Que

stio

ns?

•Th

e w

ork

com

plet

ed to

dat

e w

as fu

nded

by

a20

01 U

SEN

IX S

tude

nt R

esea

rch

Gra

nt.

•Se

e ht

tp://

ww

w.c

se.u

csc.

edu/

~jbe

van

for I

VApr

ogre

ss a

nd s

tatu

s up

date

s.

•Em

ail j

beva

n@cs

e.uc

sc.e

du w

ith fu

ture

ques

tions

.

So

urc

e-C

od

eIn

stru

men

tati

on

and

Qu

anti

fica

tio

no

fE

ven

ts

Rob

ertE

.Film

anR

IAC

Srf

ilman

@m

ail.a

rc.n

asa.

gov

Kla

usH

avel

und

Kes

trel

Tec

hnol

ogy

have

lund

@em

ail.a

rc.n

asa.

gov

NA

SA

Am

esR

esea

rch

Cen

ter

Mof

fett

Fie

ld,C

A94

035

U.S

.A.

Sep

arat

ion

of

Co

nce

rns

�A

fun

dam

enta

len

gin

eeri

ng

pri

nci

ple

isth

ato

fse

par

atio

no

fco

nce

rns

–R

ealiz

ing

dif

fere

nt

syst

emco

nce

pts

asse

par

ate,

wea

kly

linke

del

emen

ts–

Dis

trib

uti

on

of

exp

erti

se�

Sep

arat

ion

of

con

cern

sp

rom

ises

bet

ter

–M

ain

tain

abili

ty–

Evo

lvab

ility

–R

eusa

bili

ty–

Ad

apti

vity

�C

on

cern

scr

oss

-cu

t–

Ap

ply

tod

iffe

ren

tm

od

ule

sin

ava

riet

yo

fp

lace

s�

Co

nce

rns

mu

stb

eco

mp

ose

dto

bu

ildru

nn

ing

syst

ems

Inco

nve

nti

on

alp

rog

ram

min

g,t

he

cod

efo

rd

iffe

ren

tco

nce

rns

oft

enb

eco

mes

mix

ed-t

og

eth

er(t

ang

led

)

Exa

mp

les

of

So

ftw

are

Co

nce

rns

�S

ecu

rity

–A

lway

sca

llth

ese

curi

tych

eck

bef

ore

allo

win

gd

atab

ase

acce

ss�

Acc

ou

nti

ng

–A

lway

sd

ebit

the

use

r’s

acco

un

to

nea

chac

cess

toa

serv

ice

of

ob

ject

sin

the

clas

s…�

Syn

chro

niz

atio

n–

Do

n’t

let

mu

ltip

leu

sers

call

any

of

met

ho

ds

f,g

,or

ho

na

sin

gle

ob

ject

sim

ult

aneo

usl

y–

Th

eef

fect

so

fth

ese

acti

on

ssh

ou

ldb

etr

ansa

ctio

nal

�Q

ual

ity

of

serv

ice

–Q

ueu

eu

pth

ew

aiti

ng

calls

han

dlin

gth

emb

yp

rio

rity

�R

elia

bili

ty–

Pro

vid

ere

plic

ants

of

this

ob

ject

�P

erfo

rman

ceen

han

cem

ents

–C

ach

eth

ere

sult

so

fca

llsto

elem

ents

inth

iscl

ass

–D

isp

lay

rou

tin

essh

ou

ldsh

ow

the

resu

lts

of

chan

ges

,exc

ept

dis

pla

yro

uti

nes

calle

din

the

sco

pe

of

oth

erd

isp

lay

rou

tin

essh

ou

ldb

uff

erth

eir

chan

ges

for

dis

pla

yal

lat

on

ce

Fu

nct

ion

alan

dN

on

-Fu

nct

ion

alR

equ

irem

ents

Func

tiona

l:N

on-f

unct

iona

l(ili

ty):

Ava

ilabi

lity

Rel

iabi

lity

Sec

urity

Man

agea

bilit

yR

espo

nsiv

enes

s

Func

tion

1&

ility

supp

ort

Func

tion

4&

ility

supp

ort

Func

tion

2&

ility

supp

ort

Func

tion

3&

ility

supp

ort

Func

.Req

.2Fu

nc.R

eq.4

Fun

cR

eq.1

Func

.Req

.3

Func

tiona

lreq

uire

men

tsm

apto

spec

ific

com

pone

nts

Ility

requ

irem

ents

map

alm

oste

very

whe

re

Ser

vice

san

dIli

ties

�Ili

tyre

qu

irem

ents

are

imp

lem

ente

db

yco

mb

inat

ion

so

fse

rvic

eal

go

rith

ms.

�S

up

po

rtin

gili

ties

invo

lves

aco

mp

lex

sele

ctio

nfr

om

sets

of

alte

rnat

ive

serv

ice

alg

ori

thm

s.�

Th

ese

rvic

esm

ust

be

invo

ked

per

vasi

vely

thro

ug

ho

ut

the

syst

em.

Ility

requ

irem

ents

:

Serv

ices

:

Ava

ilabi

lity

Rel

iabi

lity

Sec

urity

Man

agea

bilit

yR

espo

nsiv

enes

s

Rep

licat

ion

AR

eplic

atio

n2

Rep

licat

ion Rep

licat

ion

AR

eplic

atio

n2

Tra

nsac

tions

Enc

rypt

ion

Aut

hent

icat

ion

Tra

cing

&A

udit

Faul

tDet

ectio

n

Res

ourc

eR

eser

vatio

n

Que

ueM

gmt.

Ob

ject

Infr

astr

uct

ure

Fra

mew

ork

Res

earc

hH

ypo

thes

is

�Ili

ties

can

be

ach

ieve

db

yin

sert

ing

serv

ices

into

the

com

mu

nic

atio

np

ath

bet

wee

nfu

nct

ion

alco

mp

on

ents

–O

nb

oth

sid

eso

fth

eco

mm

un

icat

ion

�F

ram

ewo

rks

that

auto

mat

ese

rvic

ein

sert

ion

can

syst

emat

ical

lyac

hie

ven

on

-fu

nct

ion

alre

qu

irem

ents

–O

bje

ctIn

fras

tru

ctu

reF

ram

ewo

rk(O

IF)

�Ili

ties

can

be

ach

ieve

db

yin

sert

ing

serv

ices

into

the

com

mu

nic

atio

np

ath

bet

wee

nfu

nct

ion

alco

mp

on

ents

–O

nb

oth

sid

eso

fth

eco

mm

un

icat

ion

�F

ram

ewo

rks

that

auto

mat

ese

rvic

ein

sert

ion

can

syst

emat

ical

lyac

hie

ven

on

-fu

nct

ion

alre

qu

irem

ents

–O

bje

ctIn

fras

tru

ctu

reF

ram

ewo

rk(O

IF)

Arc

hit

ectu

rew

ith

Ser

vice

sin

Co

mp

on

ent

Co

mm

un

icat

ion

s

Func

tion

1&

ility

supp

ort

Func

tion

4&

ility

supp

ort

Func

tion

2&

ility

supp

ort

Func

tion

3&

ility

supp

ort

Tra

ditio

nald

esig

nsm

ixili

tysu

ppor

twith

infu

nctio

nalc

ompo

nent

s:

Func

tion

1

Func

tion

4Fu

nctio

n2

Func

tion

3E

ncry

pt

SetP

rior

ity

Dec

rypt

Que

ueM

gmt

Dec

rypt

Que

ueM

gmt.

Enc

rypt

Pass

Prio

rity

Dec

rypt

Que

ueM

gmt

OIF

isde

mon

stra

ting

fram

ewor

ksth

atin

sert

serv

ices

into

the

com

mun

icat

ion

path

sbe

twee

nfu

nctio

nalc

ompo

nent

s.R

eplic

atio

n

Rep

licat

ion

Key

insi

ght:

Ser

vice

func

tiona

lity

can

bese

para

ted

from

func

tiona

llog

icby

inse

rtin

gth

ese

rvic

esin

toth

eco

mm

unic

atio

nsbe

twee

nfu

nctio

nalc

ompo

nent

s.

Key

OIF

Idea

s�

Inje

ctin

gb

ehav

ior

on

the

com

mu

nic

ate

pat

hs

bet

wee

nco

mp

on

ents

–In

ject

ors

are

dis

cret

e,u

nif

orm

ob

ject

s–

Inje

cto

rsar

eb

yo

bje

ct/m

eth

od

–In

ject

ors

are

dyn

amic

ally

con

fig

ura

ble

�A

nn

ota

ted

com

mu

nic

atio

ns

allo

win

ject

edse

rvic

esto

pas

sp

aram

eter

sto

serv

ice

pee

rs(e

.g.,

mes

sag

ep

rio

rity

,use

r-id

,tra

cin

gst

atu

s)

�T

hre

adco

nte

xts

pre

serv

ean

no

tati

on

sth

rou

gh

calls

�P

rag

ma:

Hig

h-l

evel

spec

ific

atio

nla

ng

uag

efo

rd

escr

ibin

gd

esir

edin

ject

ion

s(P

rag

ma)

Au

then

tica

teA

uth

enti

cate

Ret

ryR

etry

Man

agem

ent

Man

agem

ent

Rel

iab

ility

Rel

iab

ility

CO

RB

AP

roxy

Ch

eck

auth

.C

hec

kau

th.

Qu

alit

yo

fS

ervi

ceQ

ual

ity

of

Ser

vice

Man

agem

ent

Man

agem

ent

Rel

iab

ility

Rel

iab

ility

CO

RB

AS

kele

ton

Clie

ntC

lient

Ser

ver

Ser

ver

Net

wo

rk

Co

nfi

gu

rab

leP

roxi

es

�O

IF’s

inje

cto

rsca

no

per

ate

inp

airs

(e.g

.,en

cryp

t/d

ecry

pt;

req

ues

tau

then

tica

tio

n/a

uth

enti

cate

)o

rsi

ng

ly(e

.g.,

retr

yo

nfa

ilure

;lo

gre

sult

s)

�C

on

fig

ura

tio

nis

by

pro

xy/m

eth

od

inst

ance

�C

on

fig

ura

tio

nis

dyn

amic

Do

mai

nP

rog

ram

mer

sd

evel

op

app

licat

ion

.

Sec

uri

tyQ

ual

ity

of

Ser

vice

Man

agea

bili

ty

Dis

trib

uti

on

and

Ility

Arc

hit

ect

spec

ifie

sse

rvic

es.

Rel

iab

ility

Dis

trib

ute

dap

plic

atio

n

OIF

ram

ewo

rk

OIF

Pro

cess

�M

apo

rgan

izat

ion

alp

olic

ies

toim

ple

men

tati

on

–E

.g.,

•d

efin

ea

secu

rity

po

licy

•en

sure

that

po

licy

isfo

llow

edb

yal

ldis

trib

ute

dco

mp

on

ents

Asp

ect-

Ori

ente

dP

rog

ram

min

g(A

OP

)

�O

IFis

anA

spec

t-O

rien

ted

Pro

gra

mm

ing

syst

em�

So

ftw

are

eng

inee

rin

gte

chn

olo

gy

for

sep

arat

ely

exp

ress

ing

syst

emat

icp

rop

erti

esw

hile

nev

erth

eles

sp

rod

uci

ng

run

nin

gsy

stem

sth

atem

bo

dy

thes

ep

rop

erti

es�

Nee

dto

exp

ress

–B

ase

pro

gra

m–

Sep

arat

eco

nce

rns

–H

owth

ese

par

ate

con

cern

sm

apto

the

bas

ep

rog

ram

•O

r,if

you

pre

fer,

just

aju

mb

leo

fp

rog

ram

elem

ents

that

mu

stb

eco

mb

ined

.

Qu

anti

fica

tio

nan

dIm

plic

itIn

voca

tio

n�

Pro

gra

mm

atic

esse

nce

of

AO

Pis

tob

eab

leto

stat

eu

niv

ersa

llyq

uan

tifi

edst

atem

ents

abo

ut

(co

nve

nti

on

al,

linea

r)p

rog

ram

s�

An

dh

ave

the

effe

cto

fth

ese

stat

emen

tsre

aliz

edin

pro

gra

ms

that

do

n’t

con

tain

exp

licit

no

tati

on

app

lyin

gth

ese

qu

anti

fied

stat

emen

ts

Inp

rog

ram

sP

,wh

enev

erco

nd

itio

nC

aris

es,p

erfo

rmac

tio

nA

.

�D

imen

sio

ns

of

con

cern

for

the

des

ign

eran

dim

ple

men

ter

of

anA

OP

syst

em:

–Q

uan

tifi

cati

on

:W

hat

kin

ds

of

con

dit

ion

sC

can

be

spec

ifie

d.

–In

terf

ace:

Wh

atis

the

inte

rfac

eo

fth

eac

tio

ns

A.T

hat

is,h

owd

oth

eyin

tera

ctw

ith

bas

ep

rog

ram

san

dea

cho

ther

.–

Wea

vin

g:

Ho

ww

illth

esy

stem

arra

ng

eto

inte

rmix

the

exec

uti

on

of

the

bas

eac

tio

ns

of

Pw

ith

the

acti

on

sA

.

Ch

oic

esin

Dev

elo

pin

gA

OP

Lan

gu

ages

�W

hat

qu

anti

fied

stat

emen

tsar

eal

low

ed–

Join

po

ints

•M

eth

od

calls

•F

ield

acce

ss•

Ab

stra

ctsy

nta

x•

Co

ntr

olf

low

–S

cop

eo

fq

uan

tifi

cati

on

•S

ub

clas

ses

•B

yn

ame

•L

exic

alst

ruct

ure

�S

ynta

xfo

rex

pre

ssin

gap

plic

atio

n

�In

tera

ctio

nam

on

gas

pec

tsan

db

ase

cod

e–

Vis

ibili

ty–

Ord

erin

g–

Co

nfl

ict

reso

luti

on

�Im

ple

men

tati

on

mec

han

ism

–C

om

pile

r–

Byt

e-co

de

man

ipu

lati

on

–D

ynam

icw

rap

pin

g–

Fra

mew

ork

s–

Met

a-p

rog

ram

min

g–

Pro

gra

mtr

ansf

orm

atio

n

Sta

tic

and

Dyn

amic

Qu

anti

fica

tio

n

�In

earl

ier

wo

rk,w

ed

isti

ng

uis

hed

bet

wee

n–

Sta

tic

qu

anti

fica

tio

n:

dis

cern

able

fro

mth

esy

nta

ctic

stru

ctu

reo

fth

esp

ecim

enp

rog

ram

•E

.g,c

alls

–D

ynam

icq

uan

tifi

cati

on

:m

atch

ing

even

tsth

ath

app

enin

the

cou

rse

of

pro

gra

mex

ecu

tio

n.

•E

.g.,

cflo

w

�C

urr

entl

yex

plo

rin

gth

eh

ypo

thes

isth

at(a

lmo

st)

alli

nte

rest

ing

“eve

nts

”ar

ed

ynam

ic,a

nd

that

stat

icq

uan

tifi

cati

on

mer

ely

refe

rsto

tho

seev

ents

that

can

be

sim

ply

infe

rred

fro

mth

est

atic

stru

ctu

reo

fth

ep

rog

ram

.–

Sh

ado

ws

inth

eco

de

–E

xcep

tio

n:

pro

gra

mst

ruct

ura

lch

ang

es

Ext

rem

eE

xper

imen

t

�T

he

extr

eme

of

exp

ress

iven

ess

inq

uan

tifi

cati

on

isto

be

able

toq

uan

tify

ove

ral

lth

eh

isto

ryo

fev

ents

ina

pro

gra

mex

ecu

tio

n�

Eve

nts

are

wit

hre

spec

tto

the

abst

ract

inte

rpre

ter

of

ala

ng

uag

e�

Un

fort

un

atel

y,la

ng

uag

ed

efin

itio

ns

do

n’t

def

ine

thei

rab

stra

ctin

terp

rete

rs.

Eve

nts

and

Eve

nt

Lo

ci

Eve

nt

Syn

tact

iclo

cus

Acc

essi

ng

the

valu

eof

ava

riab

leor

field

Ref

eren

ces

toth

atva

riab

le

Mod

ifyin

gth

eva

lue

ofa

varia

ble

orfie

ldA

ssig

nm

ents

toth

atva

riab

le

Invo

kin

ga

sub

pro

gra

mS

ub

pro

gra

mca

llsC

yclin

gth

rou

gh

alo

opLo

opst

atem

ents

Bra

nch

ing

ona

con

diti

onal

Th

eco

nd

ition

alst

atem

ent

Initi

aliz

ing

anin

stan

ceT

he

con

stru

ctor

sfo

rth

atob

ject

Th

row

ing

anex

cep

tion

Th

row

stat

emen

tsC

atch

ing

anex

cep

tion

Cat

chst

atem

ents

Wai

ting

ona

lock

Wai

tan

dsy

nch

ron

ize

stat

emen

ts

Mo

reE

ven

tsan

dL

oci

Eve

nt

Syn

tact

iclo

cus

Res

um

ing

afte

ra

lock

wai

tO

ther

'sn

otify

and

end

ofsy

nch

ron

izat

ion

sT

estin

ga

pre

dic

ate

onse

vera

lfie

lds

Eve

rym

odifi

catio

nof

any

ofth

ose

field

sC

han

gin

ga

valu

eon

the

pat

hto

anot

her

Con

trol

and

dat

aflo

wan

alys

isov

erst

atem

ents

(slic

es)

Sw

app

ing

the

run

nin

gth

read

Not

relia

bly

acce

ssib

le,

bu

tat

omiz

atio

nm

ayb

ep

ossi

ble

Bei

ng

bel

owon

the

stac

kS

ub

pro

gra

mca

llsF

reei

ng

stor

age

Not

relia

bly

acce

ssib

le,

bu

tca

ntr

yu

sin

gb

uilt

-inp

rimiti

ves

Th

row

ing

aner

ror

Not

relia

bly

acce

ssib

le;

cou

ldh

app

enan

ywh

ere

Res

earc

hre

gim

e

�D

efin

ea

lan

gu

age

of

even

tsan

dac

tio

ns

on

tho

seev

ents

.�

Det

erm

ine

ho

wea

chev

ent

isre

flec

ted

(or

can

be

mad

evi

sib

le)

inso

urc

eco

de.

�C

reat

ea

syst

emto

tran

sfo

rmp

rog

ram

sw

ith

resp

ect

toth

ese

even

tsan

dac

tio

ns.

Tra

nsf

orm

atio

nal

Alt

ern

ativ

es

�F

or

Java

,can

tran

sfo

rmat

–T

he

sou

rce-

cod

ele

vel

–T

he

byt

e-co

de

leve

l

Arc

hit

ectu

ralV

iew

Sour

ceJa

vaco

de

Sour

ceJa

vaco

de

Eve

nt-a

ctio

nde

scri

ptio

ns

Eve

nt-a

ctio

nde

scri

ptio

ns

Eve

nt-

Edi

tco

mpi

latio

n

Tra

nsfo

rmT

rans

form AST

Tar

getJ

ava

code

Tar

getJ

ava

code

Pars

ePr

etty

Prin

t

Ap

plic

atio

ns

�A

pp

lyin

gA

OP

tod

ebu

gg

ing

and

valid

atin

gco

ncu

rren

tp

rog

ram

s.�

Ap

ply

ing

AO

Pto

mo

nit

or

pro

gra

ms

du

rin

go

per

atio

n,s

oth

atac

tio

ns

can

be

init

iate

din

case

bad

thin

gs

hap

pen

.�

Ap

ply

ing

AO

Pas

ag

ener

alp

rog

ram

min

gp

arad

igm

.

Pro

gra

mD

ebu

gg

ing

�D

etec

tm

ult

i-th

read

ing

pro

ble

ms

cau

sed

by

acce

ssto

shar

edre

sou

rces

by

com

pet

ing

thre

ads.

�V

alid

ate

trac

eex

ecu

tio

ns

agai

nst

use

rre

qu

irem

ents

.�

Val

idat

em

ult

ith

read

edp

rog

ram

sb

yex

plo

rin

gsc

hed

ule

inte

rlea

vin

gs.

Det

ect

Mu

lti-

thre

adin

gP

rob

lem

s

�D

eadl

ocks

:O

bse

rve

inw

hat

ord

erlo

cks

are

take

nan

dre

leas

edan

din

fer

po

ten

tial

dea

dlo

cks

fro

mcy

cles

.�

Dat

aR

aces

:O

bse

rve

wh

atlo

cks

thre

ads

ow

nw

hen

they

acce

ssva

riab

les

and

infe

rp

ote

nti

ald

ata

race

sfr

om

emp

tyo

verl

aps.

Dea

dlo

cks

Ade

adlo

ckca

noc

cur

whe

nth

read

sac

cess

and

lock

shar

edre

sour

ces,

and

lock

thes

ein

diff

eren

tord

er.

Ade

adlo

ckca

noc

cur

whe

nth

read

sac

cess

and

lock

shar

edre

sour

ces,

and

lock

thes

ein

diff

eren

tord

er.

L2

1 212

L1

T1

T2

1 212

Pro

blem

:T

1lo

cks

L1

firs

tT

2lo

cks

L2

firs

t

Exa

mpl

eSo

luti

on:

Impo

seor

der

onlo

cks:

L1

<L

2

L1

L2

cycl

e

v1.add(v2)

v1=new

Value();

v2.add(v1)

classValue{

int

x=1;

synchronizedvoidadd(Valuev){x=x+v.get();}

synchronizedint

get(){returnx;}

}classValue{

int

x=1;

synchronizedvoidadd(Valuev){x=x+v.get();}

synchronizedint

get(){returnx;}

}

Java

Pro

gra

mw

ith

Dea

dlo

ck

v2=new

Value();

Thr

ead

T1

Thr

ead

T2

Ap

ply

ing

AO

P

aspectDeadlockDetection{

whensynchronize(obj){

Threadcurr=Thread.currentThread();

Setlocks=Threads.getLocks(curr);

Graph.addEdges(locks,obj);

Graph.findCycles();

Threads.addLock(curr,obj);

} whenendofsynchronize(obj){

Threads.remove(curr,obj);

}}

Dat

aR

aces

Ada

tara

ceoc

curs

whe

ntw

oth

read

s•A

cces

sa

shar

edva

riab

le,

•Atl

east

one

acce

ssis

aw

rite

,and

•No

mec

hani

smis

used

topr

even

tsim

ulta

neou

sac

cess

.

Ada

tara

ceoc

curs

whe

ntw

oth

read

s•A

cces

sa

shar

edva

riab

le,

•Atl

east

one

acce

ssis

aw

rite

,and

•No

mec

hani

smis

used

topr

even

tsim

ulta

neou

sac

cess

.

x=

x+

1x

=x

+1

x:0

Thr

ead

1Sh

ared

vari

able

Thr

ead

2

Exa

mpl

eSo

luti

ons:

mon

itors

,sem

apho

res,

…

Res

ulta

fter

both

upda

tes

:2…

orm

aybe

1

v1.add(v2)

v1=newValue();

v2.add(v1)

classValue{

intx=1;

voidadd(Valuev){x=x+v.get();}

intget(){returnx;}

}classValue{

intx=1;

voidadd(Valuev){x=x+v.get();}

intget(){returnx;}

}

Java

Pro

gra

mw

ith

Dat

arac

e

v2=newValue();

Thr

ead

T1

Thr

ead

T2

Fo

rE

ach

Var

iab

le:

AL

ock

set

and

aS

tate

mac

hin

e

notu

sed

excl

usiv

e

shar

ed

shar

edm

odifi

ed

wr

rd(n

ewth

read

)rd

,wr

(firs

tthr

ead)

rd

wr

(new

thre

ad)

wr

rd,w

r

=no

actio

n

=re

finem

ent

=al

sow

arni

ngs

{…se

tof

prot

ectin

glo

cks

…}

Era

ser

algo

rith

m(C

ompa

q)

Ap

ply

ing

AO

PaspectDataraceDetection{

whensynchronize(obj){

Threadcurr=Thread.currentThread();

Threads.addLock(curr,obj);

} whenendofsynchronize(obj){

Threadcurr=Thread.currentThread();

Threads.remove(curr,obj);

} whenaccessto(var,isWrite){

Threadcurr=Thread.currentThread();

Statemachine.update(curr,var,isWrite);

Statemachine.checkEmptyness(var);

}}

Val

idat

ing

Exe

cuti

on

Tra

ces

Ag

ain

stU

ser

Req

uir

emen

ts

aspectCheckRequirements{

when(CLOSED

and

not

previouslyDO_CLOSE){

Report(“Systemclosedbyitself”);

} whennot(DO_CLOSEimplies

eventually(20)CLOSED){

Report(“Systemdidnotclose”);

}}

CloseSystem();

//repair

Exp

lore

Sch

edu

ling

�S

imp

leex

amp

le:

assu

me

that

allv

aria

ble

acce

sses

are

pro

tect

edw

ith

lock

s.�

Inse

rta

call

of

ara

nd

om

ized

yiel

dst

atem

ent

infr

on

to

fal

lsyn

chro

niz

atio

nst

atem

ents

and

calls

of

syn

chro

niz

edm

eth

od

s.�

Th

isw

illca

use

the

sch

edu

ler

tora

nd

om

lym

ake

aco

nte

xtsw

itch

wh

enev

era

lock

ista

ken

.Th

ism

ayb

eu

sed

,fo

rex

amp

le,t

ore

veal

dea

dlo

cks.

Rel

ated

wo

rk

�D

eV

old

eret

al.m

etap

rog

ram

min

g�

AO

Pth

rou

gh

pro

gra

mtr

ansf

orm

atio

n–

Co

lcu

mb

et,F

rad

etan

dS

ud

ho

lt–

Sch

on

ger

etal

.XM

Ltr

ansf

orm

atio

n–

Ski

pp

erku

�N

elso

net

al.c

on

cern

-lev

elfo

un

dat

ion

alco

mp

osi

tio

no

per

ato

rs:

corr

esp

on

den

ce,

beh

avio

rals

eman

tics

and

bin

din

g�

Wal

ker

and

Mu

rph

yo

nev

ents

asjo

inp

oin

ts

Co

ncl

ud

ing

rem

arks

�P

rese

nte

d–

AO

P–

OIF

,an

AO

Psy

stem

–E

ven

t-b

ased

qu

anti

fied

app

roac

hto

AO

P•

Dev

elo

pin

gan

envi

ron

men

tfo

rex

per

imen

tin

gw

ithA

OP

lan

gu

ages

(DS

Lfo

rA

OP

)

Visu

aliz

atio

n of

Soft

war

e an

d Ac

tivi

ty

Paul

Dou

rish

Inst

itute

for

Sof

twar

e Res

earc

hU

C Ir

vine

jpd@

ics.

uci.e

du

NAS

A AR

C, A

ugus

t 20

02

wha

t we

alre

ady

know

•fr

om s

tudi

es o

f so

ftw

are

deve

lopm

ent

–co

mpl

exity

of

task

and

inte

ract

ion

–th

e im

pact

of

dist

ance

–co

mpl

exity

of

inte

rdep

ende

nce

•fr

om s

tudi

es o

f co

llabo

ratio

n–

form

al a

nd in

form

al–

the

role

of

awar

enes

s•

qual

itativ

e un

ders

tand

ings

of

the

actio

ns o

f ot

hers

•pr

ovid

es a

con

text

for

you

r ow

n ac

tions

appr

oach

•vi

sual

app

roac

hes

–co

gniti

ve -

> p

erce

ptua

l–

focu

s on

art

ifact

s ra

ther

tha

n pr

oces

ses

•th

eore

tical

bac

kgro

und

–th

e ex

perie

nce

of c

ompu

tatio

n•

mak

ing

com

puta

tion

“pre

sent

”

–em

bodi

ed in

tera

ctio

n•

inte

ract

ion

as a

n em

bodi

ed p

ract

ice

•di

rect

ness

and

eng

agem

ent

•tw

o pr

ojec

ts:

sees

oft

and

vavo

om

sees

oft

•cs

cw r

esea

rch

focu

s on

aw

aren

ess

–pa

ssiv

e un

ders

tand

ing

of t

he a

ctiv

ity o

f ot

hers

•tr

ying

to

unde

rsta

nd “

awar

enes

s in

the

larg

e”–

larg

e-sc

ale,

dis

trib

uted

sof

twar

e de

velo

pmen

t–

in la

rge

proj

ects

, the

cod

ebas

e is

the

art

ifact

–aw

aren

ess

of c

hang

es in

the

art

ifact

–aw

aren

ess

of t

he a

ctio

ns o

f ot

hers

•se

esof

t–

adop

ted

from

wor

k of

eic

k, w

ills,

et

al.

–vi

ew t

he a

ctiv

ity in

cvs

rep

osito

ries

sees

oft

sees

oft

sees

oft

vavo

om

•in

terf

ace

abst

ract

ions

hid

e m

echa

nism

–“f

olde

rs”

are

fold

ers

whe

ther

loca

l or

netw

orke

d

•bu

t m

echa

nism

is h

ow w

e un

ders

tand

the

wor

ld–

unde

rsta

ndin

gs o

f ca

use

and

effe

ct–

tem

pora

l dyn

amic

cou

plin

g–

the

tem

pora

l org

aniz

atio

n of

soc

ial a

ctio

n

•m

anife

stin

g co

mpu

tatio

n–

how

to

give

peo

ple

a pi

ctur

e of

wha

t’s h

appe

ning

?

vavo

om

•in

itial

exp

lora

tion:

vav

oom

–fo

cus

on n

ovic

e pr

ogra

mm

ers

•w

e un

ders

tand

the

mod

els

in t

erm

s of

whi

ch t

o ex

plai

n•

vest

ed in

tere

st in

fin

ding

out

wha

t’s g

oing

on

•th

ere’

s pl

enty

of

them

lyin

g ar

ound

–va

voom

is t

he v

isua

l virt

ual m

achi

ne•

visu

aliz

e ja

va p

rogr

am e

xecu

tion

•dy

nam

ic, r

eal-t

ime

visu

aliz

atio

ns•

unm

odifi

ed c

lass

file

s

vvm

Java

vmux

viz1

viz3

viz2

vavo

om

vavo

om

vavo

om

vavo

om

vavo

om

•va

voom

is a

n ea

rly t

echn

ical

exp

lora

tion

–th

e fo

cus

on p

rogr

amm

ers

is a

hac

k•

but

conv

enie

nt…

as

long

as

they

hav

e th

e rig

ht p

rogr

ams

–a

mor

e in

tere

stin

g st

rate

gy is

to:

•fo

cus

on e

nd u

sers

•fo

cus

on m

ore

abst

ract

vis

ualis

atio

ns•

focu

s on

mor

e sp

ecia

lised

tas

ks–

curr

ently

exp

lorin

g ne

twor

k se

curit

y

conc

lusi

ons

•sy

stem

sup

port

for

info

rmal

inte

ract

ion

–no

n pr

oces

s-ce

ntric

col

labo

ratio

n–

qual

itativ

e un

ders

tand

ings

of

•so

ftw

are

beha

vior

•co

llabo

rativ

e ac

tivity

•ex

ploi

ting

soft

war

e as

art

ifact

–so

ftw

are

as p

rimar

y co

ordi

nativ

e re

sour

ce–

dire

ctne

ss a

nd m

alle

abili

ty•

open

que

stio

ns–

inte

grat

ion

with

pra

ctic

e–

bala

nce

betw

een

tran

sluc

ence

and

dis

trac

tion

–de

mon

stra

tion

of t

heor

etic

al a

ppro

ach

Expl

orin

g th

e Rel

atio

nshi

pbe

twee

n Pr

ojec

t Se

lect

ion

and

Req

uire

men

ts A

naly

sis

Mar

k Be

rgm

an, G

loria

Mar

kIn

form

atio

n an

d Co

mpu

ter

Scie

nce

Dep

t.U

nive

rsity

of

Calif

orni

a, I

rvin

em

berg

man

@ic

s.uc

i.edu

, gm

ark@

ics.

uci.e

du

Initi

al P

roje

ct F

orm

atio

n�

Firs

t, P

roje

ct S

elec

tion

�D

eter

min

e pr

ojec

t ch

oice

s�

Choo

se a

pro

ject

to

fund

and

dev

elop

�Th

en, R

equi

rem

ents

Ana

lysi

s�

Det

erm

inin

g st

akeh

olde

rs’ w

ants

, nee

ds, a

ndco

nstr

aint

s fo

r a

proj

ect

�Req

uire

men

ts A

naly

sis

trad

ition

ally

fol

low

s Pr

ojec

tSe

lect

ion

�H

ow d

oes

Proj

ect

Sele

ctio

n re

late

to

Req

uire

men

ts A

naly

sis?

�Pr

ojec

t Se

lect

ion

deci

sion

s fr

ame

subs

eque

ntReq

uire

men

ts A

naly

sis

Res

earc

h Q

uest

ions

�In

pra

ctic

e, d

oes

the

orde

r of

firs

tde

term

inin

g pr

ojec

t ch

oice

s, m

akin

g pr

ojec

tse

lect

ion

and

then

per

form

ing

requ

irem

ents

anal

ysis

hol

d?�

If n

ot, w

hat

are

poss

ible

pro

cedu

ral

rela

tions

hips

bet

wee

n pr

ojec

t ch

oice

cons

truc

tion,

pro

ject

sel

ectio

n an

dre

quire

men

ts a

naly

sis?

�H

ow a

re t

hey

sim

ilar

or d

iffer

ent

to c

urre

ntre

quire

men

ts a

naly

sis

view

s?

Res

earc

h M

etho

ds�

Proj

ect

Sele

ctio

n an

dReq

uire

men

ts A

naly

sis

have

bee

n st

udie

din

divi

dual

ly, b

ut n

otto

geth

er�

Proj

ect

Sele

ctio

n ha

sbe

en e

xam

ined

empi

rical

ly�

Alm

ost

no in

situ

Requ

irem

ents

Ana

lysi

sst

udie

s

�Ap

ply

Ethn

ogra

phic

Met

hods

to

stud

y in

itial

proj

ect

form

atio

n in

situ

�5

mon

ths

(2-3

tim

esw

eekl

y) o

f on

site

part

icip

ant

obse

rvat

ion

�46

indi

vidu

al s

emi-

stru

ctur

ed in

terv

iew

s an

d34

sem

i-for

mal

and

form

al g

roup

mee

tings

�5

deta

iled

tech

nica

lpr

esen

tatio

ns�

Hun

dred

s of

rel

ated

docu

men

ts

The

Fiel

d Si

te�

The

New

Mill

enni

um P

rogr

am (

NM

P) a

t th

e Je

tPr

opul

sion

Lab

orat

ory

(JPL

): A

gro

up in

a N

ASA

(Nat

iona

l Aer

onau

tics

and

Spac

e Ad

min

istr

atio

n)re

sear

ch la

bora

tory

loca

ted

in S

outh

ern

Calif

orni

a�

The

NM

P pr

ogra

m’s

mis

sion

: Sp

ace

fligh

t va

lidat

e ne

wte

chno

logi

es t

hat

are

deem

ed im

port

ant

to N

ASA’

sfu

ture

sci

ence

mis

sion

s�

This

incl

udes

mat

urin

g ne

w t

echn

olog

ies

(TRL

3 �

TRL

7)

�N

MP

Sele

ctio

n Pr

oces

s: C

hoos

ing

whi

ch n

ewte

chno

logi

es t

o va

lidat

e�

Each

new

tec

hnol

ogy

cand

idat

e ca

n be

com

e th

e ba

sis

of a

new

pro

ject

– a

val

idat

ion

mis

sion

�N

MP

sele

ctio

n pr

oces

s is

a h

ighl

y de

velo

ped

form

of i

n si

tu in

itial

proj

ect

form

atio

n

Assi

st a

nd p

rom

ote

the

tech

nolo

gy a

nd p

roje

ctse

lect

ion

proc

ess

Build

ers

of n

ew a

eros

pace

rela

ted

tech

nolo

gies

Plan

ners

, des

igne

rs,

scie

ntis

ts, b

uild

ers,

and

man

ager

s of

sci

ence

mis

sion

spa

ce s

yste

ms

NAS

A up

per

leve

l dec

isio

nm

aker

s w

ith t

he a

utho

rity

to a

ssig

n or

gani

zatio

nal

reso

urce

s to

impl

emen

tth

eir

deci

sion

Des

crip

tion

Wan

t ne

w t

echn

olog

ies

to s

pace

flig

ht v

alid

ate

Wan

t to

bal

ance

and

sat

isfy

the

nee

ds o

f th

e ad

min

istr

ator

s an

d th

emes

,w

hile

val

idat

ing

as m

any

prov

ider

s’ t

echn

olog

ies

as p

ossi

ble

Cons

trai

ned

by a

llott

ed p

roje

ct c

ycle

bud

gets

and

giv

en d

eadl

ines

NM

PTe

chno

logi

sts

Hav

e ve

ry p

reci

se c

onst

rain

ts a

nd u

sage

gui

delin

es w

hile

pro

vidi

ng s

peci

fic,

sem

i-cus

tom

izab

le t

echn

ical

func

tiona

lity

Wan

t th

eir

tech

nolo

gies

spa

ce f

light

val

idat

ed, l

ikel

y cr

eatin

g a

long

ter

mre

venu

e st

ream

, whi

le m

inim

izin

g te

chno

logy

dev

elop

men

t co

sts

Cons

trai

ned

by V

AL a

war

d am

ount

s an

d pr

ojec

t de

adlin

es

Tech

nolo

gyPr

ovid

ers

Tech

nica

lly e

xplic

it an

d pr

ecis

e in

the

ir ne

eds

and

cons

trai

nts

Wan

t ne

w t

echn

olog

y th

at w

ould

low

er f

utur

e sc

ienc

e m

issi

on s

yste

m c

osts

or e

nabl

e ex

perim

ents

Cons

trai

ned

by t

ight

bud

gets

and

pro

ject

dea

dlin

es

Mis

sion

Them

es

Wan

ts, n

eeds

and

con

stra

ints

ten

d to

be

gene

ral,

som

ewha

t va

gue,

and

usua

lly c

onfli

ctin

gW

ant

broa

dly

appl

icab

le a

rray

of

new

tec

hnol

ogie

s to

bec

ome

avai

labl

e fo

rN

ASA

wid

e sc

ienc

e m

issi

on u

sage

, whi

le m

inim

izing

cos

tCo

nstr

aine

d by

bud

geta

ry a

nd p

olic

y gu

idel

ines

fro

m t

he U

S Co

ngre

ss

NAS

AAd

min

istr

ator

s

Gen

eral

Req

uir

emen

ts P

rofi

leLa

b R

olesRo

les

and

Req

uire

men

ts

Role

s an

d Pr

ojec

t Se

lect

ion

One

of N

Can

dida

tePr

ojec

t Pla

ns, P

roje

ctPl

an N

is fo

r Co

ncep

t N

One

of x

Com

peti

ngTe

chno

logi

es fo

rCo

ncep

t N fr

om P

rovi

der

iOne

of N

Com

peti

ngGe

nera

l Sys

tem

Cand

idat

es

One

of m

NM

PTe

chno

logi

sts

One

of i

Tech

nolo

gyPr

ovid

ers

One

of p

Mis

sion

The

mes

NASA

Adm

inis

trat

ors

Lab

Role

Proc

ess

Role

Proj

ect S

trea

mNP i,N

,x

Conc

ept N

NMP m

: Pro

cess

Acto

rs/A

gent

s

P i: Tec

hnol

ogy

Prov

ider

s

TCp:

Them

eCu

stom

ers

PO: P

roce

ssOw

ners

/Pr

inci

pals

NM

P 1

NM

Pm

NM

P 2

���

NM

P T

ech

no

log

ists

(N

MP

)

���

Te

chn

olo

gy

Pro

vid

ers

(P

)

Co

nce

pt

N

���

Pk,

N,z

Pj,N

,2

Pi,N

,1

Co

nce

pt

B

���

Co

nce

pt

A

���

Pk,

A,x

Pj,A

,2

Pi,A

,1

Pk,

B,y

Pj,B

,2

Pi,B

,1

TC

1

Th

em

e C

ust

om

ers

(T

C)

TC

p

TC

2

���

NA

SA

Ad

min

istr

ato

rs(P

O)

Ove

rse

es

Co

nce

pt

AC

ust

om

ers

Co

nce

pt

BC

ust

om

er

Co

nce

pt

NC

ust

om

ers

Pro

ject

Str

eam

A

Pro

ject

Str

eam

B

Pro

ject

Str

eam

N

���

Intr

a-Co

nce

ptA

Winn

er

Intr

a-C

once

ptB

Winn

er

Intr

a-Co

nce

ptN

Winn

er

Proj

ect

Sele

ctio

n Pr

oces

s

Pro

cess

Ste

ps

tim

e(n

ot t

o sc

ale)

Conc

ept

Req

uire

men

tsD

efin

ed

Tech

nolo

gyCa

ndid

ate

Prop

osal

sSo

licite

d

Prop

osal

sPe

erRev

iew

ed

Peer

Revi

ewPa

nel

Syst

emPr

opos

alSe

lect

ion

Pane

l

Proj

ect

Plan

Dev

elop

men

tPr

ojec

tRe

view

Boar

d

Fina

lPr

ojec

tSe

lect

ion

Pro

ject

Str

eam

s

A B N…

Sele

cted

Proj

ect(

s)

…P A,1

P A,2

P A,x

P A,u … P A,w

P A,i

…P B,1

P B,2

P B,y

P B,p … P B,s

P B,j

…P N,1

P N,2

P N,z

P N,d … P N,g

P N,k• ~

9-10

mo.

per

pro

ject

sel

ectio

n cy

cle

• 6

mo.

use

d in

pro

ject

pla

n de

velo

pmen

t

Rel

atio

nshi

p Be

twee

n Pr

ojec

tSe

lect

ion

and

Req

uire

men

ts A

naly

sis

�In

itial

pro

ject

str

eam

s (c

once

pts)

def

ined

by

Them

eCu

stom

er’s

req

uire

men

ts�

Com

petit

ion

betw

een

tech

nolo

gy c

andi

date

s in

form

san

d re

fines

pro

ject

str

eam

req

uire

men

ts�

Early

iden

tific

atio

n of

wan

ted

and

unde

sire

d ex

istin

g te

chno

logi

cal

capa

bilit

y, c

osts

and

con

stra

ints

�Te

chno

logy

sel

ectio

n fr

ames

pro

ject

def

initi

on a

nd t

ight

ens

proj

ect

requ

irem

ents

�Co

mpe

titio

n be

twee

n pr

ojec

t st

ream

s al

so r

efin

esea

ch p

roje

ct’s

req

uire

men

ts�

Proj

ect

leve

l req

uire

men

ts a

re u

sed

in p

roje

ct s

elec

tion

deci

sion

,es

peci

ally

neg

ativ

e re

quire

men

ts

Mul

tiple

Par

alle

l Com

petit

ive

Req

uire

men

ts A

naly

sis

(MPC

RA)

�Rel

atio

nshi

p be

twee

n pr

ojec

t ch

oice

s, s

elec

tion

and

requ

irem

ents

ana

lysi

s is

bid

irect

iona

l, no

tun

idire

ctio

nal

�Pr

ojec

ts c

reat

ed a

nd s

elec

ted

requ

irem

ents

�Re

quire

men

ts id

entif

ied

and

fram

ed p

roje

cts,

and

info

rmed

pro

ject

sele

ctio

n

�Fo

und

mul

tiple

par

alle

l com

petit

ive

requ

irem

ents

path

s, n

ot ju

st o

ne�

Refu

tes

trad

ition

al r

equi

rem

ents

ana

lysi

s –

sing

le p

roje

ct p

ath

�O

utco

me

coul

d be

mul

tiple

pro

ject

s, a

s op

pose

d to

the

tra

ditio

nal

assu

mpt

ion

of o

ne

�Ex

tens

ive,

mul

ti-st

ep, w

ell-d

ocum

ente

d, o

pen,

com

petit

ive

proc

ess

built

con

sens

us f

or f

inal

pro

ject

sele

ctio

n

1

The

Past

and

Fut

ure

ofPo

stdo

cA

fifte

en-m

inut

e ov

ervi

ew o

fPo

stdo

c an

d w

here

doc

umen

tco

llabo

rati

on is

hea

ding

.

2

Curr

ent P

ostd

oc: F

eatu

res

•do

cum

ent s

hari

ng u

sing

any

web

brow

ser

•co

mpl

etel

y us

er-m

anag

ed a

cces

sco

ntro

l, gr

oups

, lis

ts•

per-

docu

men

t acc

ess

cont

rol

•au

tom

atic

doc

umen

t con

vers

ion

(MS

Offic

e ->

PDF

)•

inte

grat

ed m

ailin

g lis

ts•

(sim

ple)

lock

ing/

vers

ioni

ng•

easy

-to-

use,

fam

iliar

use

r in

terf

ace

3

Curr

ent P

ostd

oc: U

sage

•De

velo

ped

at A

mes

for

the

New

Mill

enni

um P

rogr

am s

cien

tist

s in

’94,

re-w

ritt

en in

’95

•fr

ee fo

r NA

SA a

nd N

ASA

colla

bora

tors

•~4

500

acti

ve a

ccou

nts (

~280

0 na

sa.g

ov)

•23

5 us

ers

logg

ed in

last

wee

k•

60GB

of d

ata

•~1

,000

e-m

ail m

essa

ges

last

wee

k•

1.5

FTE

deve

lope

rs, 1

.5 F

TE u

ser-

supp

ort 4

Post

doc

Futu

re:

Tech

nolo

gies

Inte

grat

ion

wit

h th

e de

skto

p:•

Web

DAV

for

“dra

g-an

d-dr

op”

inte

grat

ion

into

mod

ern

desk

tops

/app

licat

ions

(inc

ludi

ng A

CL,

DASL

, Del

taV

prot

ocol

s)•

IMAP

/NNT

P fo

r e-

mai

l arc

hive

acc

ess

•m

ulti

-tie

r/m

odul

ar a

rchi

tect

ure

•em

phas

is o

n st

anda

rds-

base

dpr

ogra

mm

atic

acc

ess

for

appl

icat

ion

inte

grat

ion

(Web

Ser

vice

s)

5

Post

doc

Futu

re:

Oppo

rtun

itie

s•

larg

e us

er b

ase

•la

rge

colle

ctio

n of

a w

ide

vari

ety

of d

ocum

ents

•lo

ng-t

erm

his

tori

cal a

rchi

ve•

will

ing

guin

ea p

igs

•NA

SA-o

wne

d da

taba

se, s

yste

m,

soft

war

e•

hopi

ng to

wor

k w

ith

mis

sion

(s)

6

Oblig

ator

y Sc

reen

Sho

t

A Fi

eld

Stud

y of

Col

labo

rati

veSo

ftw

are

Deve

lopm

ent T

eam

s(I

niti

al R

esul

ts)

Clei

dson

de

Souz

a1,2

John

Pen

ix2

Maa

rten

Sie

rhui

s2

1 UC,

Irvi

ne G

radu

ate

Stud

ent a

ndNA

SA/A

mes

Sum

mer

Inte

rn2 N

ASA/

Ames

Res

earc

h Ce

nter

Over

view

�Th

e Se

ttin

g: C

TAS

�M

etho

dolo

gy�

Init

ial F

indi

ngs

�Fu

ture

Wor

k�

Conc

lusi

ons

The

Sett

ing:

Cent

er T

RACO

N Au

tom

atio

n Sy

stem

(CTA

S).

�A

suit

e of

aut

omat

ion

tool

s de

velo

ped

atNA

SA/A

mes

des

igne

d to

hel

p ai

r tr

affic

cont

rolle

rs to

man

age

air

traf

fic fl

ow a

tla

rge

airp

orts

.

�In

199

1 it

was

cho

sen

by th

e FA

A as

the

futu

re a

utom

atio

n sy

stem

for

the

term

inal

are

a.

�Si

nce

then

it h

as b

een

used

in 6

diff

eren

tai

rpor

ts.

The

Sett

ing:

Cent

er T

RACO

N Au

tom

atio

n Sy

stem

(CTA

S).

�CT

AS is

com

pose

d of

10

diffe

rent

tool

s.�

Sour

ce c

ode:

�C

and

C++.

GUI

’s a

re b

eing

por

ted

to J

ava.

� 1

,000

,000

LOC

.�

Deve

lopm

ent T

eam

:�

Num

ber

of d

evel

oper

s: 3

1.�

Two

grou

ps: V

&V

and

Deve

lope

rs.

�W

ork

in p

roce

sses

, ins

tead

of t

ools

Met

hodo

logy

�Fi

eld

Stud

y�

Five

wee

ks in

the

fie

ld u

ntil

now

, fou

r m

ore

wee

ks t

ogo

.

�Da

ta C

olle

ctio

n�

Part

icip

ant O

bser

vati

on�

“Sha

dow

ing”

dev

elop

ers

wit

h di

ffere

nt r

oles

.�

Inte

rvie

w T

echn

ique

s�

4 in

terv

iew

s un

til

now

ran

ging

fr

om

45

to

120

min

utes

.

�Da

ta C

olle

cted

�Se

vera

l art

ifact

s co

llect

ed�

Wha

t de

velo

pers

do,

how

, w

hen,

whe

re t

hey

do,

and

mos

t im

port

antl

y W

HY t

hey

do it

.

Init

ial R

esul

ts

�M

ost i

mpo

rtan

t too

ls:

�co

nfig

urat

ion

man

agem

ent;

and

�bu

g tr

acki

ng s

yste

m.

�Th

ese

tool

s pr

ovid

e sh

ared

rep

osit

orie

sfo

r so

urce

cod

e an

d ch

ange

req

uest

s.�

The

CM a

nd t

he b

ug t

rack

ing

tool

pro

vide

auto

mat

ion

of s

ome

task

s lik

e:�

Vers

ion

cont

rol,

iden

tific

atio

n of

re

leas

es,

repo

rt g

ener

atio

n, a

nd s

o on

.

Init

ial R

esul

ts

�De

velo

pers

ad

opt

conv

enti

ons

tous

e th

ese

tool

s so

tha

t th

ey u

sers

mig

ht c

oope

rate

effe

ctiv

ely.

�Ex

ampl

es:

�Na

min

g co

nven

tion

s fo

r cr

eati

ngbr

anch

s and

vie

ws t

o w

ork

wit

h th

e CM

tool

;�

Prio

riti

es a

nd s

ever

itie

s of

the

bug

s in

the

bug

trac

king

tool

.

Init

ial R

esul

ts

�Ho

wev

er,

the

conv

enti

ons

adop

ted

by

the

deve

lope

rs

are

not

auto

mat

ed.

�Ex

ampl

es:

�Pr

evio

us n

amin

g co

nven

tio

n;�

E-m

ail

sent

by

deve

lope

rs r

ight

befo

re th

e ch

eck-

in.

Init

ial R

esul

ts

�Im

port

ant

com

mun

icat

ion

usin

g e-

mai

l:�

Is

it

the

mos

t ef

fect

ive

tool

to

pr

ovid

eno

tific

atio

ns?

�On

the

oth

er h

and,

e-m

ail

is a

lso

used

as

ale

arni

ng to

ol b

y ne

w d

evel

oper

s, s

o th

at t

hey

can

be a

war

e w

ho i

s re

spon

sibl

e fo

r w

hat

proc

ess.

Thi

s in

form

atio

n is

lat

er u

sed

whe

non

e ha

s to

fix

a bu

g in

that

pro

cess

.

Shor

t Sum

mar

y of

Res

ults

�Co

ordi

nati

on u

sing

CM

and

bug

trac

king

�Us

e of

Con

vent

ions

�Co

mm

unic

atio

n us

ing

E-m

ail

�Pr

oble

mat

ic in

som

e ca

ses;

but

�Pr

ovid

es

awar

enes

s of

ot

hers

wor

k.�

Inte

nse

Para

llel D

evel

opm

ent

Futu

re W

ork

�Da

ta C

olle

ctio

n fo

r 3

mor

e w

eeks

.�

Anal

ysis

of t

he d

ata

�Gr

ound

ed T

heor

y�

Brah

ms

mul

ti-a

gent

mod

el�

Ulti

mat

e go

al:

�Id

enti

fy r

equi

rem

ents

for

tec

hnol

ogy

supp

ort f

or th

is g

roup

.�

If ne

cess

ary,

dev

elop

this

tech

nolo

gy.

Conc

lusi

ons

�CT

AS:

�Su

cces

sful

pro

ject

dev

elop

ed a

t NAS

A/Am

es.

�M

etho

ds�

Init

ial r

esul

ts�

Impo

rtan

t too

ls u

sed

by th

e de

velo

pers

; and

�Pr

oble

ms

wit

h th

ese

tool

s

�Fu

ture

Wor

k

Am

esR

esea

rch

Cen

ter

Kann

a Ra

jan

Colla

b/SW

Eng

WS

8/5/

02

How

do

we

go w

here

no

one

has g

one

befo

re?

Kann

a Ra

jan

Grou

p Le

ad S

pace

craf

t Aut

onom

yAu

tono

my

and

Robo

tics A

rea

NASA

Am

es R

esea

rch

Cent

er(K

anna

.Raj

an@

arc.

nasa

.gov

)

Am

esR

esea

rch

Cen

ter

Kann

a Ra

jan

Colla

b/SW

Eng

WS

8/5/

02

RE

MO

TE

AG

EN

T

EX

PE

RIM

EN

T

http

://i

c.ar

c.na

sa.g

ov/p

roje

cts/

rem

ote

-age

nt/

Dou

glas

E. B

erna

rdJP

LSt

eve

A. C

hien

JPL

Scot

t Dav

ies

CM

UG

rego

ry A

. Dor

ais

Am

esR

icha

rd D

oyle

JPL

Dan

Dvo

rak

JPL

Cha

rles

Fry

Am

esE

dwar

d B

. Gam

ble

Jr.

JPL

Era

nn G

atJP

LB

ob K

anef

sky

Am

esR

on K

eesi

ngA

mes

Jim

Kur

ien

Am

esG

uy K

. Man

JPL

Will

iam

Mill

arAm

esS

unil

Moh

anA

mes

Pau

l Mor

risA

mes

Nic

ola

Mus

cett

ola

Am

esP

. Pan

dura

ng N

ayak

Am

esB

arne

y P

ell

Am

esC

hris

tian

Pla

unt

Am

esG

reg

Rab

idea

uJP

LK

anna

Raj

anA

mes

Nic

hola

s R

ouqu

ette

JPL

Sco

tt S

awye

rA

mes

Rei

d Si

mm

ons

CM

UB

enja

min

Sm

ithJP

LG

regg

Sw

iete

kA

mes

Wil

liam

Tay

lor

Am

esY

u-W

en T

ung

JPL

Mic

hael

Wag

ner

Am

esG

reg

Whe

lan

CM

UB

rian

C. W

illi

ams

Am

esD

avid

Yan

JPL

•• Re

mot

e Ag

ent E

xper

imen

t May

17-

21, 1

999

Rem

ote

Agen

t Exp

erim

ent M

ay 1

7-21

, 199

9••

Rem

ote

Agen

t on

DS1

win

s NA

SA’s

199

9 R

emot

e Ag

ent o

n DS

1 w

ins

NASA

’s 1

999

So

ftw

are

of th

e Ye

ar A

war

dSo

ftw

are

of th

e Ye

ar A

war

d ..

Am

esR

esea

rch

Cen

ter

Kann

a Ra

jan

Colla

b/SW

Eng

WS

8/5/

02

MAP

GEN

for

MER

High

Lev

elOb

serv

atio

n Go

als

Acti

vity

Ed

itor

Fully

Spe

cifie

d Ac

tivity

Pla

n

Sequ

ence

Gene

rato

r

Pla

nnin

g Sy

stem

Pla

nnin

g Sy

stem

Scie

nce

Team

Mod

els

MAP

GEN

MAP

GEN

Alan

Bab

aJP

LJo

hn B

resi

naAR

CLe

n Ch

ares

tJP

LW

ill E

dgin

gton

ARC

Ari J

onss

onAR

CAd

ans K

oJP

LBo

b Ka

nefs

kyAR

CPi

erre

Mal

dagu

e JP

LPa

ul M

orri

sAR

CKa

nna

Raja

nAR

C

Am

esR

esea

rch

Cen

ter

Kann

a Ra

jan

Colla

b/SW

Eng

WS

8/5/

02

Curr

ent D

rive

rs

•Sh

orte

r le

ad ti

mes

to d

esig

n, b

uild

, tes

t and

fly

•De

ep(e

r) sp

ace

mis

sion

s•

Mor

e co

mpl

exit

y–

Visi

ting

com

ets

(CON

TOUR

)–

Long

ran

ge tr

aver

ses

on

Mar

s (M

ER, M

SL)

–Di

stri

bute

d Sp

acec

raft

(LIS

A, D

S3, T

PF)

•M

ore

scie

nce

retu

rn•

Tigh

ter

budg

ets

•Ne

w h

ardw

are

cert

ifica

tion

take

s ti

me

•So

ftw

are

Reus

e•

New

er (b

ette

r?) s

oftw

are

met

hodo

logi

es•

Com

plex

ity

of s

oftw

are

has

rise

n•

Veri

ficat

ion

and

Valid

atio

n is

cri

tical

•In

ter-

cent

er c

olla

bora

tion

Am

esR

esea

rch

Cen

ter

Kann

a Ra

jan

Colla

b/SW

Eng

WS

8/5/

02

Resu

lts

•Te

stin

g ha

s bec

ome

cent

ral i

n s/

w d

evel

opm

ent

•No

tion

of a

“pr

oces

s” to

des

ign/

build

/tes

t/de

ploy

•No

tion

of m

odel

-bas

ed a

ppro

ache

s on

the

incr

ease

•Kn

owle

dge

Acqu

isit

ion

met

hods

are

bec

omin

gcr

ucia

l•

Stru

ggle

to fi

nd w

ays t

o co

llabo

rate

acr

oss t

ime-

zone

s and

cul

ture

s–

MER •

10’s

of s

cien

tist

s du

ring

the

desi

gn p

hase

•30

0+ m

issi

on s

taff

(JPL

)•

200+

scie

ntis

ts d

urin

g m

issi

on o

ps

Am

esR

esea

rch

Cen

ter

Kann

a Ra

jan

Colla

b/SW

Eng

WS

8/5/

02

Need

s

•Fo

rmal

met

hods

for

V&V

for

auto

nom

ous s

yste

ms

•To

ols

for

Elic

itat

ion

•Ri

ch a

rray

of m

etho

ds fo

r so

ftw

are

synt

hesi

s•

Colla

bora

tive

met

hods

for

desi

gn

Fo

rma

l P

ee

r In

sp

ecti

on

In

form

ati

on

Arc

hit

ectu

re

Gild

a P

our,

Ph.D

., D

.Eng.

Colla

bora

tive S

oft

ware

Engin

eering T

ools

Work

shop

8/5

/02So

ftw

are

De

ve

lop

me

nt

Fo

rma

l P

ee

r In

sp

ecti

on

Help

s m

itig

ate

ris

ks

in s

oft

ware

develo

pm

ent

and im

pro

ve s

oft

ware

qualit

y

8/5

/02So

ftw

are

De

ve

lop

me

nt

Fo

rma

l P

ee

r In

sp

ecti

on

(co

nt’

d)

•Part

icip

ants

–D

iffe

rent

role

s (e

.g. W

ork

Pro

duct

Auth

or,

M

odera

tor,

Pro

duct

Are

a L

ead, In

spect

or)

–D

iffe

rent

resp

onsi

bili

ties

for

each

role

•In

spect

ion d

ocu

ments

and t

ools

–

Diffe

rent

form

ats

and s

truct

ure

s

–Loca

ted o

n d

iffe

rent

pla

tform

s

–Loca

ted in d

iffe

rent

physi

cal and logic

al lo

cations

8/5

/02

Fo

rma

l P

ee

r In

sp

ecti

on

Ch

eck

ou

t &

La

un

ch

Co

ntr

ol

Syste

m(C

LC

S)

8/5

/02

8/5

/02Ob

jecti

ve

To d

evelo

p a

cust

om

izable

, exte

nsi

ble

, and f

lexib

le W

eb-b

ase

d a

rchitect

ure

to

support

soft

ware

develo

pm

ent

form

al

peer

insp

ect

ion

8/5

/02Ap

pro

ach

•Com

ponent-

base

d s

oft

ware

engin

eering

•XM

L s

chem

a a

nd X

SL

8/5

/02In

sp

ecti

on

Do

cu

me

nts

•Role

-base

d I

nsp

ect

ion C

heck

lists

-W

ork

Pro

duct

Auth

or’s

Insp

ect

ion C

heck

list

-In

spect

or’s

Insp

ect

ion C

heck

list

-Pro

duct

Are

a L

ead I

nsp

ect

ion C

heck

list

-In

spect

ion M

odera

tor’s

Insp

ect

ion C

heck

list

8/5

/02In

sp

ecti

on

Do

cu

me

nts

(co

nt’

d)

•W

ork

Pro

duct

Insp

ect

ion C

heck

lists

-D

ocu

ment-

Work

Pro

duct

Check

list

-Requirem

ent’s

Speci

fica

tion-W

ork

Pro

duct

Insp

ect

ion

Check

list

-H

igh-L

evel D

esi

gn -

Work

Pro

duct

Insp

ect

ion C

heck

list

-D

eta

iled D

esi

gn -

Work

Pro

duct

Insp

ect

ion C

heck

list

-Code I

nsp

ect

ion -

Work

Pro

duct

Insp

ect

ion C

heck

list

-Test

Pla

n -

Work

Pro

duct

Insp

ect

ion C

heck

list

-Test

Pro

cedure

–W

ork

Pro

duct

Insp

ect

ion C

heck

list

8/5

/02In

sp

ecti

on

Do

cu

me

nts

(co

nt’

d)

•Peer

Insp

ect

ion I

nvitation f

orm

•Peer

Insp

ect

ion P

lannin

g C

heck

list

•O

verv

iew

•Lis

ting o

f Refe

rence

Mate

rials

(e.g

. Sta

ndard

s, U

ser

Guid

es)

•Sum

mary

of

list

of

open iss

ues

that

need t

o b

e

revie

wed a

nd/o

r addre

ssed

•Peer

Insp

ect

ion D

efe

ct L

og f

orm

•In

spect

ion S

um

mary

/Clo

sure

Report

•In

spect

ion S

atisf

act

ion S

urv

ey f

orm

8/5

/02

Ex

am

ple

Ro

le-B

ase

d I

nsp

ecti

on

Ch

eck

list

Co

mp

on

en

t

•Role

of

the insp

ect

ion p

art

icip

ant

(Variable

s in

clude w

ork

pro

duct

auth

or,

insp

ect

or,

pro

duct

are

a lead insp

ect

or,

and m

odera

tor.

)

•In

spect

ion p

hase

(Variable

s in

clude p

lannin

g, overv

iew

, in

spect

ion

pre

para

tion, in

spect

ion m

eeting, in

spect

ion r

ew

ork

/follo

w-u

p, and

pro

ject

analy

sis.

)

•Resp

onsi

bili

ties

of

a s

peci

fic

role

in v

arious

insp

ect

ion p

hase

s

•Pro

ject

identifica

tion n

um

ber

(ID

)

•W

ork

pro

duct

bein

g insp

ect

ed (

Variable

s in

clude d

ocu

ments

, co

nce

pt

definitio

ns,

requirem

ents

speci

fica

tions,

top-level desi

gn,

deta

iled d

esi

gn, co

de, te

st p

lans,

test

pro

cedure

s, t

est

tools

, and

test

scr

ipts

.)

•N

am

e o

f th

e insp

ect

ion p

art

icip

ant

•D

ate

of

com

ple

tion f

or

each

task

lis

ted u

nder

“Resp

onsi

bili

ties”

•In

spect

ion loca

tion

8/5

/02

8/5

/02

8/5

/02Next

Phase

•W

eb-b

ase

d e

nte

rprise

arc

hitect

ure

to

support

soft

ware

develo

pm

ent

form

al

peer

insp

ect

ion a

t th

e e

nte

rprise

level

•Loca

tion-t

ransp

are

nt

acc

ess

of

auth

orize

d u

sers

to insp

ect

ion

docu

ments

and t

ools

at

the e

nte

rprise

le

vel

BR

AH

MS

: a

BR

AH

MS

: a

mu

ltia

gen

tm

ult

iagen

tm

od

elin

gm

od

elin

g

an

d s

imu

lati

on

lan

gu

age

for

work

an

d s

imu

lati

on

lan

gu

age

for

work

syst

em a

na

lysi

s a

nd

des

ign

syst

em a

na

lysi

s a

nd

des

ign

Maart

enM

aart

enS

ierh

uis

Sie

rhu

is, P

h.D

., P

h.D

.

Sen

ior

Sci

enti

stS

enio

r S

cien

tist

US

RA

/RIA

CS

US

RA

/RIA

CS

NA

SA

Am

es R

esea

rch

Cen

ter

NA

SA

Am

es R

esea

rch

Cen

ter

Moff

ett

Fie

ld, C

AM

off

ett

Fie

ld, C

A

msi

erh

uis

msi

erh

uis

@m

ail

.arc

.@

mail

.arc

. nasa

nasa

.. gov

gov

Au

gu

st 6

, 2002

ISR

-NA

SA

Work

shop o

n

Coll

abora

tive

Soft

ware

En

gin

eeri

ng

ToolsHCC:From Simulation to

Implementation

Th

e R

ock

et S

cien

ce o

f H

CC

CO

MP

UT

ER

Wh

at’

s th

e D

elta

?

Co

ord

ina

tem

ult

imo

da

lco

nce

pts

,valu

es, p

ract

ice

Measu

re, cla

ssif

y, in

fer,

dep

ict,

pro

cess

HU

MA

N

Researc

h Q

uesti

on

•H

ow

can

we m

od

el an

org

an

izati

on

’s w

ork

pra

cti

ce in

su

ch

a w

ay t

hat

we in

clu

de p

eo

ple

’s

co

llab

ora

tio

n,“o

ff-t

as

k”

be

ha

vio

rs,m

ult

i-ta

skin

g,

inte

rru

pte

d a

nd

resu

med

acti

vit

ies,in

form

al

inte

rac

tio

nan

dg

eo

gra

ph

y?

•O

bje

cti

ve i

s t

o f

ind r

epre

senta

tions a

nd t

echniq

ues f

or

analy

zin

g a

nd d

esig

nin

g w

ork

syste

ms (

socio

-technic

al

syste

ms)

holi

sti

call

y a

nd h

um

an-c

ente

red

Work

Pra

cti

ce

Defi

nit

ion

The p

erf

orm

ance o

f colle

ctive s

ituate

d

activities

of a g

roup o

f people

, colla

bora

ting,

com

munic

ating, and g

ain

ing e

xperience w

hile

perf

orm

ing these a

ctivitie

s s

ynchro

nously

or

asynchro

nously

.

Wo

rk P

racti

ce M

od

eli

ng

•G

rou

ps

& A

gen

ts

–w

ork

as a

cti

vit

ies

–beli

efs

tri

gger

work

–bounded r

ati

onali

ty i

s s

ocia

lly

and c

ult

ura

lly d

efi

ned

•C

oll

ab

ora

tio

n b

etw

een

Ag

ents

–ag

en

ts r

eact

to a

nd

in

tera

ct

wit

h o

ther

ag

en

ts

–sam

e t

ime/s

am

e p

lace

–sam

e t

ime/d

iffe

rent

pla

ce

–dif

fere

nt

tim

e/s

am

e p

lace

–dif

fere

nt

tim

e/d

iffe

rent

pla

ce

WP

M c

ont’

d

•T

ools

& A

rtif

act

s

–to

ols

used

in

acti

vit

ies

–art

ifacts

cre

ate

d i

n a

cti

vit

ies

•E

nvir

on

men

t/G

eogra

ph

y

–agents

have a

locati

on

–art

ifacts

hav

e a

lo

cati

on

–dete

cti

ng

real-

wo

rld

facts

•C

om

mu

nic

ati

on

–is

sit

uate

d

–th

e m

eans o

f com

munic

ati

on

depends o

n t

he s

ituati

on (

e.g

.

voic

e l

oop, f2

f com

munic

ati

on,

tele

phone, fa

xin

g, e-m

ail

)

–im

pacts

eff

icie

ncy

of

wo

rk

Bra

hm

s

Agen

tA

gen

t --O

rien

ted

Lan

gu

age

Ori

ente

d L

an

gu

age

Lan

gu

age

Pars

erL

an

gu

age

Pars

er

Inte

ract

ive

Dev

elop

men

t E

nvir

on

men

t In

tera

ctiv

e D

evel

op

men

t E

nvir

on

men

t

Dis

cret

eD

iscr

ete-- e

ven

t S

imu

lati

on

En

gin

eev

ent

Sim

ula

tion

En

gin

e

En

dE

nd

-- use

r S

imu

lati

on

Dis

pla

ys

use

r S

imu

lati

on

Dis

pla

ys

Sim

ula

tion

His

tory

Data

Base

Sim

ula

tion

His

tory

Data

Base

Java-b

ase

d

Java A

PI

XM

L

Ru

ns

on

PC

’s,

Mac,

Un

ix,

Lin

ux .

..

©M

aart

en

Sie

rhu

is

Coll

abora

tive M

odeli

ng

Bra

hm

s S

imu

lati

on

VR

Mo

del

/Ag

entV

iew

erE

thn

ogra

ph

ic O

bse

rvati

on

Vid

eo A

naly

sis

Con

cep

tual

Mod

elin

g

Bra

hm

s M

od

elin

g

con

cep

tua

l m

od

eler

s

Bra

hm

s m

od

eler

s

Desig

n, G

enera

te a

nd S

imula

te

M1

Bra

hm

s C

od

e G

ener

ati

on

M3

/M4

M2

Co

nce

ptu

al

Mo

del

Sim

ula

tion

/Vis

uali

zati

on

Bra

hm

s R

esearc

h

Pro

jects

at

NA

SA

•H

um

an-R

oboti

c T

eam

work

–T

eam

work

& W

ork

Pra

cti

ce o

nboard

the I

SS

–M

obil

e A

gents

support

ing o

f M

ars

Explo

rati

on

•M

ars

Habit

at

–L

ivin

g a

nd

wo

rkin

g o

n M

ars

•’0

3 M

ars

Explo

rati

on R

over

–U

se B

rahm

s t

o m

odel

Mis

sio

n O

pera

tions W

ork

Syste

m a

t

JP

L

Mo

bil

e A

gen

ts

Runti

me

•M

od

els

of

Peo

ple

& R

ob

ots

•In

tell

igent

Assis

tants

–A

gents

for

people

& r

obots

•S

oft

ware

Ag

en

ts

–D

ialo

g a

gen

t

–C

om

munic

ati

on A

gent

–P

rox

y a

gen

t

Desig

n P

hase

•S

imula

ted P

eople

& R

obots

•In

tell

igent

Assis

tants

•S

oft

ware

Agents

(sim

ula

ted)

•S

oft

ware

Syste

ms (

sim

ula

ted)

ER

A B

rah

ms

AT

V a

gen

ts

Dia

log

ag

ent

Pro

xy

ag

ents

Dia

log S

yst

em

AT

V

Co

mm

. a

gen

t

Co

mm

. a

gen

t

AT

V B

rah

ms

ER

A a

gen

t

Co

mm

. a

gen

t

Pro

xy

ag

ents

ER

A

WA

NA

TV

Rep

eate

r

Ro

ck

y s

erv

er

Bra

hm

s

Dia

log

Sys

tem

wir

ele

ss

mic

Ex

plo

rer

Eva R

ob

oti

c A

ssis

tan

t

Bra

hm

s

Mo

bil

e A

ge

nts

Arc

hit

ec

ture

Mo

bil

e A

ge

nts

Arc

hit

ec

ture

Sim

ula

tion

of

MO

S

Wo

rk P

roce

ss f

or

ME

R M

OS

Des

ign

Coll

abora

tive D

esig

n

wit

h M

ER

MO

S D

T

Cre

ati

on

of

new

sci

ence

pla

ns

(bo

un

da

ry o

bje

cts)

an

d c

om

mu

nic

ati

ng

to

oth

ers

Walk

ing T

ak

es T

ime!

!!!

Wa

lkin

g f

rom

Sci

ence

Ro

om

to

Co

nfe

ren

ce R

oo

m

ISS

Pro

ject

Go

als

•E

xte

rna

l g

oa

ls

•art

ifactto

stu

dy a

nd u

nders

tand w

ork

pra

ctices a

nd

team

work

onboard

IS

S

•m

odelto

be u

sed in:

•p

lan

nin

g.IS

S M

issio

n p

lannin

g a

nd p

rocedure

develo

pm

ent

•execution.

HC

I: A

uto

nom

ous Inte

lligent S

oftw

are

or

Robotic A

gents

(e.g

. P

SA

, R

obonaut)

in s

upport

of

team

work

.

•In

tern

al g

oa

ls

•E

xplo

re u

se o

f B

rahm

s in r

epre

senting m

anned s

pace

mis

sio

ns

•S

tudy B

rahm

s a

s a

n A

BS

S(D

avid

sso

n,

20

02

)

Mo

deli

ng

th

e I

SS

cre

w

wit

h B

rah

ms

•D

ata

•V

ideos, pic

ture

s, in

terv

iew

s

•JS

C m

anuals

, pro

cedure

s

•T

ime

line

s, sch

ed

ule

s

•O

n-o

rbit a

nd p

ost-

orb

it d

ebriefs

•M

OD

se

rve

rs

•W

ork

pra

ctice

da

ta a

na

lysis

•C

on

ce

ptu

al m

od

elin

g

•B

rah

ms m

od

el a

nd

sim

ula

tio

n

Mo

rnin

g A

ctiv

itie

s IS

S E

xp

2,

Ma

y 7

, 2

00

1

6 Au

gust

, 200

2NA

SA -

ISR

Wor

ksho

p

Even

t Not

ifica

tion

and

Mes

sagi

ng A

rchi

tect

ures

for

Real

-Tim

e Sc

ienc

e Co

ordi

nati

on

Elia

s Sin

ders

onel

ias@

cse.

ucsc

.edu

elia

s@em

ail.a

rc.n

asa.

gov

UC S

anta

Cru

z /

NASA

Am

es

6 Au

gust

, 200

2NA

SA -

ISR

Wor

ksho

p

Term

s an

d De

finit

ions

•Co

llabo

rati

on v

s.Co

ordi

nati

on–

Rela

ted,

but

use

ful t

odi

stin

guis

h be

twee

nth

e tw

o–

Colla

bora

tion

is w

hen

peop

le w

ork

toge

ther

on a

giv

en ta

sk–

Coor

dina

tion

impl

ies

that

mul

tipl

e,in

terd

epen

dent

task

sex

ist

•Re

al-t

ime

scie

nce

–Ha

rd d

eadl

ines

–Cl

osed

con

trol

or

feed

back

loop

–Ex

ampl

e: R

emot

eop

erat

ion

of a

sci

ence

plat

form

suc

h as

asa

telli

te, s

pace

pro

beor

rob

ot

6 Au

gust

, 200

2NA

SA -

ISR

Wor

ksho

p

Som

e of

the

Chal

leng

es

•Hi

gh c

omm

unic

atio

n ov

erhe

ad•

Shift

ing/

rota

ting

sch

edul

es•

Data

nav

igat

ion

and

assi

mila

tion

•M

aint

aini

ng s

itua

tion

al a

war

enes

s•

Tim

e se

nsit

ive

natu

re o

f mis

sion

oper

atio

ns•

Hete

roge

neou

s co

mpu

ting

env

iron

men

t•

Secu

rity

!

6 Au

gust

, 200

2NA

SA -

ISR

Wor

ksho

p

Requ

irem

ents

and

Pro

pose

dSo

luti

ons

•Pr

ovid

e ‘o

ne st

op’ a

cces

s to

mul

tipl

ere

posi

tori

es a

nd d

ata

anal

ysis

tool

s und

er a

com

mon

, Web

-bas

ed in

terf

ace

•No

tific

atio

n of

‘act

ive’

res

ourc

es...

•In

crea

se o

vera

ll aw

aren

ess o

f mis

sion

pers

onne

l:–

Sche

dulin

g to

ols

–Da

ta n

avig

atio

n to

ols–

Mis

sion

scor

ecar

ds–

New

s bro

adca

sts

6 Au

gust

, 200

2NA

SA -

ISR

Wor

ksho

p

Even

t Not

ifica

tion

/M

essa

ging

•Tr

adeo

ffs b

etw

een

expr

essi

vene

ss a

ndsc

alab

ility

nee

d to

be

reco

ncile

d•

Hete

roge

neou

s nat

ure

of d

ata

repo

sito

ries

and

lega

cy s

yste

ms

mak

esin

stru

men

ting

them

diff

icul

t•

Need

for

a co

mpl

ete

and

robu

st d

omai

nm

odel

6 Au

gust

, 200

2NA

SA -

ISR

Wor

ksho

p

Even

t Not

ifica

tion

/M

essa

ging

•Re

mot

e fil

e sy

stem

s can

be

mon

itor

ed a

ndlo

gged

wit

h ut

iliti

es su

ch a

s nf

slog

d, a

udit

d,et

c.•

Som

e da

taba

ses s

uppo

rt st

ored

pro

cedu

res

•Pu

sh r

athe

r th

an p

ull i

nfor

mat

ion

whe

reve

rpo

ssib

le to

min

imiz

e lo

ad o

n sy

stem

and

netw

ork

6 Au

gust

, 200

2NA

SA -

ISR

Wor

ksho

p

A Si

mpl

e (?

) Exa

mpl

e Met

adat

abas

e /

File

Sys

tem

Clie

nt P

ort

al

Pub/

Sub

file

exch

ange

DB Q

uery

Too

ls

Prog

ram

mat

ic A

PI

Lo

ader

daem

on

Ana

lyst

s N

oteb

ook

Port

let

Web

Site

s

Ser

ver

Co

de

JMS

6 Au

gust

, 200

2NA

SA -

ISR

Wor

ksho

p

Chan

ge A

war

enes

sDa

shbo

ard

•Ac

tive

res

ourc

es a

reth

e pr

imar

y ob

ject

s of

inte

rest

•Ea

sy a

cces

s to

reso

urce

s•

Min

imal

ly in

vasi

ve•

Peri

pher

al a

war

enes

s•

User

pre

fere

nces

•Su

bscr

ipti

on p

ersi

sten

ce–

Rees

tabl

ishe

s se

ssio

nsw

hen

user

s sta

rt th

eir

shift

•No

tific

atio

n pe

rsist

ence

–Ke

eps u

sers

up

to d

ate

wit

h an

y ch

ange

s sin

ceth

ey la

st lo

gged

on

6 Au

gust

, 200

2NA

SA -

ISR

Wor

ksho

p

Futu

re A

ctiv

itie

s

•Fi

nish

the

impl

emen

tati

on o

ver

the

next

yea

r•

Colle

ct u

ser

feed

back

on s

yste

m–

Valid

atio

n of

GUI

desi

gn–

Com

pari

sons

wit

hot

her

mis

sion

s

•W

orkf

low

ana

lysi

s of

Ops

envi

ronm

ent

•De

velo

p w

eb s

ervi

ces

for

mob

ile a

ndha

ndhe

ld d

evic

es•

Exte

nd s

yste

m to

supp

ort m

ulti

ple

site

s

UCI -

Red

mile

s

Usin

g Ev

ent N

otifi

cati

on S

erve

rs to

Sup

port

Awar

enes

sDa

vid

Redm

iles

Asso

ciat

e Pr

ofes

sor

Clei

dson

R. B

. De

Souz

a, S

anth

oshi

D. B

., Ro

bert

o S.

S. F

ilho

Grad

uate

Stu

dent

Res

earc

hers

Max

Sla

byak

Unde

rgra

duat

e St

uden

t Res

earc

her

Mic

hael

Kan

tor

(PhD

’01)

Post

Doc

tora

l Stu

dent

UCI -

Red

mile

s

Awar

enes

s an

d Co

llabo

rati

on

•In

gen

eral

, aw

aren

ess m

eans

hav

ing

info

rmat

ion

abou

t oth

er a

ctiv

itie

s th

at a

ffect

sa

pers

on’s

ow

n w

ork

[DB9

2].

•So

me

type

s of

aw

aren

ess

–Gr

oup

awar

enes

s•

Who

is a

roun

d an

d w

hat r

ough

ly a

re th

ey d

oing

?•

e.g.

, im

ages

rel

ayed

in P

orth

oles

–Pr

ojec

t aw

aren

ess

•W

hat k

now

ledg

e af

fect

s (e

.g.,

deci

sion

s ar

e m

ade

abou

t)pr

ojec

t con

tent

?•

e.g.

, sub

scri

ptio

ns in

Kno

wle

dge

Depo

t–

Appl

icat

ion

awar

enes

s•

Wha

t’s

goin

g on

in r

unni

ng s

oftw

are?

•E.

g., a

rchi

tect

ural

gau

ge

UCI -

Red

mile

s

Exam

ple:

Gro

up A

war

enes

s th

roug

ha

Port

hole

s Sy

stem

[GLT

99]

•Sh

ows p

rese

nce

of c

olla

bora

tors

and

rele

vant

spac

es

•Us

es v

isua

l cue

s(s

uch

as th

isth

eate

r st

yle)

toco

nden

se v

iew

acco

rdin

g to

rele

vanc

e.

Gir

gens

ohn

/ Lee

/ T

urne

r 99

Loo

king

for

job!

!!

UCI -

Red

mile

s

Expl

aine

r [R

ed93

]

•Ea

rly

Hype

rmed

iafo

r hu

man

lear

ning

by

exam

ple

•Ex

trem

ehy

per-

gran

ular

ity

•In

crem

enta

l[M

inim

al]

Expl

anat

ion

•Hu

man

Vari

abili

tyRe

duce

d

UCI -

Red

mile

s

Argo

/UM

L [R

HR98

] [RR

00]

Whi

le d

esig

ners

wor

k, d

esig

ncr

itic

s ana

lyze

the

desi

gn a

ndpr

ovid

e he

lpfu

lad

vice

. Th

e “t

odo

” lis

t (lo

wer

left

) pre

sent

s and

orga

nize

s ad

vice

abou

t pen

ding

desi

gn c

hang

es.

UCI -

Red

mile

s

EDEM

– E

xpec

tati

on-D

rive

n Ev

ent

Mon

itor

ing

[HR9

8]Ag

ents

mon

itor

app

licat

ion

even

ts

And

opti

onal

ly fa

cilit

ate

feed

back

.

UCI -

Red

mile

s

Know

ledg

e De

pot [

KRZ9

7]K

anto

r, R

edm

iles,

Zim

mer

man

n 97

Loo

king

for

job!

!!

UCI -

Red

mile

s

Gaug

es fo

r Ap

plic

atio

n Aw

aren

ess

[SBR

02] Ar

chit

ectu

ral M

essa

ge P

assi

ng M

onit

or

UCI -

Red

mile

s

a) P

rogr

ess B

ar

b) B

ar C

hart

f) S

igna

l

c) L

ine

Grap

hd)

Clo

cke)

Loa

d

Som

e M

ore

Gaug

es [S

BR02

] UCI -

Red

mile

s

Acti

vity

The

ory

and

Desi

gn [R

ed02

a][C

SR02

]•

Iden

tify

the

stak

ehol

ders

inth

e pr

oces

s.•

Help

ens

ure

that

tech

nolo

gy is

des

igne

d to

the

user

s, o

ther

stak

ehol

ders

, and

the

orga

niza

tion

.•

Wor

k to

war

d al

ignm

ent

betw

een

user

s’ r

ewar

dsan

d bu

sine

ss’ n

eeds

.•

Wor

k to

war

d al

ignm

ent

betw

een

the

rew

ards

of

the

desi

gner

s of t

he d

evic

ean

d bo

th th

e en

d us

ers’

and

busi

ness

’ nee

ds.

SUB

JEC

T

RU

LE

SC

OM

MU

NIT

Y

DIV

ISIO

NO

F L

AB

OR

OB

JEC

T

ME

DIA

TIN

G A

RT

IFA

CT

S

OU

TC

OM

E

Eng

estr

öm [

Eng

90]

Act

ivit

y Sy

stem

Mod

el

UCI -

Red

mile

s

Them

e -

Awar

enes

s In

form

atio

n

•Ar

go/U

ML

–Cr

itic

s no

tify

end

use

rs o

f des

ign

prob

lem

s

•ED

EM–

Agen

ts m

onit

or a

pplic

atio

n us

age

and

repo

rt d

ata

to d

esig

ners

•Kn

owle

dge

Depo

t–

End

user

s su

bscr

ibe

to e

mai

l cat

egor

ies

/ to

pics

•Ga

uges

–“P

robe

s” (i

nstr

umen

tatio

n) s

houl

d co

llect

spe

cific

info

rmat

ion

abou

t dis

trib

uted

app

licat

ions

’ beh

avio

r an

d pe

rfor

man

ce a

ndsu

pply

this

info

rmat

ion

to n

arro

w-p

urpo

sed

“Gau

ges”

(vis

ualiz

atio

ns)

•Ac

tivi

ty T

heor

y–

Man

y pe

ople

and

thin

gs a

ffect

the

achi

evem

ent o

f an

obje

ctiv

e.

UCI -

Red

mile

s

Even

t Not

ifica

tion

Ser

vice

•In

form

atio

n So

urce

s

•In

form

atio

nCo

nsum

ers

(Gau

ges)

•Ev

ent N

otifi

cati

onSe

rver

s

•Ev

ent S

ervi

ces

–Pu

blis

h (P

ost)

–No

tify

(Rec

eive

)–

Subs

crib

e

Info

rmat

ion

sour

ceIn

form

atio

n so

urce

Info

rmat

ion

cons

umer

NO

TIF

ICA

TIO

N S

ER

VE

RN

OT

IFIC

AT

ION

SE

RV

ER

PUBLISH

Info

rmat

ion

cons

umer

Info

rmat

ion

cons

umer

NOTIFY

NOTIFY

NOTIFY

S U B S C R I B E

S U B S C R I B E

S U B S C R I B E

UCI -

Red

mile

s

Usin

g th

e CA

SS S

trat

egy

Info

rmat

ion

Sour

ce: A

WA

CS

Sim

ulat

or

Not

ific

atio

n se

rver

: CA

SSIU

S

Gau

ge 1

Gau

ge 2

Gau

ge 3

Gau

ge n

UCI -

Red

mile

s

Not

ific

atio

nS

erve

r

Phys

ical

Env

iron

men

ts

(Por

thol

es, A

ctiv

e B

adge

s)C

ompl

ex to

ols:

Por

thol

es

Sim

ple

desk

top

wid

gets

Mob

ile A

war

enes

s

Am

bien

t Fix

ture

s [i

shii]

Shar

ed A

rtif

acts

(Pap

ers,

spr

eads

heet

s, d

atab

ases

)

Vir

tual

Env

iron

men

ts(M

UD

s, c

hat r

oom

s)

Aw

aren

ess

Too

lsIn

form

atio

n So

urce

s

Mob

ile W

orke

rs(C

usto

mer

Rep

, Sup

port

Sta

ff)

Wri

ter

Dev

elop

erPr

inte

rD

ocum

ent

UCI -

Red

mile

s

CASS

IUS

serv

erAW

ACS

Sim

ulat

or

Gaug

es

CASS

IUS

[KR0

1]In

terc

hang

eabi

lity

and

the

Deta

il-Va

riet

yTr

adeo

ff

UCI -

Red

mile

s

How

eas

y is

it to

prov

ide

inte

grat

edaw

aren

ess?

UCI -

Red

mile

s

Issu

es

•Ho

w g

auge

s ar

e no

tifie

d ab

out t

he e

vent

s or

The

Issu

e of

Push

vs.

Pul

l Arc

hite

ctur

es b

etw

een

the

noti

ficat

ion

serv

eran

d th

e ga

uges

?

•Ho

w p

ower

ful i

s th

e su

bscr

ipti

on s

ervi

ce fo

r ea

chno

tific

atio

n se

rver

? Wha

t are

the

type

s of

mat

chin

gsu

ppor

ted?

•W

hich

obj

ects

can

send

eve

nts t

o th

e no

tific

atio

n se

rver

, or

Issu

es a

bout

eve

nt a

nd o

bjec

t reg

istr

atio

n?

•W

hich

met

a-in

form

atio

n is

ass

ocia

ted

to th

e ev

ents

sen

t to

the

noti

ficat

ion

serv

er o

r Ho

w p

ower

ful a

re th

e ev

ents

?

•W

hat a

re th

e in

terf

aces

impl

emen

ted

by th

e no

tific

atio

nse

rver

s, o

r ho

w e

asy

to c

hang

e fr

om a

not

ifica

tion

ser

ver

toan

othe

r?

UCI -

Red

mile

s

Conc

lusi

ons

•Th

e av

aila

ble

soft

war

e (e

.g.,

notif

icat

ion

serv

ers)

for

build

ing

syst

ems

inco

rpor

atin

gaw

aren

ess

info

rmat

ion

is v

ery

low

-lev

el a

ndpr

one

to d

esig

n an

d pr

ogra

mm

ing

erro

rs.

•Su

ppor

t for

com

plex

, het

erog

eneo

us s

yste

ms

(e.g

., m

ulti

ple

diffe

rent

, ser

vers

, inf

orm

atio

nso

urce

s, a

nd c

onsu

mer

s) v

arie

s, c

urre

ntly

desi

gner

s m

ust e

xpen

d ex

tra

effo

rt to

des

ign

for

chan

ge a

nd fl

exib

ility

.•

The

goal

is u

sabi

lity—

we

seek

to p

rovi

de a

set

of u

sabl

e an

d us

eful

ser

vice

s an

d st

rate

gy to

prov

ide

usab

le a

nd u

sefu

l aw

aren

ess

capa

bilit

ies

for

appl

icat

ions

.

UCI -

Red

mile

s

In o

ther

wor

ds …

•A

grea

ter

vari

ety

of a

war

enes

s dev

ices

…–

Crit

ics

–Us

abili

ty e

xpec

tati

ons

–Em

ail n

otifi

cati

ons

–Ap

plic

atio

n ga

uges

–Se

curi

ty a

nd p

riva

cy g

auge

s?–

Port

hole

s?

… in

tegr

ated

thro

ugh

an e

vent

not

ifica

tion

infr

astr

uctu

re

UCI -

Red

mile

s

Refe

renc

es

UCI -

Red

mile

s

Refe

renc

es

•Gi

rgen

sohn

, A.,

Lee,

A.,

Turn

er, T

. Bei

ng in

Pub

lic a

nd R

ecip

roci

ty: D

esig

n fo

r Po

rtho

les

and

User

Pre

fere

nce,

In H

uman

-Co

mpu

ter

Inte

ract

ion

INTE

RACT

'99,

IOS

Pres

s, p

p. 4

58-4

65, 1

999.

•Re

dmile

s, D

. Red

ucin

g th

e Va

riab

ility

of P

rog

ram

mer

s’ P

erfo

rman

ce T

hrou

gh E

xpla

ined

Exa

mpl

es, H

uman

Fac

tors

inCo

mpu

ting

Sys

tem

s, IN

TERC

HI ‘9

3 Co

nfer

ence

Pro

ceed

ings

(Am

ster

dam

, The

Net

herl

ands

), AC

M, A

pril

1993

, pp.

67-

73.

•Ro

bbin

s, J

., Hi

lber

t, D.

, Red

mile

s, D

. Ext

endi

ng D

esig

n En

viro

nmen

ts to

Sof

twar

e Ar

chit

ectu

re D

esig

n, A

utom

ated

Sof

twar

eEn

gine

erin

g, V

ol. 5

, No.

3, J

uly

1998

, pp.

261

-290

•Ro

bbin

s, J

., Re

dmile

s, D

. Cog

niti

ve S

uppo

rt, U

ML

Adhe

renc

e, a

nd X

MI I

nter

chan

ge in

Arg

o/UM

L, In

form

atio

n an

d So

ftw

are

Tech

nolo

gy, V

ol. 4

2, N

o.2,

Jan

uary

200

0, p

p.79

-89.

•Hi

lber

t, D.

, Red

mile

s, D

. An

Appr

oach

to

Larg

e-Sc

ale

Colle

ctio

n of

App

licat

ion

Usag

e Da

ta O

ver

the

Inte

rnet

, Pro

ceed

ings

of

the

Twen

tiet

h In

tern

atio

nal C

onfe

renc

e on

Sof

twar

e En

gine

erin

g (I

CSE

‘98,

Kyo

to, J

apan

), IE

EE C

ompu

ter

Soci

ety

Pres

s,Ap

ril 1

9-25

, 199

8, p

p. 1

36-1

45.

•Ka

ntor

, M.,

Zim

mer

man

n, B

., Re

dmile

s, D

. Fro

m G

roup

Mem

ory

to P

roje

ct A

war

enes

s Th

roug

h Us

e of

the

Kno

wle

dge

Depo

t,Pr

ocee

ding

s of t

he 1

997

Calif

orni

a So

ftw

are

Sym

posi

um (I

rvin

e, C

A), U

CI Ir

vine

Res

earc

h Un

it in

Sof

twar

e, Ir

vine

, CA,

Nove

mbe

r 7,

199

7, p

p. 1

9-26

.•

Kant

or, M

., Re

dmile

s, D

. Cre

atin

g an

Infr

astr

uctu

re fo

r Ub

iqui

tous

Aw

aren

ess,

Eig

ht IF

IP T

C 13

Con

fere

nce

on H

uman

-Co

mpu

ter

Inte

ract

ion

(INT

ERAC

T 20

01, T

okyo

, Jap

an),

July

200

1, p

p. 4

31-4

38.

•de

Sou

za,C

.R.B

., Ba

save

swar

a, S

.D.,

Redm

iles,

D. U

sing

Eve

nt N

otifi

cati

on S

erve

rs t

o Su

ppor

t App

licat

ion

Awar

enes

s, to

appe

ar in

the

Proc

eedi

ngs

of t

he IA

STED

Inte

rnat

iona

l Con

fere

nce

on S

oftw

are

Engi

neer

ing

and

Appl

icat

ions

(Cam

brid

ge,

MA)

, Nov

embe

r 20

02, t

o ap

pear

.•

Colli

ns, P

., Sh

ukla

, S.,

Redm

iles,

D. A

ctiv

ity

Theo

ry a

nd S

yste

m D

esig

n: A

Vie

w fr

om th

e Tr

ench

es, C

ompu

ter-

supp

orte

dCo

oper

ativ

e W

ork,

Spe

cial

Issu

e on

Act

ivit

y Th

eory

and

the

Prac

tice

of D

esig

n, 2

002,

pp.

??-

??.

•Y.

Eng

estr

öm. W

hen

is a

Too

l? M

ulti

ple

Mea

ning

s of A

rtifa

cts i

n Hu

man

Act

ivit

y, C

hapt

er 8

of L

earn

ing,

Wor

king

and

Imag

inin

g, P

aine

ttu

Kirj

apai

no O

ma

Ky:

ssä,

Jyv

äsky

läss

ä, 1

990,

pp.

171

-195

.•

Redm

iles,

D. I

ntro

duct

ion

to th

e Sp

ecia

l Iss

ue o

f CSC

W o

n Ac

tivi

ty T

heor

y an

d th

e Pr

acti

ce o

f Des

ign,

Com

pute

r-su

ppor

ted

Coop

erat

ive

Wor

k, S

peci

al Is

sue

on A

ctiv

ity

Theo

ry a

nd th

e Pr

acti

ce o

f Des

ign,

acc

epte

d an

d to

app

ear,

200

2.•

Redm

iles,

D. S

uppo

rtin

g th

e En

d Us

ers’

Vie

ws,

The

Adv

ance

d Vi

sual

Inte

rfac

es In

tern

atio

nal W

orki

ng C

onfe

renc

e (A

VI 2

002,

Tren

to, I

taly

), M

ay 2

2-24

, 200

2, in

pre

ss.

UCI -

Red

mile

s

Extr

a Sl

ides

UCI -

Red

mile

s

Ethn

ogra

phy

+ SE

:Ac

tivi

ty T

heor

y

SUB

JEC

T

RU

LE

SC

OM

MU

NIT

Y

DIV

ISIO

NO

F L

AB

OR

OB

JEC

T

ME

DIA

TIN

G A

RT

IFA

CT

S

OU

TC

OM

E

•Su

bjec

ts a

re p

eopl

e w

ithi

n a

com

mun

ity

that

wor

k w

ith

obje

cts

to o

btai

n an

out

com

e.

•Ru

les

dete

rmin

e th

e be

havi

orof

sub

ject

s an

d th

eir

inte

ract

ion

wit

h ob

ject

s.

•Di

visi

on o

f lab

or d

eter

min

esw

ho p

erfo

rms

wha

t act

ions

.

•M

edia

ting

art

ifact

s he

lpsu

bjec

ts m

anip

ulat

e ob

ject

san

d ob

tain

out

com

es.

•M

edia

ting

art

ifact

s ha

ve a

hist

ory

wit

h re

spec

t to

aco

mm

unit

y.

Eng

estr

öm A

ctiv

ity S

yste

m M

odel

Part 2: Follow-up Materials

Citations for Follow-Up Materials

de Souza, C.R.B., Penix, J., Sierhuis, M., Redmiles, D. Analysis of Work Practices of a Collaborative Software Development Team, International Symposium on Empirical software Engineering (ISESP 2002, Nara, Japan), V. II, October 2002. Kantor, M., Redmiles, D. CASSIUS: Designing Dynamic Subscription and Awareness Services, Workshop on Ad hoc Communications and Collaboration in Ubiquitous Computing Environments, ACM Conference on Computer Supported Cooperative Work (CSCW 2002— New Orleans, LA), November 2002, available at http://www.cs.uoregon.edu/research/wearables/cscw2002ws/papers/Kantor.pdf. Silva Filho, R.S., Slabyak, M., Redmiles, D.F. A Web-based Infrastructure for Group Awareness based on Events, Workshop on Network Services for Groupware, ACM Conference on Computer Supported Cooperative Work (CSCW 2002—New Orleans, LA), November 2002, available at http://awareness.ics.uci.edu/~rsilvafi/papers/Workshops/CSCW2002-workshop.pdf. de Souza, C.R.B., Redmiles, D.F., Mark, G., Penix, J., Sierhuis, M. Management of Interdependencies in Collaborative Software Development, ACM-IEEE International Symposium on Empirical Software Engineering (ISESE 2003), September 2003. de Souza, C.R.B., Redmiles, D.F., Opportunities for Extending Activity Theory for Studying Collaborative Software Development, Workshop on Applying Activity Theory to CSCW Research and Practice, in conjunction with the 8th European Conference of Computer-Supported Cooperative Work (ECSCW 2003—Helsinki, Finland), September 2003, available at http://www.uku.fi/atkk/actad/ecscw2003-at/desouza+redmiles.pdf. de Souza, C.R.B., Redmiles, D.F., ‘Breaking the Code’, Private and Public Work in Collaborative Software Development, Supplement Proceedings of the 8th European Conference of Computer-Supported Cooperative Work (ECSCW 2003—Helsinki, Finland), September 2003. de Souza, C.R.B., Redmiles, D., Dourish, P., ‘Breaking the Code’, Private and Public Work in Collaborative Software Development, International Conference on Supporting Group Work (Group 2003—Sanibel Island, FL), November 2003.

Analysis of Work Practices of a Collaborative Software Development Team

Cleidson R. B. de Souza1,3 John Penix2 Marteen Sierhuis3 David Redmiles1

1Department of Information and Computer Science

2Computacional Sciences Division

3Research Institute for Advanced Computer Science

University of California, Irvine Irvine, CA, USA

NASA Ames Research Center Moffett Field, CA, USA

NASA Ames Research CenterMoffett Field, CA, USA

Abstract

This paper reports preliminary results of a field study of a software development team. This team develops a suite of tools called CTAS, designed to help air traffic controllers manage complex air traffic flows at large airports. We observed that CTAS developers employ two main tools for coordinating their work: a configuration management system and a bug tracking system. These tools allow them to coordinate their activities supporting a high level of parallel development. Communication and cooperation among developers with different roles is achieved using product requests. Future results from our study will pro-vide insights into the complexities of cooperative software development and help to design tools to support it. Keywords: Field Study, Empirical Studies, CSCW, Coop-erative Work, Cooperative Software Development.

1. Introduction✝ Software development is a typical cooperative activity

where experts from different domains are necessary. In-deed, developers of large systems spend about 70% of their time working with others[10]. At NASA, this prob-lem is much more difficult because of the increasing com-plexity of the software being developed. In fact, several efforts to improve the software engineering practices through the dissemination of best practices and infusion of new technologies are taking place at NASA. However, these efforts will only be effective if they address the real ways that people work together to develop software.

Gerson and Star[1] observe that no matter how formal and well-defined a process may seem, there is always a set of informal practices by which individuals and groups monitor and maintain the process, keep it on track, recog-nize opportunities for action and the necessity for inter-vention or deviation. In order to understand these prac-tices, the first author conducted an eight-week qualitative study of a software development team using non-

✝ The authors would like to thank the CTAS group for their help during the fieldwork and the NASA Research Grant NAG2-1555 for the financial support. The first author would also like to thank CAPES (grant BEX 1312/99-5) for the financial support. He is also a faculty at the Department of Informatics, Federal University of Pará, Belém, Pará, Brazil.

participant observation and informal interviews for data collection. This paper reports our initial findings.

2. The Setting

The group observed develops an application called CTAS (Center TRACON Automation System). CTAS is a suite of advisory tools designed to help air traffic control-lers manage the complex air traffic flow at large airports. The source code is developed in C and C++ and is about 1,000 K lines long. The development team is divided in two groups: developers and the verification and validation (V&V) staff. Developers are responsible for writing new code, for performing bug fixing and enhancements, and so on. There are 25 developers, including researchers that write their own code. The V&V staff is responsible for testing the software and reporting, keeping a running ver-sion for demonstration purposes and maintaining user manuals. This group is composed of six engineers.

3. The Methods

The first author spent eight weeks at the field site. We adopted non-participant observation[3] and informal in-terviews[5]. In addition to field notes generated by the observations and interviews, we collected software devel-opment tool manuals, ISO 9000 procedures, product re-quests for software changes (PR’s), and e-mails ex-changed regarding the data and documents.

Initial data collection was centered on understanding the daily work of the developers. During this stage, it be-came clear that the configuration management (CM) and the bug tracking tools combined with e-mail communica-tion were central to the coordination of activities. These results are not surprising based on previous studies by Grinter[2]. Therefore, later data collection was focused on understanding exactly how developers use these tools to perform their work. The interviews focused on observing and understanding the usage patterns of these tools.

4. Initial Findings

An important aspect in fieldwork is the interplay be-tween data collection and analysis: data collection is di-rected by on-going analysis of the data[9]. Our initial re-

sults of this analysis are described in this section. Further analysis is still necessary to obtain more reliable results. 4.1 Parallel Development

We noted that software developers often engage in par-allel development. This confirms the results from Perry et al.[6], but contrasts with the groups studied by Grinter[2], where developers avoided this situation. Parallel develop-ment usually happens when more than one developer has to make changes in the same file. Conflicts might occur when one of these developers check the file back in the repository, because the current version of other developer will be outdated and his modifications might be based on the code that was modified. To update his version, one only needs to merge the other changes back in his code. According to the developers, these conflicts are infrequent and not likely to occur. We plan to use log of the tool us-age to test this assumption.

In order to avoid these conflicts, the group adopted the convention that before checking one file in, a developer must send an e-mail to their mailing list describing the files that were changed and the product request associated with the changes. Developers even go to their co-worker’s office to talk about the changes that they made or browse the CM repository in order to understand these changes.

Another strategy used by the developers is the partial check-in, i.e., to check files in, even when their work is not completely finished. This strategy is employed by those who work with files that are constantly changed by several developers, which makes conflicts more likely. This helps them to prevent those conflicts and avoid sev-eral back merges to update their code.

4.2 Conventions

The team studied adopts several conventions in order to cooperate effectively. Conventions are rules or arrange-ments established in the group, common and accessible to its members[4]. Examples of such conventions are the e-mail that has to be sent before the check-in, or the naming conventions that must be followed when dealing with the CM and bug tracking tools. However, these conventions are not properly supported by their tools which is a source of complaints by the developers. For example, the creation of branches in the CM tool must be based on the PR num-ber recorded in the bug tracking tool. This creation is a cumbersome process that could be easily automated since this is a standard procedure.

4.3 Product Requests (PR’s) as Boundary Objects

During the fieldwork, we also identified that PR’s are used as boundary objects by members of the team with different roles. Boundary objects are objects both plastic enough to adapt to local needs and the constraints of the several parties employing them, yet robust enough to

maintain a common identity across sites[8]. In this group, PR’s are used by end-users liaisons, developers and testers serving for different functions. For example, when a bug is identified, it is associated with a specific PR. Whoever identified the problem is also responsible for describing ‘how to repeat’ it. The developer assigned to repair the bug uses this description to identify and fix it. After that, he must fill a field in the PR that describes how the testing should be performed to properly validate the fix. This in-formation is expanded by the test manager to create the test matrices that are later used by the testers. Another field conveys what needs to be checked by the manager when closing the PR. Therefore, it is a reminder of the aspects that need to be validated.

5. Conclusions and Future Work

Data analysis will be performed using grounded the-ory[9] and analytical tools like boundary objects and social networks. We also plan to use the Brahms work practice modeling and simulation method[7], in order to simulate the impact of inserting collaborative tools into the devel-opment activity. We are particularly interested in under-standing the consequences of the parallel development identified in this group: reasons why these developers en-gage in parallel development might be social, organiza-tional, technological or combinations there of. It is impor-tant to identify and understand these reasons so that this practice might be improved, made more effective or safely adopted by other development groups. Initial results indi-cate that the branching strategy employed in the CM tool properly supports such development, but this is still an open question. We collected log usage data and plan to apply statistical techniques to validate this hypothesis.

6. References [1] Gerson, E. M. and Star, S. L. Analyzing Due Process in the Workplace.

ACM Trans. on Office Information Systems, 1986. 4(3): p. 257-270. [2] Grinter, R., Supporting Articulation Work Using Configuration Man-

agement Systems. Journal of Computer Supported Cooperative Work, 1996. 5(4): p. 447-465.

[3] Jorgensen, D. L., Participant Observation: A Methodology for Human Studies. 1989, Thousand Oaks: SAGE Publications.

[4] Mark, G., et al. Supporting Groupware Conventions through Contex-tual Awareness. in (ECSCW '97). 1997, p. 253-268.

[5] McCracken, G., The Long Interview. 1988: SAGE Publications. [6] Perry, D. E., Siy, H. and Votta, L. G. Parallel Changes in Large Scale

Software Development: An Observational Case Study. in ICSE 1998. [7] Sierhuis, M., Modeling and Simulating Work Practices. BRAHMS: a

multiagent modeling and simulation language for work system analy-sis and desing. 2001: Ponsen & Looijen BV.

[8] Star, S. L. and Griesemer, J. R. Institutional Ecology, Translations and Boundary Objects: Amateurs and Professionals in Berkeley's Museum of Vertebrate Zoology. Social Studies of Science, 1989. 19.

[9] Strauss, A. and J. Corbin, Basics of Qualitative Research: Techniques and Procedures for Developing Grounded Theory. Second. ed. 1998, Thousand Oaks: SAGE Publications.

[10] Vessey, I. and A. P. Sravanapudi, CASE Tools as Collaborative Sup-port Technologies. CACM, 1995. 38(1): pp. 83-95.

CASSIUS: Designing Dynamic Subscription andAwareness Services

Michael KantorInstitute for Software ResearchUniversity of California, Irvine

Irvine, CA 92612 USAmkantor@ics.uci.edu

David RedmilesInstitute for Software ResearchUniversity of California, Irvine

Irvine, CA 92612 USAredmiles@ics.uci.edu

ABSTRACTCASSIUS is an awareness server which assists users indesigning subscriptions for maintaining awareness ofevents within work, physical and social environments.This environment is designed to work with a wide range ofawareness tools using desktop computers, mobile devicesand ambient fixtures[4]. This work investigates therequirements for creating ad-hoc subscriptions – asubscription that is created either by the user or a softwareagent, and which only exists for a brief period of time.Design guidelines are proposed that help address theproblem inherent in having users invest effort in creating asubscription which may last for only the few minutes inwhich they are in a specific location or context.

KeywordsAwareness tools, Notification servers, agents, CASSIUS,ad-hoc networks

INTRODUCTIONThe "Creating Awareness with Subscription Services"(CASS) strategy is an approach for creating a ubiquitousawareness environment [5]. The goal is to enhance people'sability to coordinate with various actors within work,physical and social environments by providing a usable anduseful environment for awareness and coordination. TheCASS strategy consists of a set of guidelines for the designof software based awareness environments.

This paper begins by presenting an overview of theseguidelines and presents our implementation of thisubiquitous awareness. We then discuss potentialextensions to the guidelines and implementation whichaddress the issues of designing an awareness environmentthat is usable for the ad-hoc creation of subscriptions formonitoring contextual information.

CASS GuidelinesThe CASS strategy consists of a set of guidelines forcreating a usable and useful awareness environment. Theseguidelines can be divided into three categories: provideaccess to diverse information, remove guesswork from

specifying the information of interest and supportflexibility in the choice of awareness styles for representingawareness information.

Provide Access to Diverse InformationResearch in awareness technologies has focused upon toolsdesigned to monitor a single source (or a narrowly definedset of sources) of awareness information. This has been thecase because the projects were either experimental,investigating a style of presenting awareness informationwith some demonstration source of awareness informationor because they were implemented within a context wherethere was only one information source that the designer wasinterested in.

In a ubiquitous awareness environment, an awareness toolhas access to diverse sources of awareness informationallowing each user to monitor the kinds of information thatmatter to them. This was done by the Elvin Tickertape [3]which could monitor discussion groups, news, email, andother notifications sent to the notification server. Tosupport awareness and coordination in diverseenvironments, we can not limit ourselves to monitoring asingle source of information. An awareness tool needs tobe able to obtain information from multiple sources ofawareness information, and integrate them together to giveusers a broader understanding of what is happening withintheir work, social or physical environments. Nor can welimit users by telling them that the only information thatthey can become aware of is news, photos of offices [1], orany other single source.

Remove Guesswork from Specifying Information of InterestHaving access to diverse sources of awareness informationwould be insufficient if the user does not know whatsources of information are available. To provide a usableawareness environment, the user needs to be informed(preferably by the awareness tools rather than by coworkers)of what sources of awareness information are available,what each source monitors, and what kinds of changes andevents can be detected. The awareness environment mustprovide users with meta information describing theawareness information accessible to the environment.

For example, if a source of information is a research paper,the sections and subsections could be monitored forchanges, as could word or page counts. As a secondexample, if users monitor for traffic problems, they need to

LEAVE BLANK THE LAST 2.5 cm (1”) OF THE LEFTCOLUMN ON THE FIRST PAGE FOR THE

COPYRIGHT NOTICE.

know what freeways and roads are monitored and whatkinds of traffic events are reported so that they can choosewhich ones to monitor.

Without this meta information, any attempt by the user todescribe their interests involves a great deal of guesswork,leading at best to partial success, and more likely tofrustration. Access to this type of information is aprerequisite for a usable ubiquitous awareness environment.

Support Choice of Awareness StylesA common problem with awareness technologies is thatthey tend to provide a fixed awareness style with very littleroom for selection of alternatives. In this work, the termawareness style refers to the manner in which informationis presented to users and varies along a variety ofdimensions including:

1 . Intrusive vs. peripheral dimension: howintrusive/disruptive is the presentation of newawareness information? If the goal is to beimmediately notified of information as it occurs, anintrusive style is needed. If the goal is to maintaingeneral awareness of ones environment, utilization ofperipheral senses may be more appropriate.

2. Mobility dimension: Can the awareness tool be usedas a person's work moves through different physicaland social contexts? Can it use mobile devices, ordoes it require greater display, networking orcomputational resources? Does its presentation stylerequire the kind of user attention only availablewithin an office or control room?

3. Information Representation dimension: What kindsof information does the representation of theinformation focus upon?

4 . Cognitive Effort dimension: How much effort isneeded to interpret the representation?

To provide an awareness environment that is useful, peopleneed to not only be able to choose what information tomonitor, they need to be able to choose how to be madeaware of the information. Ideally, they would havehundreds of different awareness tools to choose from, andcould choose the one which best fits their workenvironment, work practices and their needs with respect tosome subset of the information they intend to monitor.

Further, the user should not be limited to one awarenesstool at a time, nor one awareness tool for any source ofawareness information. As a user leaves an office settingfor a meeting, lunch or other situations, the style ofawareness that suits this new environment may change andthe user needs to have the option of changing awarenesstools to match the new environment. When the user is inthe office, there may be many sources of information, onesubset of which is monitored with an intrusive tool, and asecond subset of which is monitored with a peripheralawareness tool.

CASSIUSOur implementation of the CASS strategy is calledCASSIUS (CASS Information Update Server). It is anotification server [7] which has been optimized forusability as an awareness server. Figure 1 shows a service-based architecture that CASSIUS implements, and Figure 2shows an awareness source browser and subscription editorprovided with our CASSandra toolkit.

As shown in the top two services of Figure 1, sources ofawareness information must register with the server, listingthe objects that they monitor and describing the types ofevents that can affect those objects. The awareness tool canthen support users browsing through lists of sources ofawareness information (shown in the top left column ofFigure 2). For each information source, the user can browsethrough hierarchies of objects and properties monitored bythat information source (top center column of Figure 2).When the user selects an object to monitor, lists of eventsthat can affect the object are listed, allowing the user tooptionally refine their subscription to just those types ofevents (top right column of Figure 2). A single awarenesstool can monitor as many subscriptions and informationsources as suits the user’s needs and the tool’s awarenessstyle.

Representation of Arbitrary InformationA key issue in our design involves the representation ofawareness information from any information source. If thedesigner of the awareness tool does not know in advancewhat the source of awareness information is, how can thetool represent that information? The answer is that allnotifications, regardless of what software sent them, mustbe formatted using data fields that have a fixedinterpretation shared by all CASSIUS awareness tools andinformation sources. The awareness tool need notunderstand the meaning of the data sent in a notification,but does need to understand its nature, that one fieldcontains verbal/textual descriptions of the event, anotherfield quantifies the extent of change, etc… Our designattempts to account for the information needs of a broadrange of awareness styles by using the notification fields ofTable 1.

Sample ApplicationsWe currently have a WebDAV server (CassDAV), and anAWACS simulator which send notifications to CASSIUS,

Figure 1: CASSIUS service architecture

and we are working on a CVS repository and a Portholesimplementation [1]. In the case of WebDAV and CVSrepositories, the monitored objects are files and folders,which are described to the server so that the user, using aninterface such as that presented in Figure 2, can browsethrough a representation of the file system to find andselect files and folders to monitor. Notifications report onthe nature and extent of the changes or operationsperformed upon the files and folders.

In the case of Portholes, which creates awareness bydistributing photos of people at work in their offices, themonitored objects are groups and individuals, thenotifications indicate the extent of changes betweensuccessive photos, and contain a URL to the photo.

To monitor these and future sources of awarenessinformation we have a growing body of awareness toolsincluding simpleScroller (a tickertape such as wasillustrated by Elvin [3]), EventLister (a debugging tool tohelp developers see the notifications that their code sends)and BiffArray (Figure 3). We are also working on an email-based tool for sending digests of events, and are planningto adapt our mobile awareness technology calledMiniPortholes.

BiffArrayBiffArray (Figure 3) is modeled on Xbiff, a common mailawareness indicator in unix windowing environments. Itprovides a row of Biffs, where the graphics within the iconshow the most recent event to come from the objects beingmonitored. Rather than a mailbox with flag up or downgraphic (as was done in XBiff), it shows the GenericEvent

field (see Table 1) of the most recent notification to bereceived. As there are five values of Generic Event, there are5 images used to represent the different states. Each biffin the display can be configured both in what it monitorsand in what sounds it uses to notify the user [2].

Each biff can monitor a different source of information. Forexample, if you have six biffs, two could monitor files andfolders that you work with, two could monitor coworkers,one could monitor activity on a chat group, and the lastcould monitor the state of your group's printer.

Figure 3: BiffArray: Visual and Audio Icons

Mobile AwarenessMiniPortholes (Figure 4) is a mobile awareness technologyimplemented in J2ME. It allows users to subscribe tomaintain awareness of individuals such as coworkers andfamily. When this tool uses the CASSIUS server, itenables users to not only subscribe to monitor otherMiniPortholes users but also monitor all types ofCASSIUS information sources. This means that systemadministrators can monitor their servers, salesmen canmonitor their inventory, parents can monitor their children,and in fact, a parent who is a system administrator and

Figure 2: CASSandra information source browser and subscription editor

salesman can monitor all three simultaneously – hopefullynot while driving.

While currently using a simplified version of CASSIUS,we hope to integrate MiniPortholes with CASSIUS soon.

AD HOC AWARENESS INFORMATIONThe high level goals of this work (the creation of aubiquitous awareness environment) are important whetherone is talking about work (awareness and coordinationamong coworkers, often distributed both spatially andorganizationally), family (awareness and coordination withfamily members scattered around a city) or a physicalenvironment (awareness of problems such as upcomingtraffic, weather, riots, parades, statistics related to asporting event you attend and special deals at your favoritecoffee shop just down the street). Effective support ofthese diverse environments requires:

1) Creation of ad-hoc subscriptions, whose life span maybe as little as 10 minutes (and where the time tospecify the subscription must be comparably short).

2) Location based awareness servers that awareness toolsconnect to on-the-fly to discover new sources ofawareness information.

The principal of what must be done remains unchanged: 1)the users must be provided with meta information tellingthem what information sources are available and what typesof information can be subscribed to within eachinformation source, and 2) users choose awareness stylesfor each type of information. However, in this new

environment, extensions are needed in how these servicesare provided.

Extension 1: Detecting and Logging InformationSourcesIn our current implementation, users can view lists ofinformation sources on the servers that they havepermission to access. If we introduce location-basedawareness servers (perhaps for sending traffic awareness topeople on freeways) and time-based awareness servers (aserver which only exists for a short peiod of time, such asfor the duration of a county fair, or a festival), the nature ofthese lists must change. To effectively provide users withlists of information sources that they can monitor, mobileawareness tools need to be able to

1. Detect the presence of awareness servers as they comeinto range,

2. Obtain lists of information sources from these serversthat users can browse through,

3. Store the lists of information sources and informationabout the awareness servers (such as that it wasrunning on a traffic monitoring server, or on somestranger’s PDA),

4 . Categorize the stored information according to thenature of the awareness server (group all trafficawareness servers together, group all PDAs runningtheir own servers together), and by the informationsource (all information sources that monitor a calendarget grouped together, regardless of what awarenessserver it came from).

Extension 2: Usability in Ad Hoc SubscriptionsA key issue in supporting ad hoc subscriptions is theefficiency with which the subscription can be created. Howmuch examination of the display and selection of optionsmust be done to allow the user to monitor traffic for thenext 15 minutes? To address these problems, additional

Figure 4: MiniPortholes, mobile awareness

Table 1: CASSIUS Notifications

Summary One line textual summary of the change

GenericEvent An event name chosen from a list ofgeneric event names. Generic event namesare shared by all information sources andenable awareness tools to understand thegeneral nature of the event even if theycan’t interpret the specific nature of theevent represented by the Event field.C u r r e n t l y s u p p o r t s “Activate”,“Deactivate”, “Increase”, “Decrease” and“Change” (the last being a catch-all forevents not fitting other categories).

Event An event name specific to the informationsource and to a type of object within theinformation source. Events reporting on asection of a document might include “TextAdded”, “Text Removed”, “SubsectionAdded”, and “Subsection Removed”.

URL Optional link to more information about anotification. Leads users to text, images orinformation source specific data files.

Person Optional person associated with event.

Place Optional place associated with event.

Object Identifies the object or property that haschanged.

AccountPath Identifies the information source.

NumericalValue Optional numerical value to quantify thechange.

guidelines have been created for the design of informationsources and awareness tools.

Support a Spectrum of ComplexityLocation and time based awareness servers should providesimple options for subscribing. While it should bepossible to carefully refine long term subscriptions so thatthe awareness tool doesn’t waste time presenting unwantedinformation, support is also needed for the fast and lessprecise task of creating short-term subscriptions.

For example, a person at a county fair can subscribe to thefair’s scheduled events and be notified each time a newevent is about to begin. Or the person can be more carefuland look at the objects under “Scheduled Events” in theobject hierarchy and subscribe to only be notified whenmusical events are about to start. Both subscriptions areuseful. One requires more time and thought – time whichpeople spending all day at the fair are more likely to investthan people attending for only part of the day.

This scaling is supported in CASSIUS in the form ofnotifications that can be propagated up the object hierarchy:a notification of changes to a file in a CassDAV server willresult in notifications being sent to users monitoring thefile (users who have carefully refined their subscription),and will also propagate the notification up to usersmonitoring any of the containing folders.

One new design principal for information sources istherefore to design the hierarchy of monitored objects toexplicitly support both users who have time to carefullyrefine subscriptions by browsing deeply through objecthierarchies, and to have high level, rapidly accessibleobjects for use in creating ad hoc subscriptions.

Consistency Across Related Information SourcesSubscriptions need to be generalizable across relatedinformation sources. For example, if a user subscribes tobe notified of traffic problems while on one segment of ahighway, there is a strong likelihood that when moving toa different segment of the freeway, the user will want tosubscribe to the same or similar categories of information.

Support for this would require consistency acrossinformation sources that monitor the same types ofinformation. For example, each traffic information sourcewould have the same high level objects in its hierarchy,and only when you work your way down to monitoringcertain on/off ramps do the object hierarchies of thedifferent sources begin to look different.

Implementations of this (under the current CASSIUSarchitecture) would leave it to the awareness tool to

1) Note that two information sources are similar,

2) Determine that the user has subscribed to a certain setof information in the first information source,

3 ) Either automatically subscribe the user to similarinformation in the new information source, recommendit to the user, or make the information very easy tofind and subscribe to [6].

An alternate approach would utilize the categorization andlogging of awareness servers and information sources

discussed in the prior section. It would allow users to lookat a variety of related information sources and design asubscription that specifies what to do if informationsources of that type are encountered in the future.

CONCLUSIONWe have designed a set of guidelines for creatingubiquitous awareness environments, and provided animplementation of this environment. However, withoutstrict guidelines in the design of information sources andawareness tool that work within this environment, theenvironment will only be usable for static subscriptions;subscriptions to information sources that will be a part ofthe user’s life for an extended period of time. To make thisenvironment usable for the creation of ad hoc subscriptions,information sources need to have both high level objectsfor rapid subscription and low level objects for refinedsubscription, sources of a common type need to utilizecommon object hierarchies, and the awareness tools needto be able to log, organize and recommend subscriptionsbased on information retrieved from the awareness serversthat it encounters.

ACKNOWLEDGMENTSThis effort was sponsored by the National Aeronautics andSpace Administration (NASA) Research Grant NAG2-1555. The U.S. government is authorized to reproduce anddistribute reprints for governmental purposesnotwithstanding any copyright annotation thereon. Theviews and conclusions contained herein are those of theauthors and should not be interpreted as necessarilyrepresenting the official policies or endorsements, eitherexpressed or implied, of NASA.

REFERENCES1. Dourish, P., Bly, S. (1992) Portholes: Supporting

Awareness in a Distributed Work Group In CHI'92ACM, pp. 541-547.

2. Gaver, W. W., R. B. Smith, and T. O'Shea (1991)Effective Sounds in Complex Systems: The ARKolaSimulation In CHI'91, New Orleans.

3. Fitzpatrick, G., Mansfield, T., Arnold, D., Phelps, T.,Segall B., Kaplan, S. (1999) Instrumenting andAugmenting the Workaday World with a GenericNotification Service called Elvin In ECSCW'99Copenhagen.

4. Ishii, H., Wisneski, C., Brave, S., Dahley, A., Gorbet,M., Ullmer, B., Yarin, P. (1998) ambientROOM:integrating ambient media with architectural space InCHI’98 ACM, Los Angeles, pp. 173 - 174.

5. Kantor, M., Redmiles, D. Creating an Infrastructure forUbiquitous Awareness, Eight IFIP TC 13 Conferenceon Human-Computer Interaction (INTERACT2001Tokyo, Japan), July 2001, pp. 431-438.

6 . Maes, P. (1994) Agents that Reduce Work andInformation Overload in CACM, 37, 31-41.

7 . Ramduny, D., Dix, A. and Rodden, T. (1998)Exploring the design space for notification servers InCSCW'98 ACM, Seattle, pp. 227-235.

A Web-based Infrastructure for Awareness based on Events

Roberto S. Silva Filho, Max Slabyak, David F. Redmiles Information and Computer Science, University of California, Irvine

Irvine, CA 92697-3430 USA +1 949 824 4121

{rsilvafi, mslabyak, redmiles}@ics.uci.edu

ABSTRACT The ability to be aware of other people’s work in a collabo-rative environment is essential to improving the coordina-tion of the members of a group. In this context, events originating from many sources have to be filtered and combined in order to provide the right information to the right person at the right time. As the Web becomes a popu-lar and ubiquitous way to integrate different information sources, an infrastructure that allows the filtering, combi-nation, abstraction and routing of awareness information is required. In this paper, we describe DEAL (Distributed Event Awareness Language), an event-based infrastructure and language that supports the development of awareness applications in the context of distributed collaborative en-vironments. The requirements of the infrastructure are discussed as well as the language syntax. Our motivation was to design a language and a set of usable and useful strategies and web services that provide usable and useful awareness capabilities for the development of awareness applications.

Keywords Event Notification, Distributed Awareness, Event Process-ing Languages, CSCW, Web Services.

INTRODUCTION In a broader sense, awareness refers to people’s ability to sense relevant changes in their environment. In the spe-cific context of CSCW, awareness is usually related to the perception of the direct or indirect changes in the compu-tational and social environments originated by other peo-ple in the group. These changes are usually communicated through different computational resources, devices and applications. Awareness is an essential element in distrib-uted collaborative environments. Individuals and groups of people need to be aware of what other members of the group are doing, in special, the activities of these other

members that directly or indirectly affect each individual’s work. For example, a manager needs to be aware of the progress of the tasks assigned to her subordinates, the presence of other members of the group in the workplace in order to see a demo, the arrival of a co-worker in a re-mote site, in order to start a chat session and so on. These activities can be modeled as events, atomic asynchronous messages that represent changes in the computational and social contexts.

The CSCW literature describes many ways to provide awareness in a collaborative and potentially distributed work environment [15]. Some examples include periodic pictures of a co-worker’s office as provided by NYNEX Portholes [16], notifications about changes in shared arti-facts, provided by the BSCW system [17], application monitoring gauges as described in [5] and so on. In order to integrate and combine the information coming from those different sources, allowing the processing, routing and filtering of such information, an event processing in-frastructure is usually adopted [3].

Today’s Web Services infrastructure focuses on providing a common set of protocols for the development of web ap-plications, defining a web-based middleware for the devel-opment and integration of distributed web services [19]. In this infrastructure, the SOAP protocol is used as a remote procedure call mechanism for services communication; the UDDI implements a service location mechanism and the WSDL allows the description of the interfaces of the web services. This infrastructure alone, however, does not pro-vide all the functionality necessary for the implementation of more sophisticated web applications [11]. In this con-text, event-processing services supplement this basic infra-structure providing the ability to integrate, process, select and route events originated from different nodes in the Web. In an event notification service, producers and con-sumers of information are separated by an event middle-ware that integrates these two parties, allowing different consumers to subscribe to information coming from many event producers. This event routing layer decouples event producers from their consumers, allowing the dynamic addition and removal of these components in the system.

LEAVE BLANK THE LAST 2.5 cm (1”) OF THE LEFT COLUMN ON THE FIRST PAGE FOR THE COPY-

RIGHT NOTICE.

Specifically, previous work analyzes the use of event noti-fication servers in CSCW applications [4].

In this paper, we present DEAL (the Distributed Event Awareness Language), an event-notification infrastructure and language to support the development of distributed awareness applications for the Web. The DEAL environ-ment extends the basic functionality provided by event notification servers such as Khronika [9], CASSIUS [8], CORBA Notification Service [12], ELVIN [6] and SIENA [1] to cope with the richer set of requirements of awareness applications. This is accomplished by the use of a powerful and usable event language that allows the definition, proc-essing, combination, filtering and routing of events com-ing from heterogeneous sources (programs, applications, components, people, mobile devices and so on). The DEAL language syntax and resources were inspired in the features provided by event processing languages such as GEM [10], Yeast [2], EDEM [7] and READY [18]. Us-ability and simplicity with expressiveness were some of the principles considered in the design of the language. In special, the following scenario provides a set of require-ments and motivations that guided the design of the lan-guage and infrastructure.

SCENARIO AND MOTIVATION Consider an IT company with many branches in different cities over the country or even the world. Many people cooperate in different projects at the same time, perform-ing different roles (manager, programmer, tester, designers and so on). Each project usually is carried on by a dynamic group of people whose interaction varies according to the group’s current focus. At the beginning of a project, for example, designers and project managers are more active, whereas more towards the end, the activities concerning programmers, engineers and testers are more prominent. The work can also be split between different branches of the company. One branch, for example, deals with the product support while the other deals with the design and implementation. People join and leave groups as neces-sary. The group work is usually supported by different tools, such as configuration management repositories, word processing, CAD, databases and so on. These tools are used to produce and manage the evolution of the arti-facts being developed, as well as their meta-information (documentation, specifications, metrics and so on). In this scenario, different people need to be aware of other group member’s activities.

An indirect way of being aware of other people or group activities is to gauge the evolution of the artifacts they pro-duce or modify. The kind of information one is interested in depends on her role in the organization. For example, programmers and engineers may want to be notified when some modules in a software project repository are ready for integration or when some change request is issued and consolidated in a defect report database. Managers, on the

other hand, can gauge the activity in certain project by visualizing a graph with the number of changes in the pro-ject repository over the day.

In this dynamic work environment, mobility and heteroge-neity is another concern. Computers are no longer limited to users’ desktops at their workplaces; instead they are increasingly mobile and ubiquitous. Users can interact with a collection of computational devices ranging from non-stop servers, workstations, and motion sensors to portable devices as laptops, mobile phones and PDAs. In this mobile environment, awareness applications have to adjust their intrusiveness and information delivery policies to comply with different contexts (time, place, physical, organizational, administrative roles so on). For example, managers may want to be constantly informed about the progress of their projects using their portable computers. The level of attention required by the user, however, is dependent on her context. For example, one may want to be immediately notified about a meeting when she is in her office. This same information, however, may not be very important when she is at home or on a business trip.

Information persistency is another important issue. A man-ager, coming from a business trip, for example, may want to gauge the progress of a project by analyzing the event history of the preceding week. This requires having a way to store events during a certain period of time so they can be delivered when the user’s computer is on-line again.

Not all events, however, should be stored for further analy-sis. People usually do not want to be notified about transi-tory and ordinary events. For example, the arrival of some-one in her office or the temporary unavailability of a printer, that ran out of paper. This requires a mechanism to discard old events and filter irrelevant information.

Finally, meaningful events are usually a result of or are expressed as a combination of more ordinary events whose occurrence usually obeys some predefined patterns. For example, the turning on of the light of someone’s office followed by the typing of some characters in the computer keyboard may indicate the arrival of this person at her workplace.

REQUIREMENTS FOR AWARENESS APPLICATIONS The previous scenario illustrated many features that our event-notification infrastructure must support such as the integration of heterogeneous event sources, the need to compose events, the ability to filter information, events expiration time and mobile applications support. More-over, the appropriate delivery of an event depends on the user context, timing constraints, roles and priorities. The notion of groups is also required.

Functional Requirements

To cope with these requirements, the DEAL event lan-guage and infrastructure was defined to provide the follow-ing features.

Subscriptions: Logical expressions that provide the ability to select a subset of events based on their content or type. They allow the routing of events to the right person at the right time, with the appropriate priorities based on the user context, group, role and other properties.

Abstraction: A mechanism that combines different events into higher-level notifications in order to provide more meaningful awareness information. Event abstraction can use the following strategies:

• Pattern matching: The ability to subscribe to event sequences and patters. It is the basis for abstraction and reduction. It may detect events in a specific order or out of order.

• Reduction: Translates sets of repetitive events, ex-pressed as a pattern matching expression, into local state variables or higher-level events. This is specially required in monitoring applications, to prevent event flooding. A reduction consists in creating a new event indicating that an event pattern was detected.

• Aggregation: Is a more elaborated case of reduction in which the event generated is a composition of some of the attributes of the events in the detected pattern. Events are combined in a higher-level event which summarizes the content of the events in the pattern expression.

Event Condition Action (ECA) Rules: Special types of subscriptions that allow the execution of external applica-tions or general actions whenever a logical condition is evaluated to true. For example: an action can add or re-move subscriptions or even other rules; generate aggre-gated events, change policies, and invoke external applica-tions in response to an event pattern detection. Rules can be used to evolve the behavior of the application in re-sponse to changes in the user environment.

Time constraints: Express Delivery intervals, time to live, as well as timing and temporal relations. Some events need to be detected within certain time interval in order to have some correlation. Transitory conditions may also be ex-pressed by events with expiration time.

Subscription Priorities: Subscriptions are dependent on global, group and local contexts, allowing the adjustment of the information delivery according to the needs of the information consumers (or users).

Groups: Subscriptions and rules can be associated to groups, which are first class entities in DEAL language. This allows the broadcast of events, the definition of shared policies and contexts.

Hierarchical description of event sources: One of the neglected issues in some event infrastructures is the ability to answer the question “What can I subscribe to?” and “Which events are produced by each source?” The DEAL infrastructure provides the ability to browse through differ-ent event sources and to identify their events by keeping meta-information about which event sources are available and what events they produce.

Quality of Service Requirements Apart from the main language features, the DEAL infra-structure allows the specification of different qualities of service and policies as follows.

Persistence of events and subscriptions: Events and sub-scriptions are persistent by default, allowing the support for mobile applications and pull delivery policy.

Mobility support: Clients are allowed to explicitly indi-cate their intent to move to a new location, allowing the infrastructure to perform the necessary migration opera-tions such as the update event routing tables, the buffering of events or change the current qualities of service. This is performed by the move-in/move-out commands. Apart from these explicit commands, the infrastructure deals gracefully with the sudden disconnection of the event sources consumers.

Event Delivery Policies: During the specification of sub-scriptions and filters, one can specify which delivery policy to adopt, whether pull or push.

Security Policies: Authentication of groups, consumers and producers allow the event-processing infrastructure to prevent unauthenticated clients from receiving unauthor-ized events.

THE EVENT LANGUAGE This section describes the DEAL event language. Exam-ples are presented to illustrate its use and syntax.

Logical Expression Operators: >, <, >=, <=, == as well as starts_with and ends_with.

• MyType:ev1.name starts_with “Ro”

Subscriptions: Defined using the subscribe keyword, and removed by the unsubscribe command. Whenever a sub-scription is evaluated to true, a notification is produced having the list of events used in the subscription expres-sion.

• subscribe mySub SomeType:ev1.name == “Mike” and OtherType:ev2.counter == 2

• unsubscribe mySub

Event Type Definition: Creates an event type, a structure supporting: boolean, string, long, int, as well as other Java basic types

• type Type1 {name: string, age: int, is_present: boolean}

On-the-fly event declaration and instantiation:

• Type1:ev1 = {“john”, 22, true}

ECA Rules: Described by the use of the keyword rule, which uses the do command to define the action to be exe-cuted when the rule is matched.

• rule myRule ev1.name == “check-in” and Local.time > 12pm do run myApplica-tion.exe

In this example, the run is a reserved word that allows the execution of external applications.

rule otherRule ev1.name == “turn-on-light” and ev2.name = “workstation-activated” do { type MyAbstrac = {name: String}; MyAbstrac ev3; ev3.name = ev1.name + ev2.name; notify ev3; }

Rule Activation: Activates and deactivates rules according to the context using the enable or disable commands.

• rule activateRule1 Local.time > tomorrow do enable rule1

• rule deactRules ev1.description = “end of meeting” do disable rule1 rule2 rule3

Temporal Expressions: Express time constrains between events. Time triggers and ranges: at, by, in, within.

• at 10pm - matches after the next occurrence of 10 pm

• by 10pm - matches from now until the next occur-rence of 10 pm

• in 2 hours and 10 minutes – matches after 2 hours and 10 minutes from now

• within 3 hours – matches permanently in a pe-riod between now and 3 hours ahead

Time Period expressions: today, daily, weekly, monthly, yearly:

• at 10 am daily • at monday weekly

Event Validity Check (time to “live”): Is a special attrib-ute, present in all events, which expresses its expiration date and time. The expiration condition can be evaluated using the expired keyword:

• expired ev1 • ev2.expiration < today and

ev3.expiration < tomorrow

Pattern Matching: Performs the matching of a sequence of events (repetition, sequence and optional).

• Enforced order: ev1 then ev2 then ev3 • Optional order: ev1 and ev2 and ev3 • Matching of repetition of events (0 or more and 1 or

more): repeat (ev1 and ev2) 2 times

Groups: The keyword group allows the definition of sets of users, the keywords add and remove perform the addi-tion and removal of users to a group, whereas the operand in checks the pertinence of users in groups.

• group g1 { user1, user2, user3} • add g1 user4 // adds sub4 to group g1 • remove g1 user2 • ungroup g3 // removes the group • user1 in g1

Groups can be used as parameters of the notify command to broadcast events, as in the example

• rule r1 ev1 then ev2 then ev3 do notify ev1 to g1

Roles: A role is a group of users. Groups are used to repre-sent roles. This allows users to perform different roles.

Contexts: Contexts are name spaces that define scopes where some properties, rules and subscriptions are valid. Local and global variables (or properties) can be stored in the local, group or global contexts. In addition, the con-texts provide a set of predefined environment variables that allow the access to information as local time, host-name, user name and so on. The contexts are accessed through the special types Local and Global.

• at 12 pm and Local.mycounter == 12

• at 12 pm and Global.members > 5 Local and global rules can be defined. Expressions can use values of these contexts. A rule is associated to the local context scope using the local modifier. Global rules can be defined using the global modifier.

• local rule myRule at 12 pm and mycounter == 12 do enable rule1

In this example, mycounter is a variable in the Local scope. Each group has a special context associated with it. Group contexts are accessed by the group name, for exam-ple: g1.size expresses the size of the group.

Group rules can be defined using the group modifier fol-lowed by the group name, before the rule declaration.

Attributes can be added or removed from a context using the addcontext and remcontext keywords.

• addcontext Local name:string

Events and Subscription Priorities: Special attributes in the events, which are used by the system to perform event routing. They can be used in subscriptions by accessing the reserved attribute priority.

• rule adjustPriority Local.time > 6 pm do ev1.priority = ev1.priority –1

DESIGN The DEAL architecture is described in Figure 1. The sys-tem is implemented as a wrapper around a notification server infrastructure such as CASSIUS [8] or Siena [1].

The event-processing kernel implements the DEAL func-tionality using the resources provided by the event notifica-tion server. Applications interact with the infrastructure through a programmatic API while end-users can use a command interpreter shell or a more sophisticated GUI. The interaction with the system can be intermediated by Web services interfaces such as SOAP or by lower-level protocols as HTTP/CGI. The architecture of the system can be distributed, using the resources of federated notification servers, according to the features provided by these sys-tems. In special, Siena provides a scalable web-based con-tent-routing infrastructure.

Distributed Event sources (Instrumented softwarecomponents and programs)

Other EventSource

User API or shell

NotificationServer (Siena or

CASSIUS)

Application Application

Consumer SideEDEM agents

Event Producers

Consumer applications

ApplicationEvent Source

User API or shell

Event ProcessingKernel

Event LanguageInterpreter and API

Notifications Subscriptions

Events

Figure 1 Design of the DEAL infrastructure using an event notification server

IMPLEMENTATION DEAL is being implemented using the Java (J2SDK1.4) programming language and the CASSIUS notification server. CASSIUS was chosen for its ability to manage and provide access to a hierarchical list of event sources and their associated events. It also provides a subscription edi-tor GUI that facilitates the interaction with the end users. For using the HTTP/CGI protocol, CASSIUS allows DEAL to be integrated with different event sources dis-tributed over the Web, providing an event-based infra-structure for awareness information.

RELATED WORK In this section, we summarize the main systems that in-spired the DEAL language.

EDEM EDEM (Expectation-Driven Event Monitoring) [7] is a user interface validation and monitoring tool. EDEM uses agents to monitor GUI event patters according to design use expectations. The agent description language is very complete and allows the detection of event patters, the ma-nipulation of local context (in the monitored site), the definition of higher-level events (abstraction), the collec-tion of repetitive events (reduction) and so on.

The EDEM architecture is defined in order to collect us-ability data. Since agents execute together with the appli-cation being monitored, the system was not designed to monitor events coming from multiple distributed applica-tions.

Yeast The Yeast (Yet another Event-Action Specification Tool) [2] is an event-action system used to automate tasks in a UNIX environment. Yeast allows actions to be performed when event patterns and environment changes are de-tected. It allows the association of temporal constraints to events, borrowing its syntax from the at and cron pro-grams of UNIX systems. Sequential and out or order event pattern detection is supported. User-defined actions are executed whenever an event pattern match occurs. These actions can originate new events or start different applica-tions. Yeast allows the definition of rules to be defined, activated or deactivated at runtime. This flexibility is pro-vided by a shell script interface that integrates the UNIX shell commands with yeast pre-defined keywords.

The system is very complete, providing many features that can be used to support the development of awareness ap-plications. It, however, was developed to operate on UNIX environments, being limited at monitoring its specific re-sources and objects such as processes, files and user logs. Users can define their own events but their types are not enforced. There is no advertisement of the event types pro-vided by an event source. Event sources are not primary entities in this model. There is no explicit idea of subscrip-tion and subscriber. The event language does not allow the creation and manipulation of local variables, limiting the support for local and global contexts. User groups are not supported.

Khronika The Khronika [9] is a centralized event notification service created to increase people awareness about their environ-ment. One of the objectives of the system is to bridge the gap between computational and real-world events. Each user of the system can specify sets of pattern-action sub-scriptions that are used to automatically notify the user when an event pattern is detected. Khronika also allows the direct browsing of the events in the repository. Events have expiration time and remain on the server database as specified in their validity (days, hours or brief intervals). The event language allows queries by time interval, event

types and substring matching. Similar to Yeast, there is a mapping between English expressions as "today", "tomor-row", "now", "Thursday afternoon", and so on, to more precise time constraints. Access control lists and user groups are used. These restrictions are made simple for usability purposes.

Khronika does not provide the ability of abstracting and aggregating events. There is no support for different event sources, including mobile devices as well as the ability to activate/deactivate subscriptions (or rules) based on envi-ronment changes. There is no notion of user groups.

Gem GEM [10] is a generalized event language for real-time distributed systems monitoring. It allows the event se-quence detection and the specification of rules that can be activated or deactivated according to other rules. For being designed for real-time monitoring, rules can include spe-cial time constraints concerning incoming events delays. It also allows the use of event order constraints in event ex-pressions, such as the specific order events should occur and the acceptable delay between them. Events can be ab-stracted and generated based on contents of other events. There is support for abstraction.

The GEM language itself was not defined for usability. It does not provide support for context and groups.

READY and CORBA READY (Reliable Available Distributed Yeast) [18] is a general-purpose event notification service based on YEAST. READY adds to YEAST the ability to handle compound event matching, quality of service and other event constructs, in an implementation that extends the Standard CORBA notification server [12].

In its porting to CORBA [13], READY lost the simplicity, elegance and easy-to-use interface of the Yeast model. Its language became more complicated, being based on the OMG Event Notification Language. It also lost the timing constraints neutrality and elegance of Yeast.

CONCLUSIONS DEAL is an event processing language and system de-signed to provide awareness information in a heterogene-ous distributed system. The system was designed to cope with current distributed systems characteristics as mobility, heterogeneity, timing, as well as CSCW aspects as groups, context and priorities. In order to do so, it combines char-acteristics of different event processing, monitoring sys-tems and awareness driven notification servers. It was spe-cially designed as a distributed awareness service that can be integrated in many Web applications. This is accom-plished by the use of the HTTP protocol. The event lan-guage was designed to be useful and usable, providing a high-level way to interact with the system. A prototype is being implemented in Java using CASSIUS as the basic notification service.

ACKNOWLEDGMENTS This effort was sponsored by the Defense Advanced Re-search Projects Agency (DARPA) and Air Force Research Laboratory, Air Force Materiel Command, USAF, under agreement number F30602-00-2-0599; by the National Aeronautics and Space Administration (NASA) under contract NAG2-1555; by the National Science Foundation under grants 0083099 and 0205724. The U.S. government is authorized to reproduce and distribute reprints for gov-ernmental purposes notwithstanding any copyright annota-tion thereon. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorse-ments, either expressed or implied, of DARPA, the Air Force Laboratory, or the U.S. government.

REFERENCES 1. A. Carzaniga, D. S. Rosenblum, and A. L. Wolf. De-

sign and Evaluation of a Wide-Area Event Notification Service. ACM Transactions on Computer Systems, 19(3):332-383, Aug 2001.

2. B. Krishnamurthy and D. S. Rosenblum. Yeast: a gen-eral purpose event-action system. IEEE Transactions on Software Engineering, Vol. 21, No. 10. October 1995.

3. D. C. Luckham. The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise System. Pearson Education. ISBN 0-201-72789-7. Bos-ton MA 2002.

4. D. Ramduny, A. Dix and T. Rodden. Exploring the design space for notification servers. Proc. of the ACM CSCW’98. pp. 227-235. Seattle, 1998

5. De Souza, C.R.B., Basaveswara, S. D., Kantor, M. Redmiles, D.F. Lessons Learned using Event Notifica-tion Servers to Support Awareness. Human Computer Interaction Consortiun’02- Winter Workshop, Jan 31 to Feb 3, Fraser, CO. 2002

6. Fitzpatrick, G., Mansfield, T., et al. Augmenting the Workaday World with Elvin, Proceedings of 6th Euro-pean Conference on Computer Supported Cooperative Work (ECSCW 99), Kluwer, 1999, pp. 431-450.

7. Hilbert, D., Redmiles, D. An Approach to Large-Scale Collection of Application Usage Data Over the Inter-net, Proceedings of the Twentieth International Confer-ence on Software Engineering (ICSE '98, Kyoto, Ja-pan), IEEE Computer Society Press, April 19-25, 1998, pp. 136-145.

8. Kantor, M., Redmiles, D. Creating an Infrastructure for Ubiquitous Awareness, Eight IFIP TC 13 Conference on Human-Computer Interaction (INTERACT 2001 Tokyo, Japan), July 2001, pp. 431-438.

9. L. Lovstrand. Being selectively aware with the Khronika System. Proc of ECSCW'91. 1991.

10. M. Mansouri-Samani and M. Sloman. GEM: A Gener-alised Event Monitoring Language for Distributed Sys-tems. In ICODP/ICDP'97. 1997.

11. M. Stal Web services: beyond component-based com-puting. CACM Special Issue: Developing and integrat-ing enterprise components and services .Vol. 45, Issue 10. pp. 71-76. October 2002

12. Object Management Group. Notification Service Speci-fication v1.0.1. August - 2002. http://cgi.omg.org/docs/formal/02-08-04.pdf

13. OMG Common Object Request Broker Architecture – (CORBA/IIOP) v.3.0. formal/2002-06-33. http://cgi.omg.org/docs/formal/02-06-33.pdf

14. P. C. Bates. Debugging heterogeneous distributed sys-tems using event-based models of behavior. ACM Transactions on Computer Systems. Vol 13. Issue 1. Feb 1995.

15. P. Dourish and V. Bellotti. Awareness and coordination in shared workspaces. ACM Proc. of Conference on CSCW'92. Toronto, Ontario, pp. 107-114. 1992

16. P. Dourish, and S. Bly. Portholes: Supporting aware-ness in a distributed work group, in Proceedings CHI'92, Monterey, CA, ACM/SIGCHI, 1992.

17. R. Bentley, W. Appelt, U. Busbach, E. Hinrichs, D. Kerr, K. Sikkel, J. Trevor and G. Woetzel. Basic Sup-port for Cooperative Work on the World Wide Web. In-ternational Journal of Human Computer Studies 46, pp. 827-846, 1997.

18. R. E. Gruber, B. Krishnamurthy, and E. Panagos. High-level constructs in the READY event notification system. In 8th ACM SIGOPS European Workshop on Support for Composing Distributed Applications, Sin-tra, Portugal, September 1998.

19. Web Services Activity. 2002 http://www.w3.org/2002/ws/

Management of Interdependencies in Collaborative Software Development

Cleidson R. B. de Souza1,2 David Redmiles1 Gloria Mark1 John Penix3 Maarten Sierhuis4

1School of Information and Computer Science,

2Departmento de Informática,

3Computacional Sciences Division,

4Research Institute for Advanced Computer Science,

University of California, Irvine

Irvine, CA, USA

Universidade Federal do Pará Belém, PA, Brasil

NASA/Ames Research Center

Moffett Field, CA, USA

NASA/ Ames Research Center

Moffett Field, CA, USA

Abstract In this paper we report results of an informal field study of a software development team conducted during an eight week internship at the NASA/Ames Research Center. The team develops a suite of tools called MVP, and is composed of 31 co-located software engineers, who de-sign, test, document, and maintain the different MVP tools. We describe the formal and informal approaches used by this group to manage the interdependencies that occur during the software development process. Formal approaches are legitimated by the organization, whereas informal approaches emerge due to the needs of the de-velopers. We also describe how the software development tools used by this team support these approaches and explore where explicit support is needed. Finally, based on our findings, we discuss implications for software en-gineering research.

1. Introduction

Software development is typically a collaborative ac-tivity in which experts from different domains work to-gether to produce a software artifact. Indeed, formal and informal communication account for more than half of developers’ time [21], and cooperative activities account for about 70% of this time [30]. Therefore, breakdowns in communication and coordination efforts constitute one major problem in software development [3].

One of the reasons that cooperative software develop-ment is difficult is the large number of interdependencies that occur. These include interdependencies among activi-ties in the software development process, among different software artifacts, and finally, in different parts of the same artifact. One example involves the design document and the requirements specification—if the specification changes, the design normally needs to be changed as well. Another example involves dependencies among parts of the same artifact, such as program dependencies—syntactic relationships between the statements of a pro-gram that represent aspects of the program’s control flow and data flow [22].

Software engineering has already identified the need to manage these interdependencies and has been developing formal approaches to deal with them. For example, soft-ware development processes describe, among other things, when each artifact should be created during the software development effort. Such processes would pre-scribe that the requirements specification to be created before the design document to minimize problems due to the dependency between these documents. Design tech-niques have also been developed. Examples of such tech-niques include information hiding [19], which tries to minimize dependencies in the implementation by using the concept of coupling, and design patterns [7], which give dynamic (runtime) program dependencies explicit representation as static program structures, making them easier to manage. In addition to formal approaches, soft-ware engineering tools have been built to support the management of interdependencies. An example is con-figuration management systems that deal with dependen-cies in the source code.

Informal approaches are also used to manage the in-terdependencies. These practices exist because no matter how formal and well-defined a process may seem, it will always be incomplete, and also because formal ap-proaches have practical limitations [8]. Informal ap-proaches are as important as formal approaches and need to be understood if one wants to provide support for soft-ware development. Informal approaches solve problems not addressed by formal approaches, so formal and in-formal approaches complement each other. An example of an informal approach is the use of formal communica-tion channels in software development organizations to deal with dependencies among components of the same subsystem when the developers are co-located [9].

In this paper, we describe an informal field study that analyzes both formal and informal approaches used by a software development team to manage the interdependen-cies that occur during software development. We classify this work as an informal study since it consists primarily of observations made by the first author during an eight-week internship during the Summer of 2002. The formal

approaches identified here are those legitimately adopted by the organization, such as the software development process; the software development tools used, namely the configuration management (CM) and bug-tracking tools; and other approaches, such as the division of labor, for-mal meetings, and so on. The informal approaches are the emerging practices adopted by the team to deal with these interdependencies, such as the adoption of conventions; partial check-ins; problem reports (PRs) that cross work boundaries; and the role of e-mail as a coordination mechanism. Our observations build on Grinter’s work [9]; we identify several other informal approaches and analyzed the role of formal approaches in the manage-ment of interdependencies. The identification, analysis, and support for formal and informal approaches are es-sential in improving software development efforts. Inter-dependencies affect the coordination success because they decrease the certainty of a project [13].

2. The MVP Software Development Team

The field study was conducted in cooperation with a team that develops a software application, which for the purposes of this paper we call MVP (All names were changed to preserve anonymity). MVP is a suite of 10 different tools developed at NASA/Ames Research Cen-ter. The MVP source code is approximately one million lines of C and C++.

2.1. Team Organization

The MVP team is divided in two groups: developers and V&V staff. Developers are responsible for writing new code, fixing bugs, adding new features, and so on. This group comprises 25 members, 3 of whom are also researchers who write their own code to explore new ideas. The overall experience of these developers ranges from 3 months to more than 25 years. Experience in the MVP group ranges from 2.5 months to 9 years. This group is spread along several offices across two floors in the same building.

V&V members are responsible for testing and report-ing identified bugs, keeping a running version of the soft-ware for demonstration purposes, and maintaining the documentation (mainly user manuals) of the software. This group comprises 6 members, half located in the V&V Laboratory, and the rest in several offices on the same floor as the laboratory. The V&V Lab and the de-velopers’ offices are located in the same building.

2.2. The MVP Software

Each of the MVP’s 10 tools uses a specific set of “processes.” A process, for the MVP team, is a program that runs with the appropriate run-time options. It is not

formally related to the concept of processes in operating systems and/or distributed systems. MVP’s processes typically run on distributed Sun workstations and com-municate using a TCP/IP socket protocol. Running a MVP tool means running the processes required by this tool with their appropriate run-time options. Processes are used to divide the work among the developers (see sec-tion 4.3).

3. Methods

As an intern with the MVP team, the first author was able to make observations and collect information about several aspects of the team. Additional material was col-lected by reading manuals for the MVP tools, manuals for the software development tools used, formal documents (such as the description of the software development process and the ISO 9001 procedures), training documen-tation for new developers, problem reports, and so on, as well as talking to colleagues. Some of the team mem-bers—the documentation expert, V&V members, testers, process leaders, and process developers—agreed to let the intern shadow them for a few days to better learn about their functions and responsibilities. A representative sub-set of the MVP group was interviewed. Interviews lasted between 45 to 120 minutes. A total of seven interviews [15] were used to find out about the usage patterns of various tools. The data has been analyzed by using grounded theory [28].

4. Formal Approaches

Formal approaches are those legitimately adopted by the team to support the management of interdependencies. They facilitate the software development effort by im-proving the coordination of activities. These approaches have long been studied in the software engineering and organizational research literature (e.g., [6, 26]), so we will mention only aspects of these approaches in the context of the MVP team.

4.1. The Software Development Process

The MVP team uses a formal software development process that prescribes the steps needed to be performed by the developers. For example, the following steps must be performed by all developers after finishing the imple-mentation of a change. Initially, they should integrate their code with the main baseline. After that, must test their changes to check if their integrations have inserted bugs in the code. Finally, after checking-in files into the repository, developers must send e-mails to the software development mailing list describing the problem report (PR) associated with the changes, the files that were

changed, and the branch where the check-in will be per-formed, among other pieces of information.

The MVP software process also prescribes the usage of code reviews before the integration of any change and design reviews for major changes in the software. Code reviews are performed by the manager of each process. Therefore, if a change involves two processes, a devel-oper’s code will be reviewed twice: once by each man-ager. Design reviews are recommended for changes that involve major reorganizations of the source code; their use is decided by the software manager.

4.2. The CM and Bug Tracking Tools

We observed that MVP developers employ mainly two software development tools for coordinating their work: a configuration management (CM) system and a bug-tracking system [2, 9, 11]. These tools are integrated so that there is a link between the PRs (in the bug-tracking system) and the respective changes in the source code (in the CM tool). Both tools are provided by one of the leader vendors in the market. Other tools, such as CASE tools, compilers, linkers, debuggers, and source-code editors, are also used.

A CM tool supports the management of source-code dependencies through its embedded building mechanisms, which indicate what parts of the code need to be recom-piled when one file is modified. In this case, we use Grinter’s classification of dependencies: “Compile-time dependencies occur when a sub-system is being com-piled. Build-time dependencies occur when several sub-systems or the entire system is being linked. Run-time dependencies occur when the executable is running [9].” According to this classification, CM tools support com-pile and build-time dependencies. Similarly, a bug-tracking tool, when associated with the CM tool, supports the tracking of changes performed in the source code dur-ing the development effort.

Two members of the MVP team play important roles in the usage of these tools: the configuration and release manager and the bug-tracking manager. Both help in the administration of the tools and try to relieve the develop-ers of some of most common tasks (e.g., the CM manager created a command interface on top of the CM tool to make it easier for MVP developers to use). The CM man-ager provides full-time support for the CM tool, and the bug-tracking manager is also an MVP software devel-oper. Both managers have been receiving training in those tools, and other developers are trained before starting work in the group. Their training includes the software development tools and the MVP software development process.

The MVP team employs several advanced features of the CM tool, such as triggers, “winking in” techniques to reduce compilation time, labeling, and branching strate-

gies. Indeed, the branching strategy employed is one of the most important aspects of a CM tool because it prin-cipally affects the work of MVP developers. It is a way of deciding when and why to branch. This strategy affects the task of coordinating parallel changes. According to the nomenclature proposed by Walrad and Strom [31], the following branching strategies are used by the MVP team: (1) branch-by-purpose, in which all bug fixes, en-hancements, and other changes in the code are imple-mented on separated branches; (2) branch-by-project, in which branches are created for some of the development projects; and (3) branch-by-release, in which the code branches upon a decision to release a new version of the product. The branch-by-purpose strategy is employed by MVP developers in their daily work, whereas the other strategies are used only by the CM manager. In other words, the developers themselves create new branches for each new bug fix or enhancement, but branches for pro-jects and releases are created only by the manager.

The branch-by-purpose strategy supports a high-level of parallel development by allowing developers to work on different branches at the same time, thus avoiding problems that exist in other strategies [31]. According to this strategy, each developer is responsible for integrating his or her changes into the main code, which is often called “push integration” [1]. The changes are then avail-able to all other developers. Therefore, if one bug is in-troduced, other developers will notice it because their work will be disrupted. Indeed, we observed and collected reports of different instances of this situation. A developer who suspects there is a problem introduced by recent changes will contact the author of the changes to check the change, or to provide more information about it. 4.3. Other Approaches: Meetings and

Division of Labor

MVP developers employ other formal approaches to manage the interdependencies in the software. For exam-ple, the V&V group holds weekly meetings to discuss problems, deadlines, etc. These meetings are also used for official announcements, such as trips, dates of new re-leases, demonstrations, audits, and so on. Likewise, the entire MVP team (developers and V&V staff) holds bi-weekly “software pre-design meetings.” In these meet-ings, formal announcements are also made, but the most important part of the meeting involves the discussion of new PRs. In this case, the developers each announce their new PRs, describing them through their number and headline. In general, the headline provides enough infor-mation about the nature of the PR, but other developers might ask for more details. This is an opportunity for de-velopers to discuss their work, obtain help, and be aware of what is happening in the team. For example, it is not

uncommon after a developer reports a PR that another developer mentions that the problem has already been fixed. PRs that are almost finished might also be an-nounced to warn others about possible “weird” behavior in the tools. Finally, during these meetings the software manager will decide if design reviews are necessary.

The MVP software development team also adopts a clear division of labor based on the processes that com-pose each MVP tool. Each developer is assigned to one or more processes and tends to specialize in it. There are process leaders and process developers, who mostly work only on a particular process. This is important because it allows the developers to understand the behavior of the process more deeply and become familiar with its struc-ture, therefore helping them to deal with the complexity of the code. Indeed, during the software development activity, managers tend to assign work according to these processes. However, it is not unusual to find developers working in different processes under various circum-stances (e.g., before launching a new release, a developer might be assigned to fix bugs in other processes). Devel-opers also work in different processes due to the continu-ity of the work. Sometimes bugs that seem to be located in a process and therefore are allocated to the developer who works with this process are later discovered to be located in another process. In this case, it is better to let the developers finish the work because so much time was invested in it. Thus, this allows developers to gain a com-prehensive view of the whole MVP software.

5. Informal Approaches

Informal approaches are the practices adopted by the MVP team to deal with the interdependencies that occur during the software development process. We call them informal because they emerged naturally in response to the needs of the team and are not taught to new members. The approaches that we identified are discussed below.

5.1. Problem Reports Are Boundary Objects

In our analysis we identified that PRs are used to fa-cilitate the management of interdependencies of develop-ers from different groups and with different roles. In other words, PRs are “boundary objects” in the sense of Star and Griesemer [27]: objects whose common identity is robust enough to support coordination, but whose internal structure, meaning, and consequences emerge from local negotiations between groups. Indeed, PRs are used by end-user liaisons, developers, and testers for different purposes.

Consider the following. When a bug is identified, it is associated with a specific PR. Whoever identified the problem is also responsible for including information about ‘how to repeat it’ in the PR. This description is

used by the developer assigned to fix the bug to specify the circumstances (adaptation data, tools, and their pa-rameters) under which the bug appears. After fixing the bug, this developer must fill a field in the PR that de-scribes how the testing should be performed to properly validate the fix. This field is called ‘how to test.’ This information is then used by the test manager, who creates test matrices that will be used later by the testers during regression testing. The developer who fixes the bug also indicates in another field of the PR whether the documen-tation of the tool needs to be updated. Then, the docu-mentation expert uses this information to determine whether the manuals need to be updated based on the changes the PR introduced. Finally, another field in the PR conveys what needs to be checked by the manager when closing it. Therefore, the PR reminds the software manager of the aspects that need to be validated.

In short, the information provided by the PR is used by the developers to manage the several interdependencies in the software being developed. For example, since the user manual of an MVP tool depends on part of that tool’s source code, so changes in this source code need to be reflected in the manual. The information about such changes is provided to the documentation expert through one of the fields in the PR.

5.2. Naming Conventions

Developers share repositories containing the source code (the CM tool) and information about changes in this code (the bug-tracking tool). As a result, the team estab-lishes naming conventions that must be followed when dealing with these tools. Conventions are common and accessible rules or arrangements established in the group that act as a means to merge the different perspectives and work styles involved in handling shared objects [14].

An example of a convention is the naming convention used in the creation of branches in the CM tool: it must be based on the PR number recorded in the bug-tracking tool as well as on the developer’s name. This allows the rela-tionship that exists between a change and its correspond-ing PR to be clearly represented, therefore facilitating identification by MVP developers. However, these con-ventions are not properly supported by these tools, which is a source of complaints by the developers. Indeed, creat-ing and naming branches is a cumbersome task with four or five different tedious steps that could be automated because they follow a naming convention.

5.3. E-mail Conventions

As mentioned before, the MVP software development process prescribes that after checking-in code into the repository, a developer needs to send an e-mail to the software developers’ mailing list. However, we found out

that MVP developers perform these activities in the re-verse order—they will send e-mail before, not after, the check-in. By doing so, MVP developers allow their col-leagues to prepare for the changes. Indeed, developers might even send e-mail to the author of the change asking for a delay of its check-in. We also found out that in this same e-mail developers describe the impact that their changes will have on others’ work. A developer who reads these e-mails might walk to the co-worker’s office to ask about the changes or, if the change has already been committed, browse the CM and bug-tracking sys-tems to understand them. The following list presents some usual comments sent by MVP developers:

“No one should notice.” “(…) only EDP users will notice any change.” “Will be removing the following [x] file. No effect on re-compiling.” “Also, if you recompile your views today you will need to start your own [z] daemon to run with live data.” “The changes only affect [y]-mode so you shouldn't notice anything.” “If you are planning on recompiling your view this evening ([current date]) and running an MVP tool with live [z] data, you will need to run your own [z] daemon.” Sending e-mail before the check-ins with the descrip-

tion of the impact of the changes is an important conven-tion because it allows other developers to prepare and reflect about the effect of their colleagues’ changes in their current work. Because they are aware of some of the interdependencies in the source-code, they might conse-quently adjust to these changes.

In addition to the flexibility that allows the description of the impact of the changes, e-mail provides asynchro-nous communication, which requires storage of the mes-sages until their delivery to the recipient. This is used by MVP developers to learn about what changed in the code in a certain timeframe. For example, these e-mails were used by a developer to catch up with the changes that occurred while out of the office. They contained informa-tion that allowed the developer to identify changes that did not affect current work, but might affect future work. The following comment from another MVP developer supports this:

“(…) all of the sudden you were working and everything was going great and an e-mail comes through, you look at it, it does not mean a lot, you blow it (…) you keep working and one hour later things were broken. Why is that not working? Oh, that last check-in! You go back to that e-mail: who did this? And maybe you can go talk to that person: ‘you broke something’ (…)”

The information in the e-mail is also important be-cause it informs (or reminds) developers that they have been engaged in parallel development. Often, developers

are unaware of parallel activity because they do not check the version tree that displays information about other de-velopers working on the same file. The information in the e-mail is usually enough to tell the developer whether these changes should be incorporated right away or whether they can wait until just before check-in. In either case, the latest changes must be “merged back” into the developer’s version of the file. In general, if one file has been checked-in several times and a developer has the same file checked-out, he or she “merges back” the changes indicated in the e-mail to avoid working with an outdated file.

The asynchronous nature of e-mail could be problem-atic because developers might miss important notifica-tions about changes. However, during the field work, we did not notice any such problems. Furthermore, sending e-mail before a check-in is also used by other developers to support expertise identification and as a learning mechanism. Developers associate the author of the change with the “process” where the changes are being performed. In other words, MVP developers assume that if one developer constantly and repeatedly performs check-in in a specific process, it is very likely that the developer is an expert on that process. Therefore, another developer needing help with that process will look to that developer for help:

“[talking about a bug in a process that he is not expert] (…) I don’t understand why this behaves the way it does. But, most of these PR’s seem to have John’s name on it. So you go around to see John. So by just by reading the [PR] head-line of who does what, you kind of get the feeling of who’s working on what (…).So they [e-mails] tend to be helpful in that aspect as well. If you’ve been around for ten years, you don’t care, you already know that [who works with what], but if you’ve been here for two years that stuff can really make difference (…)” In addition, the simple fact that developers read the e-

mails sent by other developers to check for the impact of others’ changes facilitates learning about the MVP soft-ware. Interestingly, the two developers who reported these aspects of e-mail were relative novices at MVP, with 2 years and 2.5 months experience there.

5.4. Holding onto Check-ins

As mentioned, MVP developers add to the e-mail the description of the impact of their changes in other devel-opers’ code. The two most common types of impact statements are changes in run-time parameters of a proc-ess and the need to recompile parts or the whole source

code1. The former case is very important because other developers might be running the process that will be changed. The latter case is described because when a file is modified, it, as well as the other files that depend on it, will be recompiled, and this recompilation process is time-consuming—up to 45 minutes. Developers are aware of the delay they might cause to others; therefore, they hold check-ins until the evening. According to one of the developers:

“(…) and the other thing that you find is that when people also know that if they are going to check-in a file they will do in the later afternoon … you’re gonna do a check-in and this is gonna cause anybody who recompiles that day have to watch their computer for 45 minutes (…) and most of the time, you’re gonna see this coming at 2 or 3 in the after-noon, you don’t see folks (….) you don’t see people doing [file 1] or [file 2] checking-in at 8 in the morning, because everybody all day is gonna sit and recompile.” Holding onto check-ins is an informal approach

adopted by the MVP software development team to mini-mize the problems caused by the interdependencies that exist on the source code. However, this is possible only because MVP developers are aware of the existing inter-dependencies.

5.5. Engagement in Parallel Development: Partial Check-ins and “Speeding Up” the Process

We also noted that MVP developers engage very often in parallel development. This happens when more than one developer has the same file checked-out. Conflicts might occur when one of these developers checks-in this file back into the repository because the other developer’s version will then be outdated, and any changes that de-veloper makes will potentially be inappropriate. To up-date the version, the developer needs to merge the other’s changes back in his or her code. This operation is called by the developers “back merging,” and in CM terminol-ogy is named “synchronization of workspaces.” Due to the need to perform these back merges, a new depend-ency between artifacts is created during parallel develop-ment. This dependency occurs between any version of a file that has not yet been checked-in and the new version of this same file created after the check-in (i.e., the cur-rent version of a file checked-out by a developer is now dependent on the new version checked-in into the reposi-tory because the former needs to incorporate the changes of the latter before being checked-in). This is another example of dependency in software development.

1 The CM tool used by the MVP team allows developers to choose if they want to incorporate others’ changes, meaning that they are able to decide if they want to recompile the code or not.

Conflicting changes are more likely to occur in files that are accessed by several developers at the same time. For example, in MVP software, some files are used to define programming language structures that are used all over the code. Different developers often change these files, which means that they have a high degree of parallel development. These files are especially important because there is a significant correlation between them and the number of defects reported [20]. MVP developers re-ported that they do not avoid parallel development in these files because conflicts are infrequent and not likely to occur. But, without access to the CM tool, it was not possible to statistically test this claim. MVP developers accepted parallel development because it was necessary to achieve high productivity. However, we identified that they adopted a strategy to deal with files with a high de-gree of parallel development. To minimize the possibility of conflicts, developers would perform “partial check-ins,” which consists of checking-in some of the files back into the repository, even when the developers have not yet finished all their changes. This strategy decreases the number of dependencies that occur, and consequently reduces the number of necessary back merges. Note that partial check-ins are variations of the formal software development process, which establishes that check-ins will be performed only when the changes in all files are finished.

Finally, according to Grinter [9], software developers might rush to finish their work when they engage in par-allel development because they want to avoid merging. We identified that developers will rush only when they are testing their changes right before check-in. As one developer plainly pointed out: “This is a race!” According to the software development process, this testing is neces-sary to guarantee that the changes will not introduce bugs into the system. We observed that this testing is very in-formal. For example, developers will sit in the V&V Laboratory and compare the current version of the MVP with the one with changes. In short, MVP developers do not use regression testing at this moment. That will be used by the V&V staff before creating a new release of the software. This means that techniques that minimize the number of test cases necessary to validate the changes in the software (e.g., [23]) cannot be used by MVP devel-opers to determine whether the tests they need to run can be impacted by changes that another developer makes. These techniques can be used only by the V&V staff.

Although we observed that some check-ins introduced errors, we do not have evidence that these errors were introduced due to this “racing.” Similar to partial check-ins, “speeding up” the process is employed by the MVP developers to avoid the additional work necessary to deal with the extra-dependencies that occur during parallel development.

6. Computational Support for Informal Approaches

Figure 1 summarizes the formal and informal ap-proaches used by the MVP team to manage the interde-pendencies that occur during their software development activities. As mentioned before, formal and informal ap-proaches complement each other, so problems not solved by the formal approaches might be solved by the informal ones. For example, none of the formal approaches used by the MVP team addresses the issue of how to manage the crossing-boundaries dependencies that occur when a change is committed into the repository. This problem is solved by the MVP team by adopting a particular PR structure that provides information for developers with different roles (see section 5.1).

Figure 1: Formal and Informal Approaches Adopted by the MVP Software Development Team

The tools used by the MVP team assist some of the in-formal approaches. For example, the CM tool allows software developers to perform partial check-ins. In con-trast, due to the lack of tool support, developers need to rush to finish their work when they are testing their changes. In this section, we discuss the existence (or lack) of support for informal approaches in more detail. In ad-dition, we discuss implications for software engineering research when there is a lack of support.

6.1. Problem Reports as Boundary Objects

Bug-tracking tools are flexible enough to allow their managers to define the fields that will compose a PR. In addition, these tools allow a manager to specify a simple workflow describing when each one of these fields needs to be filled in [12]. By doing that, they allow the creation of PRs with fields that contain information that is useful

to developers who are members of different groups. In the MVP team, the information in these fields describes how each developer’s work is going to be affected by the PR. This means that these tools allow PRs to be defined and used as coordination mechanisms to manage interdepend-encies during software development.

6.2. Support for Naming Conventions

Following conventions for dealing with shared objects (or repositories) implies additional effort; hence, technical support often is needed [14]. As mentioned before, MVP developers follow a naming convention in which the name of the branches in the CM tool should be based on the PR number recorded in the bug-tracking tool. MVP developers have complained that the task of creating branches is very cumbersome, with four or five different tedious steps to be performed. Because this task is based on a convention, it could be automated. Unfortunately, the current integration between the CM and the bug-tracking tool does not support that. That is a major source of complaints repeatedly reported by the MVP software developers during the interviews.

6.3. Support for E-mail Conventions

NASA requires ISO 9001 certification for all software development efforts, which means that all changes in the software must be documented, reviewed, and formally authorized before the changes are integrated in the code. In other words, developers need to be accountable for their work. The MVP team chose to use e-mail as a for-mal communication channel in the organization, as clearly mentioned in the software development process. Indeed, some of the tasks (such as requesting and answer-ing code reviews) were performed by using e-mail. These tasks require the use of software development tools such as source-code editors, CM tools, and so on. Unfortu-nately, e-mail is not integrated with these tools, which means that developers need to move back and forth be-tween e-mail and the other tools in order to get their work done. Integration of e-mail with software development technology seems easy to implement; it is also very prom-ising because more and more software development or-ganizations are seeking certifications such as ISO 9001 and CMM (Capability Maturity Model). This aspect was identified during the field work and later corroborated by MVP software developers during the interviews. In addi-tion, e-mail messages exchanged among developers are also used to identify expertise in parts of the source code, as well as a history mechanism to identify changes that happened in the past. Again, this information could and should be properly organized and indexed in order to fa-cilitate these activities.

Management of

Interdependencies

Formal

Approaches

Informal

Approaches

- Software development process - Software development tools - Pre-design and V&V meetings - Division of labor, etc.

- PRs as boundary objects - Conventions - Holding onto check-ins - Partial check-ins

6.4. Holding onto Check-ins

The informal approach of holding onto check-ins is used to avoid disrupting others’ work. The support for this task provided by CM tools is appropriate because these tools allow a developer to check files in or out and merge different versions of them at any time. However, this approach is useful only if the developer who is going to check-in some code is aware that his or her work will cause the recompilation of other files. This suggests that software visualization tools (e.g., [4]) that use existing information from the CM tool could be used to support the identification of these files by novice developers who are not aware of the interdependencies in the source code.

6.5. Partial Check-ins

A check-in is called “partial” by the MVP developers when it is performed without a code review to avoid sev-eral “back merges” due to the file being changed by sev-eral other developers at the same time. CM tools support partial check-ins because they usually do not impose con-straints about when check-ins might be performed, allow-ing one to check-in code into the repository at any time. However, the current trend of integrating CM tools with software process technology [5] might disrupt that. We recognize this integration is essential because it allows the efficient automation of repetitive tasks (such as building a software release) [12]. Nevertheless, the enforcement of the process that usually goes along with this integration must be managed, because it has long been recognized as problematic [29]. CM tools must be flexible enough to allow software developers to use workarounds that devi-ate from the process in order to properly deal with the problems that they face. One example of such work-arounds is the partial check-in. Another approach is to update the software development process to reflect the need for partial check-ins, and consequently legitimate them. In this case, similar to holding check-ins, the in-formation already present in the CM tool could be used by software visualization tools [4] to allow novice devel-opers to identify files with a high degree of parallel de-velopment that need to be partially checked-in.

6.6. Speeding Up the Process

MVP developers rush their activities during the devel-opment process to minimize the number of dependencies between their code and recently committed changes in the repository (section 5.5). Current CM and bug-tracking tools create the need to speed up because they shield a developer’s workspace from other developers’ work-spaces to support parallel development. Although it is desirable to isolate one developer’s work from others, it does not allow developers to coordinate their check-ins,

and hence avoid the need to re-do their work. To the best of our knowledge, no existing software engineering tool solves this problem. However, a promising approach re-cently emerged with tools that attempt to break the isola-tion of CM workspaces (e.g., [24] and [17]). These tools achieve that by distributing the CM commands happening in a developer’s workspace to other selected workspaces. These tools focus on the actions of the developers (con-veyed as CM commands) because they want to avoid con-flicts between the files that two or more developers have checked-out. In addition, we argue that these tools need to provide information about the “status” of other devel-opers’ work. By doing that, they allow a developer to identify who is about to check-in code into the repository and, therefore, to coordinate their work, so that a devel-oper does not need to rush. We believe that this can be achieved by extending these tools to collect information from sources other than the CM tool, such as e-mail, the bug-tracking tool, the software process specification, and so on.

7. Discussion

As mentioned before, a formal process description can never completely represent all variations that might occur in a software development effort [8]. Therefore, as the data have suggested, informal approaches need to be adopted to complement the formal approaches to properly support the management of the interdependencies that occur in the software development process. However, to properly support cooperative software development, we need to unveil these informal approaches and provide computational support for them to minimize errors and improve their performance. One of the reasons these in-formal approaches are important is the high level of paral-lel development that occurs in large-scale collaborative efforts [20]. Indeed, the engagement in parallel develop-ment identified in this field study helps to substantiate the results of Perry et al. [20] that describe high levels of par-allel development, but contrasts with the groups studied by Grinter [9, 11], in which developers avoided this situa-tion. Technical improvements in merging techniques from 1995 to 2002 [2] might be the cause of divergence from Grinter’s earlier observations. Grinter, however, does not clearly describe the branching strategy used by the team studied, whereas the MVP team adopted the “branch-by-purpose” strategy. According to Walrad and Strom [31] this “strategy supports a high level of parallel develop-ment by allowing developers to work on different branches at the same time. Therefore, this might be an-other explanation for the difference between the two groups. Finally, an organization’s structural properties (e.g., reward systems, policies, norms, and so on) are other factors that influence the adoption and use of col-

laborative tools [18]. The two organizations studied are different, hence they are very likely to have different structural properties, which might explain the different levels of engagement in parallel development.

Meanwhile, this field study supports Grinter’s [9] find-ing that during parallel development developers will rush to finish their changes. However, while the developers studied by Grinter will speed up because they want to avoid the complexity of merging, MVP developers rush because they do not know when another developer might check-in some code that will lead them to another set of tests. In both studies, developers describe their dilemma: they want to produce high-quality code, but they also want to finish their changes fast.

The MVP team needs to perform extra work to suc-cessfully manage the interdependencies in the software. This extra work is a form of articulation work necessary to coordinate, negotiate, mesh, and schedule their activi-ties [25]. It is different from recomposition work [10], which is the coordination required to assemble software development artifacts from their parts, because recompo-sition work focuses on choosing the right components to create a software artifact due to source-code dependen-cies, whereas this extra work focuses on the management of all dependencies that exist in a software development effort.

Finally, in this informal field study we identified an-other approach used by software developers to identify experts. Whereas McDonald and Ackerman [16] describe the usage of change history data (equivalent to PRs in the MVP team), novice developers in the MVP team use the broadcasted e-mail messages prescribed by the software development process. The importance of finding experts for problem-solving in any organization and the complex-ity of the MVP code suggest that the operation of sending e-mail before a check-in is essential.

8. Conclusion and Final Remarks

This paper reports the findings of an informal field study conducted at the NASA/Ames Research Center during the course of an eight-week internship with a software development. The results of this field study de-scribe the formal and informal practices adopted by team members to manage the interdependencies that occur dur-ing software development. Formal approaches are those legitimated by the organization; the informal ones are those that emerge naturally due to the needs of the devel-opers. Examples of formal approaches adopted by the team are the software development process, some soft-ware development tools, design meetings, and a clear division of labor. The informal approaches that we identi-fied are partial check-ins, problem reports that cross work

boundaries, holding onto check-ins, e-mail and naming conventions, and the action of speeding up the processes.

In this work, we also indicate current and nonexisting computational support to the informal approaches. In-deed, partial check-ins, problem reports that cross work boundaries, and holding onto check-ins are work prac-tices currently supported by CM and bug-tracking tools. E-mail and naming conventions and the action of speed-ing up the processes are adopted by MVP developers due to the lack of tool support. We believe that these interest-ing research areas should be further investigated. Pointing out these areas is an important contribution of this paper.

Finally, we are planning a future study in a different organization. We seek to identify similarities and differ-ences in the formal and informal approaches that we iden-tified here and to learn how the ones that we identified are used in a different context.

Acknowledgments

The authors thank CAPES (grant BEX 1312/99-5) and NASA/Ames for financial support. This effort was also spon-sored by the Defense Advanced Research Projects Agency (DARPA) and Air Force Research Laboratory, Air Force Mate-riel Command, USAF, under agreement number F30602-00-2-0599. Funding also was provided by the National Science Foun-dation under grant numbers 0205724 and 0083099. The U.S. Government is authorized to reproduce and distribute reprints for governmental purposes notwithstanding any copyright anno-tation thereon. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either ex-pressed or implied, of DARPA, the Air Force Laboratory, or the U.S. Government.

9. References

[1] Appleton, B., Berczuk, S., et al., "Streamed Lines: Branch-ing Patterns for Parallel Software Development," Proceed-ings of Pattern Languages of Programs (PLoP'98), Washington University Technical Report #WUCS-98-25, 1998.

[2] Conradi, R., and Westfechtel, B., "Version Models for Software Configuration Management," ACM Computing Surveys, vol. 30, pp. 232-282, 1998.

[3] Curtis, B., Krasner, H., et al., "A Field study of the Soft-ware Design Process for Large Systems," Communications of the ACM, vol. 31, pp. 1268-1287, 1988.

[4] Eick, S. G., Graves, T. L., et al., "Visualizing Software Changes," Software Engineering, vol. 28, pp. 396-412, 2002.

[5] Estublier, J., "Software Configuration Management: A Roadmap," Future of Software Engineering, pp. 279-289, Limerick, Ireland, 2001.

[6] Finkelstein, A., Kramer, J., et al., Software Process Model-ing and Technology: Wiley, 1994.

[7] Gamma, E., Helm, R., et al., Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addi-

son-Wesley, 1995. [8] Gerson, E. M., and Star, S. L., "Analyzing Due Process in

the Workplace," ACM Transactions on Office Information Systems, vol. 4, pp. 257-270, 1986.

[9] Grinter, R., "Supporting Articulation Work Using Configu-ration Management Systems," Computer Supported Coop-erative Work, vol. 5, pp. 447-465, 1996.

[10] Grinter, R. E., "Recomposition: Putting It All Back To-gether Again," Conference on Computer Supported Coop-erative Work (CSCW'98), pp. 393-402, 1998.

[11] Grinter, R. E., "Using a Configuration Management Tool to Coordinate Software Development," Conference on Organ-izational Computing Systems, pp. 168-177, 1995.

[12] Grinter, R. E., "Workflow Systems: Occasions for Success and Failure," Computer Supported Cooperative Work, vol. 9, pp. 189-214, 2000.

[13] Kraut, R. E., and Streeter, L. A., "Coordination in Software Development," Communications of the ACM, vol. 38, pp. 69-81, 1995.

[14] Mark, G., Fuchs, L., et al., "Supporting Groupware Con-ventions through Contextual Awareness," European Con-ference on Computer-Supported Cooperative Work (ECSCW '97), pp. 253-268, Lancaster, England, 1997.

[15] McCracken, G., The Long Interview: Thousand Oaks, CA: SAGE Publications, 1988.

[16] McDonald, D., and Ackerman, M., "Just Talk to Me: A Field Study of Expertise Location," Conference on Com-puter Supported Cooperative Work, pp. 315-324, 1998.

[17] O'Reilly, C., Morrow, P., et al., "Improving Conflict Detec-tion in Optimistic Concurrency Control Models," 11th In-ternational Workshop on Software Configuration Manage-ment (SCM-11), Portland, Oregon, 2003.

[18] Orlikowski, W., "Learning from Notes: Organizational Issues in Groupware Implementation," The Information So-ciety, vol. 9, 1993.

[19] Parnas, D. L., "On the Criteria to Be Used in Decomposing Systems into Modules," Communications of the ACM, vol. 15, pp. 1053-1058, 1972.

[20] Perry, D. E., and, Siy, H. P., et al., "Parallel Changes in Large-Scale Software Development: An Observational Case Study," ACM Transactions on Software Engineering and Methodology, vol. 10, pp. 308-337, 2001.

[21] Perry, D. E., Staudenmayer, N. A., et al., "People, Organi-zations, and Process Improvement," IEEE Software, vol. 11, pp. 36-45, 1994.

[22] Podgurski, A., and Clarke, L. A., "The Implications of Program Dependencies for Software Testing, Debugging, and Maintenance," Symposium on Software Testing, Analysis, and Verification, pp. 168-178, 1989.

[23] Rothermel, G. and Harrold, M. J., "A Safe, Efficient Re-gression Testing Selection Technique," ACM Transactions on Software Engineering and Methodology, vol. 6, pp. 173-210, 1997.

[24] Sarma, A., Noroozi, Z., et al., "Palantír: Raising Awareness among Configuration Management Workspaces," Twenty-fifth International Conference on Software Engineering, pp. 444-453, Portland, Oregon, 2003.

[25] Schmidt, K., and Bannon, L., "Taking CSCW Seriously: Supporting Articulation Work," Journal of Computer Sup-ported Cooperative Work, vol. 1, pp. 7-40, 1992.

[26] Shull, F., Carver, J., et al., "An Empirical Methodology for Introducing Software Processes," Joint 8th European Soft-ware Engineering Conference and 9th ACM SIGSOFT Symposium on the Foundations of Software Engineering, pp. 288-296, Vienna, Austria, 2001.

[27] Star, S. L., and Griesemer, J. R., "Institutional Ecology, Translations and Boundary Objects: Amateurs and Profes-sionals in Berkeley's Museum of Vertebrate Zoology," So-cial Studies of Science, vol. 19, pp. 387-420, 1989.

[28] Strauss, A., and Corbin, J., Basics of Qualitative Research: Techniques and Procedures for Developing Grounded Theory, Thousand Oaks, CA: SAGE publications, 1998.

[29] Suchman, L., Plans and Situated Actions: The Problem of Human-Machine Communication. Cambridge: Cambridge University Press, 1987.

[30] Vessey, I., and Sravanapudi, A. P., "CASE Tools as Col-laborative Support Technologies," Communications of the ACM, vol. 38, pp. 83-95, 1995.

[31] Walrad, C., and Strom, D., "The Importance of Branching Models in SCM," IEEE Computer, vol. 35, pp. 31-38, 2002.

Opportunities for Extending Activity Theory for Studying Collaborative Software Development

Cleidson R. B. de Souza† and David F. Redmiles

School of Information and Computer Science University of California, Irvine

{cdesouza, redmiles}@ics.uci.edu

Abstract Activity theory is an analytical framework that has been used successfully to understand and explain collective work. Software development is, of course, one particular kind of collective work. We used activity theory to analyze the observations one author made during an internship with a large-scale software development group. We also made some observations about how well suited activity theory was for the analysis. We briefly describe the work setting and the analysis. Then we describe the experi-ences we had, which indicate possibilities for further de-veloping activity theory for studying collaborative work.

1. An Experience with Collaborative Soft-ware Development

The first author spent eight weeks during the summer of 2002 interning as a software developer on a large-scale software development team. As a member of this team, he was able to make observations and collect information about a variety of aspects, including the organization of the team, the formal and informal practices that this team adopted, and the tools they used. The software develop-ment team was formed to develop a software application we call MVP (not the real name), which comprises 10 different tools that are deployed in different parts of the United States. The source code is approximately one mil-lion lines of C and C++.

Each of the several different tools that compose MVP uses a specific set of “processes.” A process for the MVP team is a program that runs with the appropriate run-time options. Processes typically run on distributed Sun work-stations and communicate by using a TCP/IP socket pro-tocol. Running a tool means running the processes re-quired by this tool, with their appropriate run-time op-tions.

The software development team is divided into two groups: the developers and the verification and validation (V&V) staff. The developers are responsible for writing new code, fixing bugs, and adding new features. This group comprises 25 members. The V&V staff are respon-sible for testing and reporting bugs identified in the soft-ware, keeping a running version of the software for dem-

†

Also at the Department of Informatics, Universidade Federal do Pará, Belém, PA, Brazil.

onstration purposes, and maintaining the documentation (mainly user manuals) of the software. This group com-prises six members.

The MVP group adopts a formal software develop-ment process that prescribes the steps that need to be per-formed by the MVP developers during the software de-velopment activities. For example, all developers, after finishing the implementation of a change, should integrate their code with the main baseline. In addition, each de-veloper is responsible for testing the code to verify that his/her integration did not insert bugs in the code, or “break the code,” as this is informally characterized by MVP developers. After using a configuration manage-ment (CM) tool to check-in files into the repository, a developer must send an e-mail to the software develop-ment mailing list describing the problem report (PR) as-sociated with the changes, the files that were changed, and the branch where the check-in will be performed, among other pieces of information.

2. An Activity Theory Analysis Activity theory allows a variety of ways to analyze phe-nomena. In this work, Engeström’s activity theory model [4] was used in the analysis of findings. This model is presented in Figure 1. Activities are associated with ob-jectives called “outcomes.” People working within a community share activities. They work to create objects and rely on tools referred to as artifacts to support their activity. Rules instantiate division of labor and practices of the community.

Figure 2 is basically an “instantiation” of the frame-work described in Figure 1 as applied to the MVP soft-ware development team. The main outcome of the soft-ware development activity is high-quality MVP software (i.e., bug-free software that is easy to evolve, delivered on schedule, and meets the customers’ specifications). Of course, this includes executables, source code, bug re-positories, manuals, specifications, and so on. The object of this activity is the MVP software while being modified. This includes, for example, the changes being introduced in the code, reported bugs not yet solved, and so on. The mediating artifacts, or tools, are the set of tools used by the team to manipulate the object so they achieve their goal or outcome, such as CM and bug tracking tools, e-mail, and the like. Rules consist of formal practices

Figure 1: Elements of the Activity Theory Framework (see [4]).

Figure 2: The Software Development Activity as Ap-plied to the MVP Team

(e.g., software development processes) and informal prac-tices (conventions, workarounds, and so on) used by the MVP team. The community is the whole MVP team, which is organized according to a specific division of la-bor: There are mainly two groups, namely, developers and V&V staff. But the members of these groups also adopt a division of labor. Specifically, there are process leaders and process developers, the configuration and release manager, the software manager, and testers. 2.1. Tensions and Their “Fixes” in the MVP

Team Contradictions are important aspects in an activity be-cause they might be used as sources of development ([6], pg. 34). In other words, contradictions trigger reflection, thereby helping in the improvement of the activity. Con-tradictions reveal themselves as breakdowns, problems, tensions, or misfits between elements of an activity or between activities. In our case, we identified several ten-sions within the software development activity developed by the MVP team, but, in addition to that, we also identi-fied the fixes that the team adopted to solve them. We identified tensions between different elements, such as between the object and the community, and between the

rules and the community. In the first case, the tension between the object and

the community exists due to the effects that the object (e.g., changes in the MVP software) will have on the community. For example, if a change (the object) is in-troduced in the source code, other members of the MVP team (the community) might need to be informed because they may need to perform additional tasks (e.g., update the documentation) due to that change. The tension exists because developers are not aware of some interdependen-cies in the software and, therefore, how other members of the community are affected by their work. Despite that, the community must support the evolution of the software and guarantee that the software delivered is not inconsis-tent with the specifications, manuals and other artifacts.

In the second case, the tension exists basically be-tween rules and the community because one rule suggests that a developer should perform a specific action, but he/she does not want to perform that action out of con-cern for the effects of the action on the rest of the com-munity. For example, if one developer decides to check-in his/her code into the repository, the other developers (part of the community) might need to recompile their code in order to work with the latest version of the soft-ware, and this compilation process is time-consuming. 2.2. Tensions between the Object and the Com-

munity In this case, tensions emerge in the software development activity due to the concern about how the object will af-fect the community. For example, when the source code is modified, often it is also necessary to modify other software artifacts, such as manuals, documentation, speci-fications, and so on, or inconsistencies will arise. Al-though inconsistencies might have positive effects in software development, in general they are not desirable [10]. The MVP software development team already rec-ognized the need to handle this problem (tension) and adopted two different and complementary practices to deal with it: Formal reviews are adopted in the software development process to handle inconsistencies in the source code, and problem reports are structured in such a way that the inconsistencies between source code and other artifacts are easier to manage. Both practices are explained in the following sections.

2.3. Tensions between the Rules and the Commu-

nity These tensions occur because a rule might suggest that a developer should perform a specific action, but the devel-oper does not want to perform it due to concern about the effect of this action on the community. As mentioned earlier, an example of such tension occurs when one developer needs to check-in his/her code into the repository, but the other developers would then need to recompile their code in order to work with the latest

Subject

Rules Community Division of labour

Object → Outcome

Mediating Artefacts

Subject (developers)

Rules

(software process, conventions)

Community (MVP team)

Division of Labour (developers and V&V staff)

Object (MVP software) → Outcome (MVP SW without bugs, etc)

Artefacts (CM tools, bug tracking, e-mail)

their code in order to work with the latest version of the software. Because this compilation process is time-consuming, the developer needs to decide whether to fol-low the rule and thus cause the whole community to recompile, or to not follow the rule, at least for a while, thereby minimizing the impact of his/her actions in the rest of the community. Typical fixes adopted by the MVP team include changing the order in which some rules are executed or performing additional actions along with the rule to minimize the disruption to the community.

Furthermore, tensions between these components also arise due to the impact on the community in the execution of the rule. In other words, the developer is concerned that he/she needs to perform a rule but actions of the community (such as check-ins or check-outs) will impact his/her performance of the rule. In this case, those ac-tions influence how the developer performs the rule. Note that in this case, the division of labor also influences this tension because it prescribes how developers should be organized in the community, therefore allowing two or more developers to work and check-in in concurrently.

3. Implications for Activity Theory 3.1. Modeling Human Activity In software development terms, section 2 of this paper developed a model. The process of developing this model has more similarities to software modeling than one might expect. In particular, we began by choosing a modeling language that seemed appropriate for our application—the language of activity theory, and in particular Engeström’s terminology and diagrammatic notation. We then built an instance of a model in this language that served as a first approximation. We then refined it through several iterations. We reached a point at which analysis of the model yielded explanations consistent with the data, as presented above. Iterative refinement of the model appeared to be an open-ended process. However, the actual observations made during the internship acted in a sense like a “test oracle.” Namely, we reached a stopping point when all observed phenomena were accounted for. Moreover, the focus of activity theory on identifying tensions and con-flict were useful for understanding what we observed and for highlighting areas where software tools and practices might be improved. In sum, the attempt to model the human collective ac-tivity of collaborative software development did not seem straightforward at first, but required a first approximation and successive refinement. Although frustrating, the chal-lenges did not seem greater than other kinds of modeling, and the results were informative. In the next subsection, we make some observations on how this process may be improved and identify research areas for the methodol-ogy.

3.2. Activity Theory: Where Next? Activity theory has been applied to the design of software systems, and research to date has indicated its usefulness toward collecting requirements for software system de-sign (e.g., [1] and [8]). However, to the authors’ knowl-edge, this paper represents the first application of activity theory to studying collaboration among software devel-opers; previous studies have examined only the collabora-tion between end users and software developers. Thus, we had to struggle with a finer degree of detail of activity than previous works with respect to the development of software. One challenge that presented itself was the notion that a single activity might be consistent when observed as a single instance, but might be a source of tension when there were multiple instances of that activity. For in-stance, in the case of a single developer, even when work-ing with end users and other team members, the activity of checking-in a module revision is consistent within it-self. However, multiple instances of this check-in activity create a tension we observed as developers sped up their work to be the first to check-in. This part of the model and the more general issue of multiple instances of activ-ity is one place for further research into the application of activity theory and a potential contribution to improving the methodology. Another area for research in activity theory is akin to dependency analysis in software testing. Namely, as we identified different activities that comprised the general activity of evolving a software system, we began to ob-serve many interdependencies. For example, rules for applying a specific software tool led to other activities, each with their own associated set of rules, subjects, other tools, and so on. We were intrigued by the notion that a kind of dependency analysis might be developed to help an organization more precisely account for the potential impact of making changes to tools and practices. This kind of work, however, would be a long-term goal. A related issue is that of adoption. Understanding the his-tory of how elements in the activity theory models evolved (e.g., tools, rules, division of labor, and so on) can better enable the responsible introduction of new tools, including involving end users with tool introduc-tion. The basic premise of introducing changes into peo-ple’s work is the ability to develop the fullest understand-ing possible of that work. Activity theory, even in its pre-sent state of development, is successful in that regard. Finally, a new line of research is beginning to present itself around the concepts of reflection and awareness. Specifically, various researchers have begun to recognize the value of simply reflecting back to a group or organi-zation the actuality of its various objectives and activities. In a previous study, we used this kind of reflection as a matter of course in reporting findings, but the process of performing this “reporting” led to improvement in the

process of software developers collecting requirements and in the organization’s members better understanding one another’s roles [2]. Other researchers have observed similar effects, including those at a small scale. Namely, some researchers are developing software tools to help people coordinate their collaborative work by reflecting the current state of a collaborative activity or the state of actual collaborators. Some instances are Portholes sys-tems that reflect the state of collaborators [3] [7], configuration management tools that reflect who is working on what modules [9], and tickertape tools that reflect all activities in a work environment [5]. Thus, another open area is better understanding and better reflecting of actual activity (through manual and automated means) back to participants in that activity, and understanding ways this has positive effects on the collective work.

4. Conclusions Our experiences in performing the analysis presented

briefly in this paper as well as previous experiences of our own and our colleagues have shown many positives to activity theory. It is open ended, which, although a challenge, allows for the introduction of new ideas and refinements. It is noninvasive, using open-ended inter-views or even more informal observations of work such as presented in this paper. It readily yields to iterative refinement. When more detail is needed in a model, addi-tional activities may be named and analyzed. Finally, there seems to be some overlap in object-oriented analy-sis. Although the present authors do not wish to overem-phasize the similarities, the overlap is helpful for people with object-oriented experience to engage in learning the methodology. Thus, although there is still a great deal of craft involved in becoming acquainted with and applying activity theory, we have experienced many positives in our analyses in different work settings and anticipate the methodology becoming more refined and documented.

Acknowledgments The authors thank CAPES (grant BEX 1312/99-5) and NASA/Ames for financial support. This effort was also sponsored by the Defense Advanced Research Projects Agency (DARPA) and Air Force Research Laboratory, Air Force Materiel Command, USAF, under agreement number F30602-00-2-0599. Funding also was provided by the National Science Foundation under grant numbers CCR-0205724 and 9624846. The U.S. Government is

authorized to reproduce and distribute reprints for gov-ernmental purposes notwithstanding any copyright anno-tation thereon. The views and conclusions contained herein are those of the authors and should not be inter-preted as necessarily representing the official policies or endorsements, either expressed or implied, of the Defense Advanced Research Projects Agency (DARPA), the Air Force Laboratory, or the U.S. Government.

5. References [1] Bodker, S., Through the Interface: A Human Activity Ap-

proach to User Interface Design, Hillsdale, NJ: Lawrence Erlbaum, 1991.

[2] Collins, P., Shukla, S., et al., “Activity Theory and System Design: A View from the Trenches,” Computer Supported Cooperative Work—Special Issue on Activity Theory and the Practice of Design, vol. 11, pp. 55-80, 2002.

[3] Dourish, P., and Bly, S., “Portholes: Supporting Distributed Awareness in a Collaborative Work Group,” ACM Confer-ence on Human Factors in Computing Systems (CHI '92), Monterey, CA, 1992.

[4] Engeström, Y., “Activity Theory and Individual and Social Transformation,” pp. 19-38, in Engeström, Y., Miettinen, R., and Punamäki, R-L., “Perspectives on Activity The-ory.” Cambridge, UK: Cambridge University Press, 1999.

[5] Fitzpatrick, G., Mansfield, T., et al., “Augmenting the Workaday World with Elvin,” 6th European Conference on Computer Supported Cooperative Work, pp. 431-450, Co-penhagen, Denmark, 1999.

[6] Kuuti, K., “Activity Theory as a Potential Framework for Human-Computer Interaction Research,” pp. 17-44, in Nardi, B., “Context and Consciousness: Activity Theory and Human-Computer Interaction.” Cambridge, MA: The MIT Press, 1996.

[7] Lee, A., and Girgensohn, A., “NYNEX Portholes: Initial User Reactions and Redesign Implications,” ACM Confer-ence on Human Factors in Computing Systems (CHI '97), pp. 385-394, 1997.

[8] Nardi, B., and Redmiles, D., Eds. Computer Supported Co-operative Work, The Journal of Collaborative Computing, Special Issue on Activity Theory and the Practice of De-sign, Vol. 11, No. 1-2, p. 1-11, 2002.

[9] Sarma, A., Noroozi, Z., et al., “Palantír: Raising Awareness among Configuration Management Workspaces,” Twenty-fifth International Conference on Software Engineering, pp. 444-453, Portland, Oregon, 2003.

[10] Spanoudakis, G., and Zisman, A., “Inconsistency Manage-ment in Software Engineering: Survey and Open Research Issues,” in Handbook of Software Engineering and Knowl-edge Engineering, vol. 1, S. K. Chang, Ed.: World Science Publishing Co., 2001, pp. 329-380.

“Breaking the Code”, Private and Public Work in Collaborative Software Development Cleidson R. B. de Souza1,2 and David F. Redmiles2 1Universidade Federal do Pará, Brazil and 2University of California, Irvine, USA cdesouza@ics.uci.edu, redmiles@ics.uci.edu

Abstract. As a cooperative effort, software development is especially difficult because of the many interdependencies amongst the artifacts created during this activity. In order to minimize problems created by these interdependencies, some software development tools create a distinction between private and public aspects of work of the developer. Technical support is provided to these aspects as well as for transitions between them. However, we present empirical material collected from a software development team that suggests that the transition from private to public work needs to be more carefully handled. Indeed, our analysis suggests that different formal and informal work practices are adopted by the developers to allow a delicate transition, where software developers are not largely affected by the emergent public work.

Private and Public Work in CSCW Software engineers have sought for quite some time to understand their own work of software development as an important instance of cooperative work, especially seeking ways to provide better software tools to support developers (Curtis, Krasner et al. 1988). Indeed, they created different tools, such as configuration management (CM) and bug tracking systems, to facilitate the coordination of groups of developers (Grinter 1995). However, software development is especially difficult as a cooperative endeavor because of the several interdependencies that arise in any software development effort. To minimize these problems, CM systems adopt design constructs (like branches and workspaces used in configuration management systems) to shield each individual from effects of other developers’ work. These workspaces enforce a distinction between the private aspects of work developed by the software engineer and the public aspects that occurs when this developer shares his work with the other developers. Similar approaches have been taken in other categories of collaborative applications (e.g., collaborative writing and hypermedia systems), which have adopted this distinction between private and public work in order to facilitate collaboration. This is usually done through the provision of separate private and public (or shared) workspaces. Private workspaces allow users to work in different parts of a document in parallel and contain information that only one user can see and edit allowing him to create drafts that later will be shared with the other co-workers. On the other hand, public workspaces allow all users to share the same information or document.

When support for private and public work is provided, it is also necessary to support transitions between them. The central issue in systems maintaining separate workspaces is how information or

activity moves between them, and similarly, the central mechanism around which CM systems are built is the mechanism for moving information between public and private conditions – checking in, checking out, merging. In cooperative working settings, people selectively choose when and how to disclosure their private work to others, i.e., they want to be able to control the emergence of public information (Ackerman 2000). CM tools and collaborative authoring tools provide support for these transitions. In collaborative writing, for example, one can basically copy the content of a private workspace and paste into the public workspace. On the other hand, in CM systems, more sophisticated tools involving merging algorithms and concurrency control policies need to be used because of the aforementioned interdependencies in the software.

Transitions between private and public work (and vice-versa) are particularly important in cooperative work and can lead to problematic situations when overlooked. Indeed, Sellen and Harper (Sellen and Harper 2002) describe some case studies of companies that had problems because they underestimated the delicacy of this transition. Despite that, insufficient analytical attention has been given to this transition by the CSCW community. In this paper, we will examine this issue with empirical material collected from a collaborative software development effort. The team observed used three software development tools for coordination purposes. However, these tools alone were not sufficient to effectively support the team; participants needed to adopt a set of formal and informal work practices to properly support private, public work and transitions between them. The adoption of these different work practices suggests that the computational support provided by these systems to support the emergence of private information is still unsatisfactory.

Setting and Methods

The group studied develops an application called MVP (not the real name) and is divided in two teams: developers and the verification and validation staff (V&V). Developers are responsible for writing new code, for performing bug fixing, enhancements, and so on. There are 25 developers, including researchers that write their own code. The V&V team (6 engineers) is responsible for testing the software, keeping a running version for demonstration and maintaining user manuals.

The first author spent eight weeks during the summer of 2002 as a member of the MVP team. During that time, he was able to interview developers, make observations and collect information about several aspects of the team. He also talked with his colleagues to learn more about their work. Additional material was collected by reading manuals of the MVP tools, manuals of the software development tools used, formal documents (like the description of the software development process and the ISO 9001 procedures), problem reports (PR’s), and so on.

MVP Practices to Handle Private and Public Work

The main tools used by the MVP team to coordinate their activities are the configuration management (CM) and the bug tracking tools (Grinter 1995). Branching in CM tools are used to create shields between developers’ workspaces isolating one’s work from others (Conradi and Westfechtel 1998). On the other hand, merging mechanisms are created to allow one’s work to be combined with other developers’ work. In other words, branches support private work, while merging mechanisms support the transition from private to public work. Finally, building mechanisms in CM tools support the public work because they allow developers to automatically recompile the code in order to incorporate changes recently committed in the repository.

In general, we identified that the private and public work are properly supported by the software development tools and by the software development process adopted by the MVP. However, except for

the merging mechanisms embedded in CM tools, the transitions between private and public are improved through informal work practices because of the need developers have to manage the interdependencies. Examples of these practices will be briefly discussed in the following paragraphs.

We called the first practice “holding onto check-in’s”. Developers will hold onto check-in’s (and merges) when they realize that their work (in this case, their changes in the software) will imply in the recompilation of the whole source code. They avoid that because they know that the recompilation process is time-consuming usually taking between 30 to 45 minutes. This means that other developers will waste their time waiting for the recompilation of their local copies.

After making their work public by merging it back into the repository, the software development process prescribes that MVP developers must send an e-mail to the whole software development group informing about the new changes in the system. However, these developers will send this e-mail before committing their changes and will also add a brief description of the impact that these changes will cause on their colleague’s work. In this case, because of these e-mail messages, other developers might reflect about the effect of their colleagues’ changes in their current work and prepare for that. This is possible because they are aware of some interdependencies in the source-code. The convention (adding impact statements in the e-mails) is the second practice identified.

A third approach identified was the “partial check-in”, which consists of checking-in files back in the repository, even when the developers have not yet finished their entire work. This is used to deal with parallel development in files that are changed very often. This practice allows developers to reduce the work necessary to make their work public, as it minimizes the number of updates that they need to perform in their files before merging them into the main repository.

Finally, we also identified that problem reports (PR’s) are used by different stakeholders (e.g., end-users liaisons, developers and testers) to manage the software interdependencies. For example, when a bug is identified, it is associated with a specific PR. Whoever identified the problem is also responsible for filling in the PR with information about ‘how to repeat’ it. This description is used by the developer assigned to fix the bug to specify the circumstances (adaptation data, tools and their parameters) under which the bug appears. In short, MVP members use the information from the PR’s in many different ways, according to the role they are playing.

Conclusions

We briefly described some of the work practices adopted by software developers to properly handle the transition between their private and their public work. MVP developers employ these practices because of the interdependencies that exist in the software. As mentioned before, the adoption of these practices suggests that computational support is necessary in cooperative software development tools to support the emergence of private information.

References Ackerman, M. S. (2000). "The Intellectual Challenge of CSCW: The Gap Between Social Requirements and Technical

Feasibility." Human-Computer Interaction 15(2-3): 179-204. Conradi, R. and Westfechtel, B. (1998). "Version Models for Software Configuration Management." ACM Computing

Surveys 30(2): 232-282. Curtis, B., Krasner, H. and Iscoe, N. (1988). "A field study of the software design process for large systems."

Communications of the ACM 31(11): 1268-1287. Grinter, R. E. (1995). Using a Configuration Management Tool to Coordinate Software Development. Conference on

Organizational Computing Systems, Milpitas, CA, 168-177. Sellen, A. J. and Harper, R. H. R. (2002). The Myth of the Paperless Office. Cambridge, Massachusetts, The Mit Press.

“Breaking the Code”, Moving between Private and Public Work in Collaborative Software Development

Cleidson R. B. de Souza1,2 David Redmiles1 Paul Dourish1

1School of Information and Computer Science

University of California, Irvine

Irvine, CA, USA – 92667

2Departamento de Informática

Universidade Federal do Pará

Belém, PA, Brazil - 66075

{cdesouza,redmiles,jpd}@ics.uci.edu

ABSTRACT Software development is typically cooperative endeavor where a group of engineers need to work together to achieve a common, coordinated result. As a cooperative effort, it is especially difficult because of the many interdependencies amongst the artifacts created during the process. This has lead software engineers to create tools, such as configuration management tools, that isolate developers from the effects of each other’s work. In so doing, these tools create a distinction between private and public aspects of work of the developer. Technical support is provided to these aspects as well as for transitions between them. However, we present empirical material collected from a software development team that suggests that the transition from private to public work needs to be more carefully handled. Indeed, the analysis of our material suggests that different formal and informal work practices are adopted by the developers to allow a delicate transition, where software developers are not largely affected by the emergent public work. Finally, we discuss how groupware tools might support this transition.

Categories and Subject Descriptors H.4.1 [Office Automation]: Groupware; H.5.3 [Group and Organization Interfaces]: Computer-supported cooperative work;

General Terms Human Factors

Keywords Private work, public work, collaborative software development, qualitative studies.

1. INTRODUCTION Software engineers have sought for quite some time to understand their own work of software development as an important instance of cooperative work, especially seeking ways to provide better

software tools to support developers [6]. Indeed, they created several different tools, such as configuration management (CM) and bug tracking systems, to facilitate the coordination of groups of developers [14]. However, software development is especially difficult as a cooperative endeavor because of the several interdependencies that arise in any software development effort. To minimize these problems, current CM systems adopt design constructs (like workspaces and branches used in configuration management systems) to shield each individual from effects of other developers’ work [5]. These workspaces enforce a distinction between the private aspects of work developed by a software engineer and the public aspects that occur when this developer shares his work with other developers. Similar approaches have been taken in other categories of collaborative applications (e.g., collaborative writing and hypermedia systems), which have adopted this distinction between private and public work in order to facilitate collaboration. In these applications, this is usually done through the provision of separate private and public (or shared) workspaces. Private workspaces allow users to work in different parts of a document in parallel and contain information that only one user can see and edit allowing him to create drafts that later will be shared with the other co-workers [7]. On the other hand, public workspaces allow all users to share the same information or document and edit it concurrently.

When support for private and public work is provided, it is also necessary to support transitions between them. The central issue in systems maintaining separate workspaces is how information or activity moves between them, and similarly, the central mechanism around which CM systems are built is the mechanism for moving information between public and private conditions – checking in, checking out, merging. In cooperative working settings, people selectively choose when and how to disclosure their private work to others, i.e., they want to be able to control the emergence of public information [1, 26]. CM tools and collaborative authoring tools provide support for these transitions. In collaborative writing, for example, one can basically copy the content of a private workspace and paste into the public workspace. On the other hand, in CM systems, more sophisticated tools involving merging algorithms and concurrency control policies need to be used because of the aforementioned interdependencies in the software.

Transitions between private and public work (and vice-versa) are particularly important in cooperative work and can lead to problematic situations when overlooked. Indeed, Sellen and

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

GROUP’03, November 9–12, 2003, Sanibel Island, Florida, USA.

Copyright 2003 ACM 1-58113-693-5/03/0011…$5.00.

Harper [28] describe case studies of companies that had problems because they underestimated the delicacy of this transition. Despite that, insufficient analytical attention has been given to this transition by the CSCW community. In this paper, we will examine this issue with empirical material collected from a collaborative software development effort. The team observed uses mostly three tools for coordination purposes: a configuration management tool, a bug-tracking system, and e-mail. However, these tools alone were not sufficient to effectively support the team; participants needed to adopt a set of formal and informal work practices to properly support private, public work and transitions between them. The adoption of these different work practices suggests that the computational support provided by these systems to support the emergence of private information is still unsatisfactory. Based on these results, we draw more general conclusions about the implications for computer-supported cooperative work.

The rest of the paper is organized as follow. The next section discusses the idea of private and public work in computer-supported cooperative work. Then, sections 3 and 4 present the settings and the methods that we used to study the software development team. After that, Section 5 describes the set of work practices adopted by the team to properly deal with private, public work and transitions between them. Section 6 presents our discussion about the data that we collected. After that, Section 7 discusses implications of our findings in the design of CSCW tools. Finally, conclusions and ideas for future work are presented.

2. PRIVATE AND PUBLIC WORK In this paper we examine the distinction between private and public work in collaborative efforts. The need for this distinction is widely recognized in CSCW research. According to Ackerman [1], for example, people “(…) have very nuanced behavior concerning how and with whom they wish to share information (…) people are concerned about whether to release this piece of information to that person at this time (…)”. Another reason that makes people care about the release of information about them is that they “(…) are aware that making their work visible may also open them to criticism or management (…)” (ibid.). Furthermore, one does not make his entire work visible because he wants to appear competent in the eyes of colleagues and managers by making their work more complicated than necessary [26]. Indeed, people are not interested in all information that is provided to them. As Schmidt [26] points out:

“(…) in depending on the activities of others, we are ‘not interested’ in the enormous contingencies and infinitely faceted practices of colleagues unless they may impact our own work (…) An actor will thus routinely expect not to be exposed to the myriad detailed activities by means of which his or her colleagues deal with the contingencies they are facing in their effort to ensure that their individual contributions are seamlessly articulated with the other contributions.”

To summarize, people have several contextualized and different strategies to release their private information, and they expect that others will do the same, not overloading them with public information that is not ‘relevant’ to their current context or

activity. Note that this private information might be collaboratively constructed [16]. In this case, the information is public for those involved in its “construction”, but it is private to the other members of the cooperative effort.

CSCW researchers have already recognized the need to support these findings. Indeed, a typical approach to address that is to provide support for private and public (also called shared) windows, or workspaces, to support the collaboration among users [30]. Private workspaces allow users to work in different parts of a document in parallel and contain information that only one user can see and edit, allowing him to create drafts that later will be shared with the other co-workers [7]. On the other hand, public workspaces allow all users to share the same information or document so that, changes in the document are automatically visible to all users. The usage of these workspaces mimic conventions carried over non-technological work, where no one wants to search or look at anyone’s private desk or drawer, and conversely wants no one to search theirs, but accepts that when they occur in public spaces. Indeed, Mark and colleagues [21] report how conventions about the use of private and public workspaces implicitly evolved from conventions formed in face-to-face non-technological work after the introduction of a groupware tool.

Often, other mechanisms are present in collaborative systems to make other actions’ visible as well. For example, grey ‘clouds’ were proposed in the collaborative editor Grove to indicate where other co-writers are editing the text [9]. Furthermore, it is also well-known that, in some settings, making others’ work public facilitates the coordination of the activities [16] [17] and enables learning and greater efficiencies [20]. Examples of tools that explore such approaches include Portholes [8] and Babble [10].

The underlying distinction between private and public work also implies that in collaborative efforts transitions between these two aspects occur. However, while notions of “public” and “private” have been incorporated into software system design, insufficient analytical attention has been give to the transitions. Field studies such as those of Bowers [4] or Sellen and Harper [28] demonstrate that overlooking these transitions can be problematic. In Bower’s study, the disclosure of private data brought about dilemmas of ownership and responsibility among the employees of the organization studied. In Sellen and Harper’s study, when the companies tried to go paperless deploying a new information system, the employees’ ability to control when to disclosure information was lost and these employees boycotted the system. This happened because paper, as a medium on which work was performed, allowed their owners to avoid sharing information with their co-workers until they felt that the information was “ready”.

Note that the setting where the collaborative effort takes place is important. For example, in a control room, all workers are collocated, which allows them to use intonations in their voice and/or body language to make their actions visible to other co-workers [17]. On the other hand, Whittaker and Schwarz [34] report an ethnographic study where a large wallboard (containing the schedule of a software development project) is used by the team, which is spread along different cubicles and offices. The public location of this wallboard allowed developers to access

information about who was doing which tasks at which times, among other things. In other words, in this setting, information about others’ current actions was made public by checking and updating the schedule displayed in the wallboard.

In collaborative software engineering, this distinction between private and private work is not only desirable, but necessary and often enforced by tools. This occurs because of the several interdependencies that arise in any software development effort. In other words, each part of the software depends, directly or indirectly, on many other parts. Furthermore, these interdependencies are not strictly defined in the artifacts produced, and often are not even known by the developers. To handle this problem, software engineers created tools, such as configuration management (CM) and bug tracking systems, to facilitate the coordination of groups of developers [14]. Current CM systems adopt design constructs (like workspaces and branches) to shield the work of individuals from effects of other developers’ work [5]. Basically, these workspaces “create a barrier that prevents developers from knowing which other developers change which other artifacts” [25]. Therefore, CM workspaces allow software developers to work privately. Furthermore, CM systems provide mechanisms to support the transition from private to public work when developers want to make this transition. To be more specific, when a developer finishes his work in his private workspace, he can publicize his work to other software developers through check-in’s, check-out’s and merging operations. Despite this support, several problems arise in any software development effort. Indeed, based on empirical data that we collected, we identified a set of formal and informal work practices used by a team of software developers to handle these problems. The setting where the data was collected and the methods used to analyze this data are described in the following section.

3. THE SETTING The team studied is located at the NASA / Ames Research Center and develops a software application we will call MVP (not the real name), which is composed of ten different tools in approximately one million lines of C and C++. Each one of these tools uses a specific set of “processes.” A process for the MVP team is a program that runs with the appropriate run-time options and it is not formally related with the concept of processes in operating systems and/or distributed systems. Processes typically run on distributed Sun workstations and communicate using a TCP/IP socket protocol. Running a tool means running the processes required by this tool, with their appropriate run-time options.

Processes are also used to divide the work, i.e., each developer is assigned to one or more processes and tends to specialize on it. For example, there are process leaders and process developers, who, most of the time, work only with this process. This is an important aspect because it allows these developers to deeply understand the process behavior and familiarize with its structure, therefore helping them in dealing with the complexity of the code. During the development activity, managers tend to assign work according to these processes to facilitate this learning process. However, it is not unusual to find developers working in different processes. This might happen due to different circumstances. For

example, before launching a new release all workforce is needed to fix bugs in the code, therefore, developers might be assigned to fix these bugs.

3.1 The Software Development Team The software development team is divided into two groups: the verification and validation (V&V) staff and the developers. The developers are responsible for writing new code, for bug fixing, and adding new features. This group is composed of 25 members, three of whom are also researchers that write their own code to explore new ideas. The experience of these developers with software development range between 3 months to more than 25 years. Experience within the MVP group ranges anywhere between 2½ months to 9 years. This group is spread out into several offices across two floors in the same building.

V&V members are responsible for testing and reporting bugs identified in the MVP software, keeping a running version of the software for demonstration purposes and for maintaining the documentation (mainly user manuals) of the software. This group is composed of 6 members. Half of this group is located in the V & V Laboratory, while the rest is located in several offices located in the same floor and building as this laboratory. Both, the V&V Lab and developers’ offices are located in the same building.

3.2 The Software Development Process The MVP group adopts a formal software development process that prescribes the steps that need to be performed by the developers during their activities. For example, all developers, after finishing the implementation of a change, should integrate their code with the main baseline. In addition, each developer is responsible for testing its code to guarantee that when he integrates his changes, he will not insert bugs in the software, or, “break the code”, as informally characterized by the MVP developers. Another part of the process prescribes that, after checking-in files in the repository, a developer must send e-mail to the software development mailing list describing the problem report associated with the changes, the files that were changed, the branch where the check-in will be performed among other pieces of information.

The MVP software process also prescribes the usage of code reviews before the integration of any change, and design reviews for major changes in the software. Code reviews are performed by the manager of each process. Therefore, if a change involves, e.g. two processes, a developer’s code will be reviewed twice: one by each manager of these two processes. On the other hand, design reviews are recommended for changes that involve major reorganizations of the source code. Their need is decided by the software manager usually during the bi-weekly software developers meeting (called pre-design meetings).

3.3 Software Development Tools: CM and Bug tracking MVP developers employ two software development tools for coordinating their work: a configuration management system and a bug tracking system. Of course, other tools are used such as CASE tools, compilers, linkers, debuggers and source-code editors, but the CM and bug-tracking tools are the primary means

of coordination [5] [12] [14]. These tools are integrated so that there is a link between the PR’s (in the bug tracking system) and the respective changes in the source-code (in the CM tool). Both tools are provided by one of the leader vendors in the market.

A CM tool supports the management of source-code dependencies through its embedded building mechanisms that indicate which parts of the code need to be recompiled when one file is modified. To be more specific, CM tools support both compile-time dependencies, i.e., dependencies that occur when a sub-system is being compiled; and build-time dependencies that occur when several sub-systems or the entire system is being linked [12]. A bug tracking tool, when associated with the CM tool, supports the tracking of changes performed in the source code during the development effort.

It is important to mention that the MVP team employs several advanced features of the CM tool such as triggers, techniques to reduce compilation time, labeling and branching strategies. Indeed, the branching strategy employed is one of the most important aspects of a CM tool because it affects the work of any group of software developers. This strategy is a way of deciding when and why to branch, which makes the task of coordinating parallel changes easier or more difficult [33]. According to the nomenclature proposed by Walrad and Strom [33], the following branching strategies are used by the MVP team: (1) branch-by-purpose, where all bug fixes, enhancements and other changes in the code are implemented on separated branches; (2) branch-by-project, where branches are created for some of the development projects; and (3) branch-by-release, where the code branches upon a decision to release a new version of the product. The branch-by-purpose strategy is employed by MVP developers in their daily work, while the other strategies are only used by the CM manager. In other words, developers create new branches for each new bug fix or enhancement, while branches for projects and releases are created by the manager only. The branch-by-purpose strategy supports a high degree of parallel development but at the cost of more complex and frequent integration work [33]. According to this strategy, each developer is responsible for integrating his changes into the main code. This approach is often called “push integration” [2]. After that, the changes are available to all other developers. Therefore, if one bug is introduced, other developers will notice this problem because their work will be disrupted. Indeed, we observed and collected reports of different instances of this situation. When one developer suspects that there is a problem introduced by recent changes, he will contact the author of the changes asking him or her to check the change, or for more information about it.

4. METHODS The first author spent eight weeks during the summer of 2002 as a member of the MVP team. As a member of this team, he was able to make observations and collect information about several aspects of the team. He also talked with his colleagues to learn more about their work. Additional material was collected by reading manuals of the MVP tools, manuals of the software development tools used, formal documents (like the description of the software development process and the ISO 9001 procedures), training documentation for new developers, problem reports (PR’s), and so on.

All the members of the MVP team agreed with the author’s data collection. Furthermore, some of the team members agreed to let the intern shadow them for a few days so that he could learn about their functions and responsibilities better. These team members belonged to different groups and played diverse roles in the MVP team: the documentation expert, some V&V members, leaders, and developers. We sampled among MVP “processes”, developers’ experience in software development and with MVP tools (and processes) in order to get a broader overview of the work being performed at the site. A subset of MVP group was interviewed according to their availability. We again sampled them according to the dimensions explained above. Interviews lasted between 45 and 120 minutes. To summarize, the data collected consists in a set of notes that resulted from conversations, documents and observations based on shadowing developers. These notes have been analyzed using grounded theory techniques [31].

5. PRIVATE AND PUBLIC WORK IN SOFTWARE DEVELOPMENT As mentioned before, software development tools like configuration management systems support private, public work, and transitions between them. Despite using a CM system the MVP team faced several problems when dealing with these aspects. In this section, we present the formal and informal approaches adopted by this team in order to properly perform their work, i.e. develop software. In the sections that follow, we will explore these situations separately: private work, the transition from private to public, public work, and the transition from public to private.

5.1 Private Work Configuration management tools allow developers to work privately through the implementation of workspaces and branches [5]. These workspaces isolate the changes being created by one developer from other parts of the code. In this case, a developer’s ‘work-in-progress’ is not shared with other developers. Furthermore, these workspaces allow a developer to work without being affected by the changes of other developers. Indeed, when new changes are committed in the repository by other developers, the CM tool lets the user decide if he or she wants to grab these changes. In case one wants to incorporate the changes, he may recompile the software using the embedded building mechanisms on these tools. In case a developer does not want to incorporate the changes, one can continue working and, if necessary, recompile the software with the appropriate run-time options that do not grab these new changes. Of course, this is a risky course of action because it might lead the developer to work with an outdated version of the files, which might potentially make his work less ineffective.

Mechanisms embedded in CM tools are able to identify syntactic conflicts between the developer’s ‘work-in-progress’ and the changes committed into the repository, reporting whether or not the ‘work-in-progress’ is affected by these changes. However, because CM systems rely on syntactic features of the domain such as files, suffixes and lines of code, they can not identify semantic conflicts [11]. This means that except for these conflicts, current configuration management systems provide extensive and

automated support for maintaining the isolation between the work performed by one person from other’s work [5].

However, when software developers engage in parallel development, problems arise in the CM tool. Parallel development happens when more than one developer needs to make changes in the same file. This means that the same file is checked-out by different developers and all of them are making changes in the different copies of this file in their respective workspaces. As one might imagine, parallel development might lead to conflicts. They might occur when one developer checks-in his changed version of the file back in the repository, because the versions of the other developers will become outdated. In this case, the changes of these developers might become inappropriate because they are based on a code that is not the latest. To solve this problem, a developer needs to update his version of the file by merging the other developer’s changes into his code. The developers term this operation “back merging”; in CM terminology, it is named “synchronization of workspaces” or “import of the changes”. Conflicting changes are more likely to occur in files that are accessed by several developers at the same time. Indeed, in the MVP software some files are used to describe programming language structures that are used all over the code. This means that several different developers often change these files. In this case, “back merges” are problematic because CM tools face difficulties when they need to perform several merges at the same time. To overcome this problem not avoiding parallel development, MVP developers adopted a strategy to deal with these files: they perform “partial check-in’s”, which consist of checking-in some of the files back in the repository, even when the developers have not finished all their changes yet. This strategy reduces the number of “back merges” needed, therefore overcoming the limitations of CM tools. In addition, they minimize the likelihood of conflicting changes.

In addition to “partial check-in’s”, MVP developers adopt a different practice during their private work: they “speed-up” to finish some of their activities during the development process to avoid merging. This does not happen all the time though, it occurs only when MVP developers are testing their changes. This activity is performed right before the check-in operations. As one developer plainly pointed out: “This is a race!”. According to the software development process, this testing is necessary to guarantee that the changes will not introduce bugs into the system. We observed that, this testing is very informal: developers will sit on the V&V laboratory and compare the current version of MVP with the one with changes. MVP developers do not use more formal techniques, such as regression testing techniques, at this moment. These will be used by the V&V staff before creating a new release of the software.

In contrast, the bug tracking tool does not provide support for the private work of software developers. All the operations made in the problem reports managed by this tool are publicly accessible to all other software developers. For example, when a developer is assigned a bug, he needs to fill some information about the bug indicating how he will proceed to fix that bug. MVP developers usually write the information to be added to the bug tracking system outside the tool in a private file only accessible by themselves. Eventually, this information is added to the bug-tracking tool by the developer, which will automatically make it

available to all members of the MVP team. Furthermore, the tool does not avoid that two developers work on the same PR, as reported by one of the developers. Developers themselves have to deal with this problematic situation. The MVP group tries to avoid this problem through the software development process, which prescribes that the software manager is the one responsible for assigning PR to developers. Any assignment needs the approval of the manager. Organizational rules however interact with this process. According to these rules, the software manager can not assign work to the contractors working for the MVP group. This assignment has to be done to the manager of the contracting company, who will be responsible for assigning the work to the developers.

5.2 Moving from Private to Public Work In this section we discuss the work practices used by the MVP team to support the transition from private to public work, as well as how the software development tools used by the MVP team support this transition. This transition might occur in two situations: when a developer asks for code reviews, or informal comments, in his code; or when a developer commits his work (source-code changes) into the CM repository.

In the first case, MVP developers want to grant others access to their code, meaning that the work will be visible to them so that they can comment on it. In this case, MVP developers simply need to change a setting in their CM workspaces. Although their work is now public, it is not shared by the other developers, meaning that it will not impact other developers work.

In the second case, after a developer commits his work into the CM repository, this work is made public and shared meaning that it is visible and might impact the work of the other developers. In order to publicize his work, the author of the changes has to perform, at least, four different operations1:

1. Check-in the files that he wants to publish in his own branch;

2. Check-out the same set of files from the baseline; 3. Merge his changed files with the checked-out files

available in the baseline; and 4. Check-in the new files generated by the merging

operation into the baseline.

From the technical point of view, these tasks are not difficult since check-in’s, check-out’s and merges are typical operations in CM systems and, therefore, supported by nearly every tool in the market. This means that CM systems provide adequate support for these operations. However, this support is problematic when a developer is, or was, engaged in parallel development. As mentioned in the previous section, MVP developers adopt “partial check-in’s” to deal only with files with high levels of parallel development. Other files are not “partially checked-in”. In this case, if a developer is engaged in parallel development and other developers had checked-in the same files in the baseline before him, then he will need to perform “back merges” before merging 1 These operations might be different in other software

development teams since they depend on the branching strategy adopted by the team.

his code into the baseline. “Back merges” are supported by the CM tool through the presentation of version trees of the files being merged, which allows developers to identify the need for this task through the observation of the versions on this tree. After that, the operation is a simple merge. Again, the situation becomes problematic only if several “back merges” need to be performed.

During the transition from private to public, there is nothing that other developers need, or are able to do to facilitate this process. The work of performing the transition needs to be done by the author of the changes that will be publicized. However, because of the several inter-dependencies that exist among the several parts of the software (e.g., source-code, manuals, specifications, design documents, and so on), this does not mean that these developers will not be affected by the transition. Indeed, in order to minimize these effects, the developer who is going to perform the transition follows a set of formal and informal practices to facilitate the management of the interdependencies. These practices need to be adopted because the tool support to the developers affected by the private work being publicized is minimal. These formal and informal practices are described below.

The Software Development Process

As mentioned before, the software development process adopted by the MVP team prescribes the usage of code and design reviews. One of the reasons reported by the MVP developers for using these formal reviews is the possibility of evaluating the impact that the changes under review will have on the rest of the code. The most experienced software developer of the team, for example, reported that design reviews are used to guarantee that changes in the code do not “break the architecture” of the MVP software. By breaking the architecture, she means writing code that violates some of the design decisions embedded in the MVP software. Code reviews, on the other hand, are responsibility of process leaders, who can evaluate the impact that the changes will introduce in their processes before they were committed in the main repository. This helps each and every process leader to coordinate the work of other developers working in the same process.

E-mail Conventions

In addition to formal reviews, the MVP process prescribes that after checking-in code in the repository, a developer needs to send an e-mail about the new changes being introduced in the system to the software developers’ mailing list (see section 3.2). However, we found out that MVP developers send this e-mail before the check-in. Moreover, MVP developers add a brief description of the impact that their work (changes) will have on other’s work in this e-mail sent to the software developers’ mailing list. By adopting these practices, MVP developers allow their colleagues to prepare for and reflect about the effect of their changes. This is possible because all MVP developers are aware of some of the interdependencies in the source-code, but not all of them. As an example of this ‘preparation’, developers might send e-mail to the author of the changes asking him to delay their check-in, walk to the co-worker’s office to ask about these changes or, if the changes have already been committed, browse the CM and bug tracking systems to understand them. The following list presents some comments sent by MVP developers:

“No one should notice.” “[description of the change]: only EDP users will notice any change.” “Will be removing the following [x] files. No effect on recompiling.” “Also, if you recompile your views today you will need to start your own [z] daemon to run with live data.” “The changes only affect [y] mode so you shouldn't notice anything.” “If you are planning on recompiling your view this evening and running a MVP tool with live [z] data you will need to run your own [z] daemon.”

These e-mails are also important because they tell (or remind) developers that they have been engaged in parallel development. Often, developers do not know that this is happening2. The information in the e-mail is usually enough to tell the developer if he needs to incorporate these changes right away in order to continue his work, or if he can wait until he is ready for check-in. In both cases, the developer needs to “merge back” the latest changes into his version of the file.

Sending e-mail before a check-in is also used by other developers to support expertise identification, and as a learning mechanism. Developers associate the author of the e-mails describing the changes with the “process” where the changes are being performed. In other words, MVP developers assume that if one developer constantly and repeatedly performs check-ins in a specific process, it is very likely that he is an expert on that process. Therefore, if another developer needs help with that process he will look for him for help:

“[talking about a bug in a process that he is not expert] (…) I don’t understand why this behaves the way it does. But, most of these PR’s seem to have John’s name on it. So you go around to see John. So, by just by reading the headline of who does what, you kind of get the feeling of who’s working on what (…).So they [e-mails] tend to be helpful in that aspect as well. If you’ve been around for ten years, you don’t care, you already know that [who works with what], but if you’ve been here for two years that stuff can really make difference (…)”

On the other hand, the fact that developers read e-mails sent by other developers to assess the impact of others’ changes in their code contributes to their learning experience within MVP. Note that developers who reported the aspects described in this section had little experience working at MVP: the first with 2 years and the second with 2 ½ months.

Problem Reports

The problem reports (PRs) of the bug-tracking tool are used by different members of the MVP team who play diverse roles in the software development process. Basically, when a bug is

2 Differently than the developers reported by Grinter [14], before

checking-out a file, they do not check the version tree that displays information about other developers working on the same file.

identified, it is associated with a specific PR. The tester who identified the problem is also responsible for filling in the PR the information about ‘how to repeat’ it. This description is then used by the developer assigned to fix the bug to learn and repeat the circumstances (adaptation data, tools and their parameters) under which the bug appears. In other words, the information provided by the tester is then used by the MVP developer to locate, and eventually fix the bug. After fixing the bug, this developer must fill a field in the PR that describes how the testing should be performed to properly validate the fix. This field is called ‘how to test’. This information is used by the test manager, who creates test matrices that will be later used by the testers during the regression testing. The developer who fixes the bug also indicates in another field of the PR if the documentation of the tool needs to be updated. Then, the documentation expert uses this information to find out if the manuals need to be updated based on the changes the PR introduced. Finally, another field in the PR conveys what needs to be checked by the manager when closing it. Therefore, it is a reminder to the software manager of the aspects that need to be validated.

In other words, PR’s provide information that is useful for different members of the MVP team according to the roles they are playing. They facilitate the management of interdependencies because they provide information to MVP developers that help them in understanding how their work is going to be impacted by the changes that are going to be checked-in the repository.

Holding check-in’s

As mentioned earlier, MVP developers add a brief description of the impact of their changes to the e-mail sent to the developers before checking-in any code. Two types of impact statements are used more often than others: changes in run-time parameters of a process, and the need to recompile parts or the whole source code. The former case is important because other developers might be running the process that will be changed with the check-in. The latter case is used because when a file is modified, it will be recompiled, as well as, the other files that depend on it and this recompilation process is time-consuming, up to 30 to 45 minutes. Developers are aware of the delay that they might cause to others. Therefore, they hold check-in’s until the evening to minimize the disturbance that they will cause. According to one of the developers:

“(…) people also know that if they are going to check-in a file, they will do in the late afternoon … You’re gonna do a check-in and this is gonna cause anybody who recompiles that day have to watch their computer for 45 minutes (…) and most of the time, you’re gonna see this coming at 2 or 3 in the afternoon, you don’t see folks (….) you don’t see people doing [file 1] or [file 2] checking-in at 8 in the morning, because everybody all day is gonna sit and recompile.”

The transition from private work, then, is recognized as a point at which the work of a single developer can impact the work of others. Developers’ orientation is not simply towards the artifacts but towards the work of the group. The subtlety with which the transition is managed reflects this consideration.

5.3 Public Work The work of one developer becomes public when it is visible to all other co-workers. This happens in two different circumstances: when a developer changes the settings of his workspaces to grant others access to his code and after a developer commits his changes into the repository of the CM tool. These situations raise the question of how the MVP developers handle the new public work (changes)?

In the former case, the work is public but not shared, which means that it is not going to affect other developers’ work. Therefore, MVP developers do not need to take any step in order to handle the public work, because it will not affect them. However, in the second case, MVP developers might need to adapt their work based on these changes. Indeed, MVP developers might need to recompile their changes (work) in case they choose to incorporate the new public work or they might need to change the run-time parameters of a process that was altered by the changes. Based on our data, we found out that the configuration management tool provides some help to MVP developers handle this situation. As mentioned before, these tools have building mechanisms that help MVP developers, upon request, to incorporate the new changes and identify syntactic conflicts between the developer’s ‘work-in-progress’ and the new changes. However, these tools are not able to detect semantic conflicts since they are purposely created to be independent of programming languages [11].

The bug tracking tool, on the other hand, provides support for public work because all the operations performed in the problem reports are automatically visible to all MVP developers. In addition, this tool implements some accounting features that record the history of a PR including all operations performed on each one of them.

5.4 Moving from Public to Private Work, or “Breaking the code” According to Walrad and Strom [33], the branch-by-purpose strategy adopted by the MVP team (see section 3.3) assures continual integration of the code, therefore minimizing problems. However, this strategy needs to be complemented by some form of notification that informs all developers that a check-in happened (and therefore that some integration took place). As mentioned before, this is achieved in the MVP team through the e-mail notification sent before the check-in’s. Therefore, whenever a new change is introduced in the repository, all developers are notified about it. This affords an easy detection of problems caused by the introduced changes. In other words, if a change introduces a bug in the software, other developers might be able to detect it because: (i) they are aware that a change was introduced in the code by another developer; and (ii) they usually integrate the new introduced changes in their own work. If any abnormal behavior is identified in the software after a check-in, whoever identified that will contact the author of the check-in to verify if the problem is happening because of the check-in. If that is the case, the software is called “broken” and the code that was checked-in must be removed from the repository, corrected, and checked-in again later. In other words, the publicly available work needs to be made private again. The CM tool supports this transition because

it provides rollback facilities that allow one to remove committed changes from the repository.

6. DISCUSSION The notions of private and public work and workspaces are well known ones in the design of collaborative systems. However, our empirical observations draw attention to the complex set of practices that surround the transition between public and private. Private information has public consequences, and vice versa.

The different formal and informal work practices arise in the MVP team, especially, because of the interdependencies among the different artifacts created during the software development process. Indeed, these interdependencies make the process of publicizing work so important. A developer can not simply carelessly publicize his work, because this will cause a large impact in other developers’ work: some of them will need to go through their testing again, others will spend a lot of time recompiling their changes, others can need to change their own code in order to adapt the new checked-in code, and so on.

Since the MVP developers are aware of some of these interdependencies, they explicitly work to minimize problems that emerge in the relationship between their different working needs. Artifacts such as problem reports facilitate the management of interdependencies of developers from the different groups and with different roles. Problem reports are “boundary objects” in the sense of Star and Griesemer [29]; objects whose common identity is robust enough to support coordination, but whose internal structure, meaning, and consequences emerge from local negotiations between groups. Viewing PR’s as boundary objects draws attention to their role in managing loosely-coupled coordination, and how each developer is able to interpret the information in the PR’s that is useful to their current work. Critically, this is achieved without changing the identity of each PR along the whole software development process. Indeed, each PR keeps the same unique identifier.

Interestingly, these formal and informal work practices require that the author of the changes performs most of the additional work. However, this author will not get any benefit from that. Indeed, sending e-mail notifications, holding check-in’s, and filling the appropriate PR’s fields during the implementation are all operations performed by the author of the changes and none of them facilitate or improve his work. There is one developer performing the extra-work who does not gain any benefit of this extra work, and fifteen other developers who benefit from his work3. That is exactly one of the situations that lead groupware applications to fail [15]. In this particular software development team though, this does not happen. MVP developers are aware of the extra-work that they need to perform, but they are also aware that this same extra-work is going to be performed by the other developers when necessary, and this is going to help each and every one of them in performing their tasks.

On the other hand, MVP developers also adopt informal practices during their private work. The first one, called “partial check-

3 The MVP group is composed of 16 developers. One of them is

performing the check-in; therefore 15 others are being helped by the extra-work.

in’s”, is especially important because it is used to handle files with a high degree of parallel development and changes in these files positively correlate with the number of defects [23]. “Partial check-in’s” are variations of the formal software development process, which establishes that check-ins only will be performed when the entire work is done. They are necessary because of the software development tools adopted are unable to properly handle merging in these files. This is the same reason, according to Grinter [14], that led other team of software developers to either avoid parallel development or rush to finish their work. On the other hand, MVP developers rush because they do not want to repeat their testing when another developer checks-in some code into the repository. In both studies, developers describe their dilemma: they want to produce high-quality code, but they also want to finish fast their changes.

Holding onto check-in’s is another informal approach adopted by the MVP developers during their private work. It is adopted because they are aware of some of the existing interdependencies in the software and they want to minimize the impact that their changes will cause on others’ work. To be more specific, they understand that some changes cause a lot of recompilation, which might lead other developers to spend time “watching” the recompilation.

All this extra-work performed by the different members of the MVP team is another form of articulation work [27] that occurs in cooperative software development. It is different from the recomposition work [13], which is the coordination required to assemble software development artifacts from their parts. Recomposition work focuses on choosing the right components to create a software artifact due to source-code dependencies, while this extra work that we report focuses on the management of all interdependencies that exist in a software development effort.

After any code is checked-in into the CM repository, the other MVP developers are able to detect problems, or, detect if the MVP software is “broken”. As noted in other settings such as ship bridges [19] or aircraft cockpits [20], this can be achieved because work artifacts and activities are visible to all. By creating a public space, the CM repository supports collective error detection and correction.

7. IMPLICATIONS FOR TOOLS Software engineers have been developing tools to help co-workers in analyzing the impact of others’ work in their own work. In this case, the support is provided to the developers after the transition from private to public work has been made. This approach, called change impact analysis [3], uses several techniques. One example is dependency graph approaches, which focus on determining the impact of the changed code (product) in other’s part of the source code. These approaches are usually based on program dependences, which are syntactic relationships between the statements of a program representing aspects of the program’s control flow and data flow [24]. In other words, they focus only in determining the impact of the changes in the product in the rest of the cooperative effort. Although powerful, these techniques are also computationally expensive and very time-consuming to be used by developers in their daily work. Consequently, they do not completely support the transition from private to public work, and as we’ve seen, this is a very subtle step in cooperative software

development. Although these techniques have their limitations, they are evidence that the dependencies between developers' working activities are a cause for concern and attention. We argue that other cooperative efforts, especially those with several interdependencies, could greatly benefit from such approaches, if they were arranged to support the emergence of public information.

Recent approaches in software engineering attempt to provide useful information to developers so that they can better coordinate. In other words, these approaches try to increase the awareness [7] of software engineers about the work of their colleagues. They differ, however, on the type of information that is provided. A first approach is based on the idea of facilitating the dissemination of public information by collocating software developers in warrooms [32]. In this case, companies expect to achieve the same advantages that the public availability of others’ actions has brought to other settings such as ship bridges [19], aircraft cockpits [20], transportation control rooms [17] and city dealing rooms [16]. Indeed, early results of this approach have been encouraging [32]. However, there are practical limitations in the size of the teams that can be collocated, which suggests that tool support is still necessary. Indeed, new tools like Palantir [25] and Night Watch [22] adopt a different approach that focuses on constantly publicizing information(like CM commands) collected from a CM workspace to other workspaces that are accessing the same files. In this case, instead of focusing in the transition between private and public aspects of work, these tools basically eliminate the private work by making all aspects of the work publicly available to others. However, as discussed in section 2, the need for privacy and for controlling the release of private information is an important aspect in any social setting; which therefore needs to be addressed in the design of cooperative tools.

Finally, our data suggests that a software developer might use different sources of information at different times in order to assess the current status of the work. As mentioned before, the MVP team uses information from e-mail messages, the configuration management tool and the bug tracking system. By reading e-mail, MVP developers are aware of future changes in the CM tool because somebody else is going to check-in something. By inspecting only the CM tool, a developer can be aware of partial check-ins in the repository that are not reported by e-mail. And finally, the bug-tracking tool, through its PR’s, provides information about how a developer’s work is going to be impacted by the problem report associated with the check-in. These are three different tools that a MVP developer has to use. We believe that a possible improvement is to use event mechanisms (such as event-notification servers) to integrate these different sources of information, and then provide a unique interface and tool to assess the relevant information. Furthermore, abstraction techniques [18] could be employed to generate high-level information (e.g., status of the work) from low-level information like recent check-ins and check-outs, e-mails exchanged among software developers, information added to the bug-tracking tool, etc. This is an interesting research area that we plan to explore.

8. CONCLUSIONS AND FUTURE WORK This paper examined the transitions between private and public work based on empirical material collected from a large-scale software development effort. The team studied, called MVP, uses mostly three tools to coordinate their work: a configuration management (CM) tool, a bug-tracking system, and e-mail. These tools provide support for private and public work, as well as some technical support that facilitates the transition from the former aspect to the latter. However, MVP developers also adopted a set of formal and informal work practices to manage this transition. These transitions are necessary to facilitate the management of the interdependencies among the different software artifacts. The following practices were identified and described in the paper: partial check-in’s, holding onto check-in’s, problems reports crossing team boundaries, code and design reviews, “speeding-up” the process, and finally, the convention of adding the description of the impact of the changes in the e-mail sent to the group. These practices suggest that analytical attention needs to be given to these transitions in order to enhance our understanding of cooperative work. Furthermore, computational support also needs to be provided so that this task can occur properly.

We plan to study other software development teams in order to understand how they deal with the aforementioned transition and their work practices to perform that. By doing that, we expect to learn important characteristics that can help us in understand other cooperative efforts.

9. ACKNOWLEDGMENTS The authors thank CAPES (grant BEX 1312/99-5) and NASA/Ames for the financial support. Effort sponsored by the Defense Advanced Research Projects Agency (DARPA) and Air Force Research Laboratory, Air Force Materiel Command, USAF, under agreement number F30602-00-2-0599. Funding also provided by the National Science Foundation under grant numbers CCR-0205724, 9624846, IIS-0133749 and IIS-0205724. The U.S. Government is authorized to reproduce and distribute reprints for governmental purposes notwithstanding any copyright annotation thereon. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Defense Advanced Research Projects Agency (DARPA), the Air Force Laboratory, or the U.S. Government.

10. REFERENCES [1] Ackerman, M. S., "The Intellectual Challenge of CSCW:

The Gap Between Social Requirements and Technical Feasibility," Human-Computer Interaction, vol. 15, pp. 179-204, 2000.

[2] Appleton, B., Berczuk, S., et al., "Streamed Lines: Branching Patterns for Parallel Software Development," vol. 2002, 1998.

[3] Arnold, R. S. and Bohner, S. A., "Impact Analysis - Towards a Framework for Comparison," International Conference on Software Maintenance, pp. 292-301, Montréal, Quebec, CA, 1993.

[4] Bowers, J., "The Work to Make the Network Work: Studying CSCW in Action," Conference on Computer-Supported Cooperative Work, pp. 287-298, Chapel Hill, NC, USA, 1994.

[5] Conradi, R. and Westfechtel, B., "Version Models for Software Configuration Management," ACM Computing Surveys, vol. 30, pp. 232-282, 1998.

[6] Curtis, B., Krasner, H., et al., "A field study of the software design process for large systems," Communications of the ACM, vol. 31, pp. 1268-1287, 1988.

[7] Dourish, P. and Bellotti, V., "Awareness and Coordination in Shared Workspaces," Conference on Computer-Supported Cooperative Work (CSCW '92), pp. 107-14, Toronto, Ontario, Canada, 1992.

[8] Dourish, P. and Bly, S., "Portholes: Supporting Distributed Awareness in a Collaborative Work Group," ACM Conference on Human Factors in Computing Systems (CHI '92), Monterey, CA, 1992.

[9] Ellis, C. A., Gibbs, S. J., et al., "Groupware: Some issues and experiences," Communications of the ACM, vol. 34, pp. 38-58, 1991.

[10] Erickson, T. and Kellogg, W. A., "Social Translucence: An Approach to Designing Systems that Support Social Processes," Transactions on HCI, vol. 7, pp. 59-83, 2000.

[11] Estublier, J., "Software Configuration Management: A Roadmap," Future of Software Engineering, pp. 279-289, Limerick, Ireland, 2001.

[12] Grinter, R., "Supporting Articulation Work Using Configuration Management Systems," Computer Supported Cooperative Work, vol. 5, pp. 447-465, 1996.

[13] Grinter, R. E., "Recomposition: Putting It All Back Together Again," Conference on Computer Supported Cooperative Work (CSCW'98), pp. 393-402, Seattle, WA, USA, 1998.

[14] Grinter, R. E., "Using a Configuration Management Tool to Coordinate Software Development," Conference on Organizational Computing Systems, pp. 168-177, Milpitas, CA, 1995.

[15] Grudin, J., "Why CSCW applications fail: Problems in the design and evaluation of organizational interfaces," ACM Conference on Computer-Supported Cooperative Work, pp. 85-93, Portland, Oregon, United States, 1988.

[16] Heath, C., Jirotka, M., et al., "Unpacking Collaboration: the Interactional Organisation of Trading in a City Dealing Room," Third European Conference on Computer-Supported Cooperative Work, pp. 155-170, Milan, Italy, 1993.

[17] Heath, C. and Luff, P., "Collaboration and Control: Crisis Management and Multimedia Technology in London Underground Control Rooms," Computer Supported Cooperative Work, vol. 1, pp. 69-94, 1992.

[18] Hilbert, D. and Redmiles, D., "An Approach to Large-scale Collection of Application Usage Data over the Internet," 20th International Conference on Software Engineering (ICSE '98), pp. 136-45, Kyoto, Japan, 1998.

[19] Hutchins, E., Cognition in the Wild. Cambridge, MA: The MIT Press, 1995.

[20] Hutchins, E., "How a Cockpit Remembers its Speeds," Cognitive Science, vol. 19, pp. 265-288, 1995.

[21] Mark, G., Fuchs, L., et al., "Supporting Groupware Conventions through Contextual Awareness," European Conference on Computer-Supported Cooperative Work (ECSCW '97), pp. 253-268, Lancaster, England, 1997.

[22] O'Reilly, C., Morrow, P., et al., "Improving Conflict Detection in Optimistic Concurrency Control Models," 11th International Workshop on Software Configuration Management (SCM-11), Portland, Oregon, 2003 (to appear).

[23] Perry, D. E., and, H. P. S., et al., "Parallel Changes in Large-Scale Software Development: An Observational Case Study," ACM Transactions on Software Engineering and Methodology, vol. 10, pp. 308-337, 2001.

[24] Podgurski, A. and Clarke, L. A., "The Implications of Program Dependencies for Software Testing, Debugging, and Maintenance," Symposium on Software Testing, Analysis, and Verification, pp. 168-178, 1989.

[25] Sarma, A., Noroozi, Z., et al., "Palantír: Raising Awareness among Configuration Management Workspaces," Twenty-fifth International Conference on Software Engineering, pp. 444-453, Portland, Oregon, 2003.

[26] Schmidt, K., "The critical role of workplace studies in CSCW," in Workplace Studies : Recovering Work Practice and Informing System Design, P. Luff, J. Hindmarsh, and C. Heath, Eds.: Cambridge University Press, 2000, pp. 141-149.

[27] Schmidt, K. and Bannon, L., "Taking CSCW Seriously: Supporting Articulation Work," Journal of Computer Supported Cooperative Work, vol. 1, pp. 7-40, 1992.

[28] Sellen, A. J. and Harper, R. H. R., The Myth of the Paperless Office. Cambridge, Massachusetts: The Mit Press, 2002.

[29] Star, S. L. and Griesemer, J. R., "Institutional Ecology, Translations and Boundary Objects: Amateurs and Professionals in Berkeley's Museum of Vertebrate Zoology.," Social Studies of Science, vol. 19, pp. 387-420, 1989.

[30] Stefik, M., Foster, G., et al., "Beyond the Chalkboard: Computer Support for Collaboration and Problem Solving in Meetings," Communications of the ACM, vol. 30, pp. 32-47, 1987.

[31] Strauss, A. and Corbin, J., Basics of Qualitative Research: Techniques and Procedures for Developing Grounded Theory, Second. ed. Thousand Oaks: SAGE publications, 1998.

[32] Teasley, S., Covi, L., et al., "How Does Radical Collocation Help a Team Succeed?," Conference on Computer Supported Cooperative Work, pp. 339-346, Philadelphia, PA, USA, 2000.

[33] Walrad, C. and Strom, D., "The Importance of Branching Models in SCM," IEEE Computer, vol. 35, pp. 31-38, 2002.

[34] Whittaker, S. and Schwarz, H., "Meetings of the Board: The Impact of Scheduling Medium on Long Term Group Coordination in Software Development," Computer Supported Cooperative Work, vol. 8, pp. 175-205, 1999.