Collaborative Software Design & Development Coordination...

1

Collaborative Software Design and Development

© 2006, Dewayne E Perry

Coordination-I

EE 382V – Spring 08

Collaborative Software Design & Development

Coordination I

Deepak Panwar, Nidhi

Nayyar03/06/2008

2

Collaborative Software Design and Development Coordination-I

© 2006, Dewayne E Perry EE 382V – Spring 08

Discussions

Formulation and Preliminary Test of an Empirical Theory of Coordination in Software EngineeringJames D. Hersleb

(Carnegie Mellon University)

Audris

Mockus (Avaya Labs Research)

The Impact of Information Technology on Coordination: Evidence from B-2 “Stealth” BomberNicholas S. Argyres

3



Formulation and Preliminary Test of an Empirical Theory of Coordination in

Software EngineeringJames D. Hersleb, Audris

Mockus

4



OUTLINE, ETC in SEMotivation and ObjectivesWhat is Empirical Theory of Coordination (ETC)?Prior WorkCommon Laws of Software Engineering (SE)Key AssumptionsExperiment DetailsHypothesis and Validation TechniqueConclusion!!

5



Motivation & ObjectivesAny Basic Computer Program: Computation & Coordination

Software Project: Decision Making of Individual Software Engineering & Coordination of these decisions decide success of the project!

Keywords in the paper: Coordination

and Dependencies

among Engineering decisions

in any project are the key to understanding of better methods of software creation!!

6



Motivation & ObjectivesWhat is coordination?

While it is clear that coordination often involves good communication, & that it concerns constraints among engineering decisions.

It is not so cleara) what it means to enhance coordination?b) how to tell if good coordination is present in a project?c) What are implications of effective & ineffective coordination?

Authors set out to: “Create an empirically testable theory to characterize and make predictions about coordination of engineering decisions”.

7



Empirical Theory Vs Theory!Theory:

“A rigorous means of reasoning mathematically from axioms to describe any property”

Are the phenomena of interest accurately described by the theory?

Empirical Theory:a)

Ordinarily tested by drawing out the implications of the theory for observable phenomena i.e generating

hypothesisb)

Observing or constructing situations in which this hypothesis can be tested

(Empirical Validation Research)

8



Objectives in light of Empirical Theory!

To formulate an empirical theory of coordination in software engineering.

To identify testable hypotheses that follow from this theory.

To show examples of precisely how one can go about empirically testing such hypotheses.

9



Prior WorkInterdisciplinary Theory of Coordination

Coordination problems in many fields have similar problems e.g resource conflicts

humans: floor space; programs: memory space Solution: ??? Scheduling

Therefore independent of discipline one could catalog all types of dependency patterns and resolve them.

Authors believe that design work is quite complex and is structured by very complicated patterns of constraints among eng decisions. Therefore their approach does not identify general coordination problems but rather just the sets of decisions as they constrain decision makers.

10



Prior WorkDistributive Cognition

Complex tasks distributed over individuals and artifacts. Viewed as coordinated activity with many interdependent tasks, where coordination occurs by means of communication and sharing of artifacts.

Authors work could be considered a formalization of one key aspect of distributed cognition, i.e, “The impact of mutual constraints among decisions!”

11



Prior WorkGeographically Distributed Software Engineering

Coordination issues more highlighted, project split across sites, nearly total absence of informal communication among developers.

Involves more number of people than number of people that would have been involved in a site.

Statistical models corroborate the fact that number of people is

the most significant predictor of duration.

The delays associated with geographically distributed SE, will be a special case of coordination phenomena by their theory.

12



Common Laws of SEPattern of Dependency among Engineering Decisions

Any SE work proceeds by making choices for all of the decisions. Any feasible project could be defined by the right combination of choices for those decisions.

Choices are made by potentially different people and tend to constrain the choices for the remaining decisions i.e they are mutually constraining.

Authors while analyzing this property of mutual constraints among eng’ decisions understand that the problem of coordination is then recognizing & correctly acting upon these constraints.

13



Common Laws of SE Feasibility Function

14



Common Laws of SEModularity:

