Collaborative Software Design & Development. *Collaboration*

Collaborative Software Design &

Development

*Collaboration*

Dewayne E Perry

ENS 623A

Office Hours: T/Th

10:00-11:00

perry @ ece.utexas.edu

www.ece.utexas.edu/~perry/education/382V-s08/

Environment Support

Â

Model of software development environments

ª

SDE model = { policies, mechanisms, structures }

Â

Policies

ª

Requirements imposed on the user of an environment

¾ Eg, static linker/loaders require all externally referenced

names to be resolved before successful linking

ª

Need not be hardwired

¾ Eg, in Darwin (Minsky’s law-governed system), policies are

defined by declarative rules

¾ Eg, Osterweil’s process programming enables explicit

programming of the desired policies

ª

Supported

vs

enforced

policies

¾ Supported: provides means of satisfying the policy ¾ Directly enforced: no other way to do it

¾ Indirectly enforced: environment supported, management

Â

Structures

ª

Objects or object aggregates that mechanisms operate

¾ Eg, files in Unix – basic ubiquitous structure

¾ Eg, abstract syntax trees in integrated environments

9Problem – difficulty integrating new tools if use different structure

9Partial solution: Garlan’s mechanism for generating a common underlying

structure for integrated tools

ª

The more sophisticated and plentiful the objects,

¾ The more comprehensive the mechanisms ¾ The richer the possible set of policies

¾ Eg, an object base (and extension of a database) ¾ Eg, Inscape’s semantic interconnection structure

ª

Structures impose limitations on the kinds of policies

¾ Eg, Infuse enables richer policies regarding interaction and

Environment Support

Â

Mechanisms

ª

The languages, tools and tool fragments

ª

Implement with structures the supported and enforced

policies

ª

Some visible, some hidden

¾ Unix – all available

¾ Smile – hidden beneath a facade that provides higher level

mechanisms

ª

Policies can be encoded explicitly or implicitly

¾ Explicit - Darwin and Marvel’s rules

Â

4 classes of SDEs

ª

Individual

ª

Family

ª

City

ª

State

Individual:

ª

Primary issue: construction

ª

Mechanisms dominate

ª

Examples:

¾ Tool-kit environments (eg, Unix)

¾ Interpretive environments (eg, Interlisp)

¾ Language-oriented environments (eg, Cornell synthesizer) ¾ Transformational environments (eg, Refine)

Environment Support

Family:

ª

Primary issue: coordination

¾ Generally laissez faire – ie, loose coordination

9On a farm, can do pretty much want you want with respect to vehicles

and driving rules

ª

Structures dominate

ª

Examples

¾ Extended toolkit environments (eg, Unix with SCCS} ¾ Integrated environments (eg, Gandalf Prototype)

¾ Distributed environments (eg, DSEE [now ClearCase]) ¾ Project management environments

Â

City:

{…, cooperation policies},

{…, cooperation mechanisms}, {…, structures for cooperation} )

ª

Primary issue: cooperation

¾ Often much more enforcement involved

ª

Policies dominate

ª

Examples

¾ Infuse – enforced cooperation

Environment Support

State:

ª

Primary issue: commonality

¾ Enables cross project movement ¾ Reduces new project training

ª

Higher-order policies dominate

ª

Examples

Â

Contributions of the model

ª

Distinguishes those aspects of an environment useful in

evaluating SDEs

ª

The taxonomy delineates 4 important classes of interactions

ª

Individual and family models are [still] the current state of

the art

ª

City models provide qualitative differences

Tool Supported Collaboration

Â

Codified by Fagan – 1976 – peer review of code

ª

Fresh look with no/few assumptions

ª

Less expensive to detect fault when inserted

ª

Versus cost of testing, isolating, repair and retest

Â

Code inspection process

ª

Generate inspection package

ª

Individual preparation

ª

Team analysis – fault collection

ª

Repair

ª

Follow up

Â

Factors in code inspections

ª

Structures – how steps are organized into a process

ª

