Parallel Changes in Large-Scale Software Development: An Observational Case Study ACM Transactions...

Post on 28-Mar-2015

213 views 0 download

Tags:

Transcript of Parallel Changes in Large-Scale Software Development: An Observational Case Study ACM Transactions...

Parallel Changes in Large-Scale Parallel Changes in Large-Scale Software Development: An Software Development: An Observational Case StudyObservational Case Study

ACM Transactions on Software Engineering and Methodology, Vol. 10, No. 3,

July 2001, Pages 308 – 337

Michelle ThomsonAgnieszka Jankowska

Shiona Webster

Authors StrategyAuthors Strategy

The authors strategy for understanding the The authors strategy for understanding the problem of parallel changes was to look at problem of parallel changes was to look at the problem from a number of different the problem from a number of different angles and viewpoints in the context of a angles and viewpoints in the context of a large-scale, real-time system and a large-large-scale, real-time system and a large-scale development.scale development.

CharacteristicsCharacteristics

An essential characteristic of large-scale An essential characteristic of large-scale software development is parallel software development is parallel development by a team of developersdevelopment by a team of developers

How this development is structured and How this development is structured and supported has a profound effect on both the supported has a profound effect on both the quality and timeliness of the productquality and timeliness of the product

Why parallel developmentWhy parallel development

Release preparation Release preparation Post-release maintenance (segregated from Post-release maintenance (segregated from

new development)new development) Tailored or customer-specific softwareTailored or customer-specific software Segregation of work by different Segregation of work by different

development teams or individualsdevelopment teams or individuals Segregation of work on different features Segregation of work on different features Deployment of different software variants Deployment of different software variants

into different environmentsinto different environments

IssuesIssues

Four essential problems in software Four essential problems in software development: development:

1) evolution1) evolution 2) scale 2) scale 3) multiple dimensions of system 3) multiple dimensions of system

organisation organisation 4) distribution of knowledge.4) distribution of knowledge.

EvolutionEvolution

Evolution compounds the problems of Evolution compounds the problems of parallel development because not only is parallel development because not only is there parallel development within each there parallel development within each version, but also among the releases as wellversion, but also among the releases as well

ScaleScale

Scale compounds the problems by increasing Scale compounds the problems by increasing the degree of parallel development and the degree of parallel development and therefore increasing both the interactions therefore increasing both the interactions and interdependencies among the and interdependencies among the developersdevelopers

Multiple dimensions of system Multiple dimensions of system organisationorganisation

Multiple dimensions of system organisation Multiple dimensions of system organisation compounds the problems by preventing tidy compounds the problems by preventing tidy separations of development into independent separations of development into independent work unitswork units

By System organisation, we are looking at By System organisation, we are looking at hardware and software which make up the hardware and software which make up the product and not the developers organisationproduct and not the developers organisation

Distribution of KnowledgeDistribution of Knowledge

Distribution of knowledge compounds the Distribution of knowledge compounds the problem by decreasing the degree of problem by decreasing the degree of awareness that is distributedawareness that is distributed

File checkin/checkout, branching File checkin/checkout, branching and mergingand merging

Serial development using exclusive Serial development using exclusive checkoutscheckouts

BranchingBranching

MergingMerging

Management of Parallel ChangesManagement of Parallel Changes

One of the standard features that enables One of the standard features that enables developers to create parallel versions of the developers to create parallel versions of the code is the branching mechanismcode is the branching mechanism

Every time a developer needs to create a Every time a developer needs to create a new version of the code, they request the new version of the code, they request the configuration management system (CMS) to configuration management system (CMS) to create a new branchcreate a new branch

The different versions of the code are then all The different versions of the code are then all stored in the same physical filestored in the same physical file

Benefit of CMS in parallel Benefit of CMS in parallel developmentdevelopment

Classic vs. Modern Configuration Classic vs. Modern Configuration Management SystemsManagement Systems