It addresses how work is split so that it doesn’t impose unreasonable reqs

for communication and coordination.

The more a design can be partitioned into non overlapping modules (i.e lesser dependencies), the better is the success rate of the project!

Parnas’ Effect:Parnas’ Effect for a given decision Xi is the number of

decisions in other modules that have nonempty effect on Xi. Parnas

effect for a system = sum of Parnas’ effect of

all Xi.

The lower the Parnas’ effect for a system the more are the chances of it’s success!

15



Common Laws of SEConway’s Law:

Conways’ law states that organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. Therefore any piece of software reflects the organizational structure that produced it.

In any design activity the number of variables that do not fit in this homomorphic

relationship could be said to be the Conway’s number of the system, i.e modules implemented by several organizations.

Therefore higher Conway’s numbers could imply more rework, longer cycle times due to lesser coordination.

16



Key Assumptions -

IThe possible effects of infeasible choices:

A1: Defects, faults, errors, failure to complete project( If the infeasible choice is never reconsidered).

A2:

Rework (Infeasible choice is identified and changed, and perhaps other decisions dependent on it must also be changed).

A3:

Longer Cycle Time (Introducing the change of infeasible choices will cause the project to take longer, since rework consumes time).

A4:

Lower Productivity (Rework consumes resources).

17



Key Assumptions -

IISecond Set of Assumptions deal with factors that make infeasible choices more or less likely!

a)

When decision maker is aware of the constraints that relate to other decisions, it is more likely that choice is feasible.

b)

Frequent communication among decision makers who are making mutually constraining decisions increases likelihood of a feasible choice.

18



Key Assumptions -

IIFeasible choices for mutually constraining decisions are more likely to be made when:

A5: The decisions are made by a single person or fewer people.

A6: They are made by people having frequent communication rather than infrequent communication.

A7: All the constraints that relate to a decision are visible to the decision maker.

19



Experiment DetailsData: Extracted from Modification Request (MR) system from a

development project at Avaya Tech.

Project: Embedded software for a communication device with user interface. New functionalities lead to changes with development cycle over two years.

Code Complexity: 30 lead developers spent 2.5 yrs modifying 5000 files. Code was written in C, C++, Java & Assembly. One release for eg contained 1 million lines of code (LOC) of C & C++, 200,000 LOC of assembly, and 100,000 LOC of Java!

Usage:

They use the data to construct the following graphs.a)

Graph that shows workflow among individuals.b)

Organization of files which tend to get changed together.

20



MR Details-> MRs arise from New Features or Defects found.

-> In case of defects developers investigate the problem, make necessary changes and submit an MR for integration.

-> New features involve additional tasks: low level design, design review before coding. After coding is complete MR is submitted.

-> Developers reassign MRs to other developers if they cannot resolve the problem on their own.

-> More than half of the MRs do not lead to changes. They include things like duplicate reports, problems that are not reproducible or are not high priority.

21



Empirical Workflow Graph

22



Empirical Workflow GraphData points measured from the graph:

23



Empirical Workflow GraphHypothesis:

H1: Developers with higher inDegree

will have lower productivity.

Theoretically also this can be derived from assumption A5, that the more the people with whom one must coordinate one’s mutually constraining decisions the more one is likely to make infeasible decisions, hence by assumption A4 the lesser is the productivity.

24



Regression Results Table

25



Conclusions-IProductivity

a) The inDegree

variable is the best indicator of the number of people whose work constraints a given developer’s decisions.

b) Productivity is measured as the number of MRs divided by the total time participating in the project.

c) Self & in represent aspects of individual productivity.d) Out represents time spent but does not count toward individual

productivity.

ResultsProductivity of an individual increases with the self & Ins the

person resolves and significantly reduces with inDegree

(in line with H1)

26



Work Modularity Graph

27



Work Modularity GraphData points measured from the graph

28



Work Modularity GraphH2:

Modification requests that require work in different modules will have longer cycle times than modification requests that require work only in a single module.

Theoretically, if engineering decisions concerning one module have no effects on engineering decisions in other modules, then all relevant constraints are revealed by looking only at a portion of the system rather than system as whole. Therefore by assumption