Techniques – how each step is carried out

ª

Inputs – reviewer ability, code quality

ª

Context – interactions, project schedule, personal calendars

Â

Code inspections in geographically separated projects

ª

Time-zone mismatches

ª

Travel for inspection meetings – expensive

ª

Long distance mailing of inspection packages

Â

These factors affect project interval

Possible solutions

ª

Tele-conferencing

¾ 2 hours on the speakerphone: mind-numbing

ª

Video conferencing

ª

Groupware

Â

Unknown factors

ª

Affect on effectiveness

Technology Pull instead of Push

Â

Our tool development approach

ª

Select improvement criteria

¾ Often reducing cost and increasing quality ¾ Ours: reducing interval

ª

Model the cost-benefit drivers of the process

¾ Need theories that are

9General

9Causal

9Suggestive of control strategies

¾ Theories Æ factors Æ manipulation

ª

Understand current process and identify key problems

¾ Enables prioritization

ª

Explore and evaluate alternative improvements

¾ Empirical studies key

¾ Key issues, risks and costs

Â

Process structure

ª

Team size key factor

¾ Coordination of multiple teams requires time ¾ Some changes had adverse effect on interval ¾ Overall, little effect on interval

Â

Process inputs

ª

Code size explained 50% of variation

ª

But little effect on interval

Â

Techniques – with, without meetings

ª

Traditionally more faults found in meetings

ª

Experiment: meetingless more effective

ª

When effort for meeting applied to individual analysis, more

Potential Drivers

Â

Techniques – defect detection methods

ª

Scenarios:

¾ higher detection rate

¾ more effective for what scenario covered ¾ No less effective

ª

Checklist no more effective than ad hoc

Â

Process environment

ª

Influences choices of developers

ª

Hence, does influence interval

¾ Tasks have priorities

¾ Under heavy load, low priority tasks deferred ¾ Lengthened interval

Â

Process Overhead

ª

Creating and distributing inspection documents

¾ Particularly a problem in geographically distributed projects

ª

Inspection data used by other processes

¾ Defects must be collected, processed and managed

9Eg change management – to ensure all defects fixed

9Entered, fixed, closed and signed off

Â

Blocking due to synchronization and sequencing

ª

Blocking can lengthen interval

ª

General problem

¾ Many tasks sequentially ordered ¾ Some tasks must by synchronized

9Eg, group meetings

Solution Space

Â

Possible ways of reducing interval

ª

Eliminate paper generation

ª

Eliminate inspection meeting

ª

Share preparation results

ª

Overlap preparation and repair

Â

Justification

ª

Opportunistic study

¾ Desk vs meeting inspections

¾ No difference in average fault density

ª

Argument for sharing results

¾ sharing would be no worse than keeping them private ¾ Useful process gains in sharing

ª

Overlapping inspection and repair

¾ Problems: premature repair and consistency ¾ Given risks, decided not to do this

Experience and Evaluation

Â

Initial acceptance was excellent

ª

Cost savings

ª

hypeCode integrated seamlessly into the existing environment

ª

New possibilities for concurrency and inherent speedups

ª

Web a natural and ubiquitous platform

Â

Anecdotal evidence interviewing users

ª

10-25% reduction in total inspection interval

ª

Eliminates time spent in reproduction and distribution

ª

Improves effectiveness and reduces time spent

¾ Can see others comments

ª

Primary work product of meetings a by-product here

¾ Eliminates about a day needed to prepare the meeting report

ª

Inspection report improved

¾ More low, medium and observation category defects ¾ No fewer severe category defects

¾ Defect descriptions more detailed and complete ¾ Recorded discussions of defects

ª

Need for collection meeting often eliminated

¾ Reduces interval eliminating delay for meeting ¾ When there is a meeting, very focused

¾ Quality often higher – more focused on a few unresolved issues ¾ Meeting significantly shorter, and less lapse time to meeting

9Average about a half hour

Â

Overall a run away success – lost control of it

Â

Used on at least a dozen projects in half a dozen

countries