In the classic configuration management In the classic configuration management system the merging process has to be done system the merging process has to be done manually. There are no mechanisms to manually. There are no mechanisms to collapse branches back togethercollapse branches back together

Modern configuration system provide Modern configuration system provide mechanisms for automatically merging mechanisms for automatically merging several versions back togetherseveral versions back together

http://www.timefold.com/snapsite/timefold/public/html/page41.html#q8

http://www.ibm.com/software/rational

About ClearCase:About ClearCase:

A Software Configuration A Software Configuration Management System Management System (SCMS) originally from(SCMS) originally fromRational SoftwareRational Software

(now IBM/Rational) (now IBM/Rational)

Levels of parallel developmentLevels of parallel development

5ESS was maintained as a series of releases 5ESS was maintained as a series of releases each offering new features on top of existing each offering new features on top of existing onesones

Releases were being build in parallel with Releases were being build in parallel with varying amount of overlapping developmentvarying amount of overlapping development

Features were being developed in parallel Features were being developed in parallel (both with a simple release and multiple (both with a simple release and multiple releases)releases)* - Wikipidia.http://en.wikipedia.org/wiki/5ESS_switch

The 5ESS change management The 5ESS change management processprocess

Two layer approach

ECMS

IMR

MR SCCS

Change management layer

Configuration management layer

Deltas

Process of implementing an MR Process of implementing an MR

Make private copy of fileMake private copy of file Try out changeTry out change Retrieve original from SCCS – lock for editingRetrieve original from SCCS – lock for editing Makes changes [deltas] in the SCCS – release Makes changes [deltas] in the SCCS – release

lockslocks Retrieve amended files again from SCCS for Retrieve amended files again from SCCS for

readingreading Put code through inspection & testingPut code through inspection & testing Submitted back for load integrationSubmitted back for load integration MR closed when changes made and approvedMR closed when changes made and approved IMR is closedIMR is closed

IMR vs. MR activityIMR vs. MR activity

Lucent Technologies subsystem: Lucent Technologies subsystem: 5ESS5ESS

Facts: Case study data found that:

The higher degree of parallelism the higher The higher degree of parallelism the higher the number of defects!the number of defects!

12.5% of all deltas are made to the same file by different developers within the same 24h period

Across the subsystems, 3% of the deltas made within 24h by different developers physically overlap each other’s changes.

Case study observationsCase study observations

The parallel development plays a vital role in The parallel development plays a vital role in large-scale software developmentlarge-scale software development

As study showed that the current tools As study showed that the current tools (2001) available for the level or parallelism (2001) available for the level or parallelism involved in large-scale development were involved in large-scale development were inadequateinadequate

The number of defects was proportional to The number of defects was proportional to the level of parallelismthe level of parallelism

Team workTeam work

In parallel development team work plays a In parallel development team work plays a vital role to insure good integration of the vital role to insure good integration of the system system

Communication, effort and interaction need Communication, effort and interaction need to be effectively organised and executed for to be effectively organised and executed for parallel development effort to succeedparallel development effort to succeed

Team members need be aware of what other Team members need be aware of what other team members are doing and why team members are doing and why

Workflow Organization Workflow Organization

Microsoft Solution Framework

It is not a question of how well It is not a question of how well each process works, the each process works, the question is how well they all question is how well they all work together. work together.

Lloyd DobensLloyd Dobens

ReferencesReferences

Dewayne E. Perry et al. ACM Transactions on Software Engineering and Methodology, Vol. 10, No. 3, July 2001, Pages 308-337.

Brad Appleton, Stephen Berczuk, Ralph Cabrera, and Robert Orenstein. Permission is granted to copy for the PLoP '98 conference. 1998

Tom Demarco, Timothy Lister. Peopleware: Productive Projects and Teams. Dorset House. 1999

Plastic SCM Platform Parallel Development. Pablo Santos Luaces. Codice Software. February 2007. www.codicesoftware.com

Context switching. http://codicesoftware.blogspot.com/2006/11/developer-contect-switching.html