A7 it will lead to fewer

infeasible decisions which by assumption

A3 will lead to smaller cycle times!

29



Regression Results Table

30



Conclusions-IICycle time and Modularity:

Cycle time implies the interval the MRs involve changes in the code.

Interval is tested based on the factors Other, NReleases, Nfiles, Developer, Multi-mod.

Results:Probability Results indicate that all factors contribute

significantly to the intervals.MRs that require work in different modules will have longer

cycle times!

31



(Case Study)The Impact of Information Technology on

Coordination: Evidence from the B-2 “Stealth” Bomber

Nicholas S. Argyres

32



OUTLINE, B-2 Case StudyB-2 Project OverviewKey ChallengesMethodology for Case StudyStrategy for Project ExecutionProduct Definition SystemStructural AnalysisIssuesConclusion!!

33



Project OverviewCase study of development of B-2 “Stealth” Bomber, an aircraft that was designed by independent firms with IT as the framework!

Stealth Bomber is a military aircraft designed and built for U.S. Air Force.

Project proceeded under very tight secrecy. It was actually America’s biggest military secret since the Atom Bomb!

It is rated as one of the most successful modern aircraft development program ever from the point of efficient organization, keeping in mind the project complexity.

34



Project OverviewThe project was designed during 1980-1986 by four large firms : Northrop, Boeing, Vaught and General Electric. Northrop was the prime contractor on the project, with the other three firms acting as major subcontractors.

Stealth bomber was designed to be “low observable”: it’s difficult to be detected by a radar system.

It was accomplished by the plane’s overall shape, complex surface, use of advanced radar-absorbent material and use of engines free of thermal and acoustic signatures.

35



Project OverviewDeveloping such shaping or scu lptur i ng was a major challenge. The engineering tolerances required were on the order of 1/10,000 of an inch, much greater than a c o n v e n t i o n a l a i r c r a f t

36



Division of Work Based on Company Strengths!

37



Key ChallengesMulti site development: coordination issues.

Different firms imply different working methodologies.

Project highly secretive.

Needed highly accurate design strategies to meet the standards of military aircraft.

Governance & projects costs could be very high due to: asset specificity, miscommunications, redesigns, measurement costs etc.

Chances of first time success could be low if mismanaged!

38



MethodologyData taken by interviewing engineers and managers who were involved in designing the B-2, with industry IT experts and some recently declassified documentsRespondents were asked to describe the functioning of B-2 information system and provide their views on systems critical attributesThere were also some subjective questions regarding the conflicts that arose during the project

Interviewees from the various firms provided very similar accounts of the conflicts

39



StrategiesSystem for coordination!

Northrop had well proven advanced computer-aided design and manufacturing (CAD/CAM) tools.

They took an all digital design approach. With this approach comprehensive information on sizes, shapes, and other attributes of each individual component would be stored on a centralized database.

It would be available to all major subcontractors for inspection on a continuously updated basis.

40



StrategiesForm of Information System

Set of standards for the definition and transmission of data, the analysis of designs, and a format for common database.

Tools 3-D modeling: NCAD and NCAL (Northrop).Orthogonal Drawings: CADAM (Commercial).Structural Analysis System: NASTRAN (NASA).

41



StrategiesForm of Information System

The tools were easily agreed upon, as after some experimentation it was found that design complexity needed the accuracy given only by solid 3-D models.

No commercial system contained a data transmission standard for defining and transmitting 3-D models between incompatible CAD systems. These tools included a standard for transmitting data and storing it in a common database.

42



B-2 Product Definition SystemStandardization, Data Filters, Batch Updates.

Product design used NCAL, NCAD & CADAM. Even with common programs there were different options available to model parts.

Earlier in the design phase engineers understood that it was difficult to interpret data constructed by others (if they used different modeling rules) & check for compatibility.

Fixed standards were set for modeling. Automated data filters

which were called by batch updates

checked the

integrity of the data before it could be entered into the common database.

43



Product Definition SystemPrototyping cost reduction!

IT based product definition system (PDS) allowed very tight integration between CAD and CAM.

System allowed parts to be manufactured on automated tools using data directly from the database. 3-D models were translated into codes to run numerically controlled machines used to shape parts.

B-2 PDS allowed the elimination of conventional prototyping in the form of blueprints, paperwork and lot of engineers spending time in translations.

44



Product Definition SystemIncreased Prototyping Success Rate!

Elimination of intermediate tool based prototyping steps, creation of manufacturing drawings and machine codes directly from the database!

Results: Parts could meet specifications more accurately with lesser

trials. Redundant prototyping left less room for design misinterpretation.

Northrop claimed 90% first time fits due to lesser form and fit errors. Saves redesigns and rework significantly!

45



Product Definition SystemIT based PDS much lesser maintenance costs!

Conventional engineering designs require large manuals drawing information out of blueprints or outputs from 2-D CAD systems.

Significant manual documentation work, and paper cost was saved as designers and automated tools could directly access information from the database.

46



Product Definition SystemGeneral Advantages from IT based automation!

IT based PDS allowed much better communication between designers, manufacturers, maintenance people than would have been without the system.

Decreased the number of messages that needed to be sent across all cross functional teams to achieve the goodness-of-fit targets.

The system allowed engineers to capture and transmit large volume of data in a very economical way.

47



Product Definition SystemGeneral Advantages from IT based automation!

PDS reduced the scope for misinterpretations of complex product descriptions by designers, manufacturers and machinists.

Allowed automatic maintenance activities through database batch updates!

A standard system creates a technical grammar or social convention that everyone follows without any intermediate authority enforcing it e.g traffic signals

48



Product Definition SystemAgency cost It is the cost associated with self-interested actions by members of an organization as well cost associated with monitoring and metering the performance of those agents to limit such action

Measurement costIt is the agency cost when the good is purchase through the market and the buyers cannot determine the qualities of good to bought, and the seller can easily and without detection, reduce or misrepresent the quality of their good

49



Product Definition SystemSince B-2 design project involved a network of independent contracting firms, the concept of measurement cost is more applicable

The PDS provided a low-cost way of monitoring and measuring the quality of designers work and hence prevented opportunistic or careless behavior by certain engineers or firms

By reducing agency/measurement cost, IT allowed decentralization within organizations because it can be used to monitor and measure performance of employees at lower level

50



Structural AnalysisA computerized system known as NASTRAN was used for analyzing the structural integrity of the aircraft

Developed by NASA, NASTRAN was the most advanced structural analysis software available at that time

The structure was defined as set of elements, each with a given number of nodes. Each element was endowed with capabilities of sustaining a certain amount of force

51



Structural AnalysisAll structural analysis was overseen by a Master Model Committee, which had representatives from all the subcontractors

The committee defined nodes at the interfaces of various aircraft sections allowing the different subcontractors to work independently

NASTRAN reduced significant amount of redesign because of it’s capability to simulate the structure with a large amount of details

52



Structural AnalysisBenefits of the NASTRAN system

Allowed the subcontractors to work independently by “modularizing” the design

Acted like a social convention resulting in the low requirement of horizontal communication to achieve coordination

It had a centralized organization in the form of “Master Model Committee” to solve the technical issues. However, it had no hierarchical authority

53



Issues

Initial resistance to the standards adopted by Northrop, however alternative database formats and applications had not reached a stage of development where they could beat the maturity of Northrop systems.

Sometimes redesign resulted in the change of workloads for different subcontractors

Due to its no hierarchical authority, Master Model Committee couldn’t solve all disputes

However, Project continued as scheduled because of Air Force willingness to intervene is case of dispute and even absorb some of the costs

54



ConclusionSuccessful development of a very high technology aircraft. IT based automated platform provided enhanced coordination. Specific features like data filters and batch updates that helped in solving difficult communication and governance problems.PDS system allowed considerable decentralization of design decision making by setting a social convention and providing a communication channel between designers.PDS system reduced the cost of governing exchange relationship between the firms. Data filters & updating features reduced agency/measurement cost.

Collaborative Software Design & Development Coordination...

Documents

Transcript of Collaborative Software Design & Development Coordination...