Transcript Challenges in Software Engineering for Collaborative

Challenges in
Software Engineering for
Collaborative Development
Thomas Marlowe (Seton Hall)
Vassilka Kirova (Alcatel-Lucent)
Mojgan Mohtashami (Advanced Infrastructure Design)
Outline

Why cooperative development?


Motivation, properties, forms
A long list of challenges – many open questions





Process
Information
System organization
Technology
Management and legal
Organization A
Organizational
Background
Contingency
Processes
Information
Technology
Inter-organizational
Communication
Effectiveness
Organizational
Background

Contingency
Processes
Software
Development
Performance
Information
Technology
A short list of mitigations
 Endless opportunities for innovation and research
7/21/2015
Organization B
Seton Hall University
Software Engineering Disciplines







Requirements Elicitation
Specification and Analysis
Design
Implementation
Testing and Validation
Maintenance and Evolution
Process Evolution
7/21/2015
Seton Hall University
Traditional Software Engineering
 Disciplines
are phases
 Limited feedback
 “Requirements complete at start of project”
 “Testing can wait until after
implementation”
7/21/2015
Seton Hall University
Agile OO Software Engineering

Disciplines are work areas
 Disciplines exercised concurrently during
development


Obviously, more requirements at start; more evolution
at end; and so on
Testing must start early

Requirements never complete or completely
understood but change
 Development must follow changes
 Evolution is critical
7/21/2015
Seton Hall University
Some Prior Findings

Iterative, continuous communication improves
collaboration and decision making

Large, complex, long-lived, or high uncertainty
projects benefit from dynamic management and
good quality communication

Emphasis on information and knowledge exchange
is the key to collaborative success

Traditional software development practices
negatively affect collaboration
Mojgan Mohtashami - AID, INC.
IRMA May 22
8
THE CHALLENGE
7/21/2015
Seton Hall University
Software Industry Challenges
Costs
Up
Revenues
Down

Intervals
Shrinking
Market
Expectations
Up
Complexity
Up
Stockholders : ROI
Customers: Value
Users : Functionality & Quality
Need solutions that are
flexible, expansible, survivable,
sustainable, affordable and secure
7/21/2015
Seton Hall University
Four Styles of Development
 Traditional

Single organization, few teams, coordinated
 Open

Source
High parallelism, low coordination & control
 Contractual

Vendors, subcontractors, services, …
 Collaborative

Multiple organizations, negotiated partition
7/21/2015
Seton Hall University
Motivation
Software Development is Risky
 75%
of standalone software development
projects fail
 Full collaboration increases resources
 But also increases complexity and risk
 Without attention to collaborative process,
failure rate is almost certainly higher
7/21/2015
Seton Hall University
Models
 Traditional,


single-organizational
Dominant style for small and medium projects
Problems for large and complex projects
• Expertise, staffing, resources, economy, …
7/21/2015
Seton Hall University
Models
 Open


source
Important source for low-security projects,
components and tools
Management and intellectual property issues
 Contractual



model
Uses expertise, resources, … of others
Limited flexibility after early decisions
Fits traditional software engineering model
7/21/2015
Seton Hall University
Models
 Collaborative





model
Highly flexible, both for resources & design
Better fit to modern software engineering
Distributed, collaborative risk management
Success in restricted domains/environments
Lots of open questions
7/21/2015
Seton Hall University
What to do?

Iterative incremental development

Management contingency policies

Distributed development

Across teams, sites, and organizations

Distributed risk management

Collaborative development

International collaboration
7/21/2015
Seton Hall University
Cooperative-Collaborative
Development

Development

Large and complex systems
• Ultra-large Scale Systems (DoD, SEI)

Requiring multiple specialties
• Mix of skills, knowledge and expertise
• Multiple communities of experts



Specialized components, tools & libraries
Diversity of development models and participating
organizations
Software production as a socio-technical ecosystem
7/21/2015
Seton Hall University
Cooperative Development
 Cooperative



development
Multiple teams working toward
a common product
Often at multiple sites
Frequently in different organizations
 Domain
and application experts and
specialists—and reusable code base—
also widely distributed
7/21/2015
Seton Hall University
International Collaboration
 New


Multiple perspectives and skill
sets—both managerial & technical
Time zones extend collaborative
work day
 New



Benefits
Challenges
Conflicts in perspectives and skill sets
Time differences inhibit communication
Language and cultural differences matter
7/21/2015
Seton Hall University
Collaborative Development
Our Goal
 Provide
a documented, standardized
structure





7/21/2015
A foundation for collaborative
process definition & alignment
A bridge to management buy-in
A basis for SQA for collaborative
systems
A plan for ongoing involvement
A checklist for possible risks and hazards
Seton Hall University
MODES OF COLLABORATIVE
SOFTWARE DEVELOPMENT
Cooperative Development
 Inter-organizational
Collaborative Software
Development (ICSD)

Often international
• Management-inspired — outsourcing/offshoring
• Technically inspired — expertise matching

Less collaboration  less satisfactory
 Important
business, process, and project
characteristics
7/21/2015
Seton Hall University
ICSD
 Business



Characteristics
Long or short-term alliances
Ventures with loosely defined relationships
with parent company
Distributed decentralized development and
management model
7/21/2015
Seton Hall University
ICSD
 Process



Characteristics
Full-fledged integrated development, with
dynamic requirements and flexible design
Flexible component development
Development of modifiable, configurable tools
and libraries
7/21/2015
Seton Hall University
ICSD
 Project



Characteristics
Long-lived projects or high innovation
Components with specific roles, but significant
dependences and interaction
Evolvable specification, not completely fixed
7/21/2015
Seton Hall University
Requirements for
Collaborative Software
Development
Overview
 ICSD





requires
High bandwidth and high
diversity communication
Ongoing coordination
Emphasis on information and communication
Collaboration-aware risk management
Collaboration-aware management policies
7/21/2015
Seton Hall University
Examining the Challenges
and Requirements
 Processes
and methods
 Technology and infrastructure
 Risk Management
 Corporate Management
 Customer Interaction
 Legal
 Metrics
 Reflection—process flexibility & evolution
7/21/2015
Seton Hall University
Process Challenges
 Need
to develop a modified process for
software development



Start with less common knowledge
Require more information sharing
Constrained by lower information bandwidth
• Both data volume and conceptual communication
• Face-to-face or even virtual face-to-face interaction
necessarily more limited

Constrained by cultural differences
7/21/2015
Seton Hall University
Process Challenges
Information

Sharing information





Relax need-to-know, information
hiding relative to requirements
Share high-level process and
design views
Provide support for design
decisions
Interacts with management and legal concerns
Be sensitive to cultural differences—what is the role
of personal information?
7/21/2015
Seton Hall University
Process Challenges
System Organization & Design

Architectures


Component structure




Adaptable, open architectures, aspects, services
Component boundaries and interaction mechanisms
Identify integration and end-to-end constraints
Support flexible interfaces
Levels of abstraction

Use higher-levels of abstraction in system definition
and design (e.g., model-driven development, domain
specific modeling languages)
7/21/2015
Seton Hall University
Technology Challenges
 Integrated
(possibly virtual) development
environment or views
 Coordinated tool support
and development
 Common tools
where appropriate
 Identify and extend
existing tools and techniques

“Not invented here” is also cultural
7/21/2015
Seton Hall University
Technology Challenges
Communication
 Both
synchronous and
asynchronous channels
 Improved multi-media
communication

Live Meeting support
including (e.g. LiveMeeting)
 Collaborative

Environments
Co-authoring (e.g., ColabNet)
7/21/2015
Seton Hall University
Technology Challenges
Knowledge base
 Support
for lore—a viable group memory
 Shared project repositories

Documents, code, specification
and design artifacts, …
 Multi-layer,
distributed
risk management archive
 With language differences


Establish governing versions of text documents
Create usable translations where feasible
7/21/2015
Seton Hall University
Special Technical Challenges
 Handling
innovation
 Security
 Real-time
applications
 Active applications with
multiple active components

Process control, voting, robotics, …
 Extensive
multi-lingual interfaces
 Configurability over multiple components
7/21/2015
Seton Hall University
Risk Management
 Uncertainty
+ loss
 Steps in risk management






Identify and analyze
Plan how to recognize, handle
and recover
Try to avoid or prevent
Mitigate occurrences
Recover software process
Need communication and reflection
7/21/2015
Seton Hall University
Risk Management Challenges
New and Modified Risk Factors
 Communication



Increased bandwidth
increases vulnerability
New modes and artifacts
require infrastructure
and understanding
Linguistic and cultural
differences complicate
specification and documentation
7/21/2015
Seton Hall University
Risk Management Challenges
New and Modified Risk Factors
 Cultural




differences
Not just social and language
Institutional, site, and team culture
Work norms and at-work interactions
Interactions with
outside contacts
7/21/2015
Seton Hall University
Risk Management Challenges
New and Modified Risk Factors
 Differences in processes and practices

Incompatible views of design, code, and data
• Leads to difficulties in integration
• Leads to misunderstandings


Impact of process and practices
on mental map,
and conversely
Sapir-Whorf —
also language
7/21/2015
Seton Hall University
Risk Management Challenges
New and Modified Risk Factors
 Collaborative impact of problem


Increased risk (of course) at
component interfaces
Risk confinement and contagion
• Scope limited to single component or organization
• Effects primarily on interfaces or agreements
• Many components or partners affected
7/21/2015
Seton Hall University
Risk Management Challenges
New and Modified Risk Factors
 Collaborative impact of problem

Trust—Problems can affect ongoing
relationships
• Current project
• Future collaboration
• Reputation and ability to form
new collaborations


Language and cultural differences exacerbate
May be redressable or recoverable
7/21/2015
Seton Hall University
Risk Management Challenges
Why is this a new challenge?
 Cultural

differences
Lots of work on social and management
practices
• For example, American vs Japanese customs


Little attention to differences in technical or
technical management worldviews
Little attention to differences in work norms or
importance of work for technical staff
7/21/2015
Seton Hall University
Risk Management Challenges
New Criteria for Effective Collaboration
 Level
of trust established
 Cultural sensitivity
 Collaborative communication
 Effective interaction
 Focus on quality of relationships
 Technical support for communication
7/21/2015
Seton Hall University
Risk Management Challenges
New Criteria for Effective Collaboration
 Aligned
management support
 Responsibility for risk management
 Responsibility for customer interaction
 Responsibility for maintenance
 Process for product evolution
 Process for process evolution, including
updating RMMM plan
7/21/2015
Seton Hall University
Risk Management Challenges
Some specific issues

Glossary must account
for regional or cultural
differences in definitions of words
 At least three facets of communication



Culture-neutral or culture-exempt technical
communication
Culture-sensitive personal communication at both
management and technical levels
Culture-aware documentation—both for development
and for customers + users
7/21/2015
Seton Hall University
Management Challenges
 Management


Management buy-in is important and often
tricky
Need a process for resolving
disputes
• Arbitration—by whom? Where?
• Need a way to judge technical
merit in addition to legal rights

Needs to be seen as forging alliances, not as
weakness or revealing secrets
7/21/2015
Seton Hall University
Management Challenges
 Management


metrics
Evaluation of cooperative
projects and staff
Cost-benefit needs to include
• Immediate benefits from collaboration
• Benefits from long-term relationships (encourage!)

Multiple alliances and conflicting loyalties
7/21/2015
Seton Hall University
Management Challenges
Management Contingency Policies
 Management
planning ahead
 Three major aspects



Response to external stimuli
Management of organizational behavior
Management of processes
7/21/2015
Seton Hall University
Management Challenges
Management Contingency Policies

Tensions in collaborative development
 Need more clearly defined policies and practices

 Need more flexible policies and practices
 Need to detect changes and problems quickly and robustly

 Need to coordinate responses, possibly delaying action
 Need to promote information sharing

 Need to protect intellectual property, privacy, security, & resources
7/21/2015
Seton Hall University
Management Challenges
Customer Interaction
 Customer





interaction with multiple partners
Likely to blur responsibilities
Likely to confuse customer
Customer may provide conflicting information
Partners may have
conflicting interpretations
Most importantly, likely
to weary customer
 Interact
in customer’s language & idiom
 Need a policy for customer interaction
7/21/2015
Seton Hall University
Legal challenges
 Intellectual

property rights—general
Application and tools
• Can you reuse your component?
• Can you use it in a competitor’s application?

Proprietary confidential information
• Library source code, proprietary tools, data, …

Test suites and case studies
• Performance of partner applications or process

Overlapping alliances and conflicts
7/21/2015
Seton Hall University
Legal Challenges
 Intellectual

property rights
Right to publish and disseminate
• Revealing experimental results

Indirect intellectual property
• Insights developed in
collaborative process
• Process and practices
 Whose
7/21/2015
law governs what?
Seton Hall University
Metrics Challenges
 How







can one measure
Readiness of an institution or
work force for collaboration
Suitability of a product for
collaborative development
Success of an alliance
Success of a collaborative project
Success of a collaborative product
Uniform application of standards
Quality of collaborative support
7/21/2015
Seton Hall University
Reflection Challenges
Flexibility and Adaptability
 Define
collaborative process so as to allow
flexibility for different


Domains
Application form and nature
• Behavior, constraints and lifetime

Modes of collaboration
7/21/2015
Seton Hall University
Reflection Challenges
Evolution
 Provide

support for evolution
Technical structure
• What is needed?
• Where is change needed?
• What effect does it have on interfaces?

Management structure

• Who initiates?
• Who prioritizes modifications?
• Who commits new versions?
http://www.lifewithalacrity.com/ Evolution of Soc Soft
7/21/2015
Seton Hall University
Some approaches
General Principle
 Hierarchical/layered





approach
Leave as much as
possible under local control
Modify as needed to address
collaborative concerns
Create flexible interfaces
Increase communication between organizations
Define a policy or structure for negotiation and
dispute resolution
 Increase
cross-awareness of cultural and
organizational differences
7/21/2015
Seton Hall University
General Principle
 Flexible


interfaces
Between components
Between organizations
 Increased

communication
Increased bandwidth
• Technical, management, and interpersonal
• Diversity of artifacts
• Negotiation of changes
7/21/2015
Seton Hall University
Technical Infrastructure
Collaborative Development Environments

Open Source platforms (SourceForge)
 SaaS (Software as a Service) –
can this be used?
 Multi-layer, distributed SCM and
SCR
 Application Lifecycle Management

codeBeamer, Polarion, Borland, etc.

TraceabilityWeb and Artifact Flow Through
 Eclipse and Jazz
7/21/2015
Seton Hall University
FLEXIBLE INTERFACES
7/21/2015
Seton Hall University
Interface Layers
 Physical

Protocols, storage, security
 Design

& Implementation
Specification, architecture, UML, process
 Information

Management
Change management, artifact flow
 Knowledge
Management
 Management Contingency Policy

Risk management, business environment
7/21/2015
Seton Hall University
Accommodating Change in
Development
 Software
Architectures provide guided
decomposition of large projects
 Traceability connects changes to


Original or changed requirements
Design decisions or tradeoffs
 Agile
methods provide an approach for
graceful accommodation of change by
iterative specification, design, modification
7/21/2015
Seton Hall University
Managing Change
Benefit/Impact
level
Open,
scalable,
architecture
Agile
methods
Traceability
500 REQS
2,000 REQS
10,000 REQS
Small,
Large,
The
Change
Accommodation
Tool-Box
relatively
complex
simple
project
project
REQS - Requirements
7/21/2015
Seton Hall University
Managing Change
 Traceability—the


Fits contractual mode best
But want to work with partially specified
requirements and highly dynamic applications
 Full



problem
traceability
Documentation large and hard to access
Dependence web can be enormous
Updating dependences intricate and tricky
 Automation
July 2 2008
can alleviate to large extent
WM-SCI 2008
73
Managing Change
 Agile







methods—the problem
Communication bandwidth
Effort duplicated or at cross-purposes
Resulting inconsistent interfaces
Stresses dispute resolution mechanism
Stresses ongoing management buy-in & unity
Poor support for early, high-level modular
decomposition
Client cannot be involved everywhere
July 2 2008
WM-SCI 2008
74
Managing Change
 Traceability




and agility still useful
Traceability provides rationale
Agility provides for flexibility & evolution
Have to be used selectively
Apply control and focus
 Need
to combine with software
architecture techniques
 Provide an overall strategy
July 2 2008
WM-SCI 2008
75
Interfaces and Managing Change
 Three-level


strategy for interfaces
Kernel, defining interface semantics
Shell, with relaxed assumptions on
interface syntax, supported by
design patterns
• Exceptions, specialization, …

Auxiliary services, to communicate
bookkeeping and related information
between components
• History, links to services, workload, …
7/21/2015
Seton Hall University
Layered Architecture
 Kernel

architecture
Core component behavior and extrafunctional properties
• Interface guarantee to other components
• Ordinary semantics and syntax fixed,
• Exception semantics extensible to respond to
newly found problems


Kernel interface alterable only in the most
extreme circumstances
May provide some flexibility, such as timing
7/21/2015
Seton Hall University
Layered Architecture
 Shell



interface architecture
Actual call-return or message structure
Additional services that may be used in extending or
evolving component behavior
Fixed boundaries, negotiable details
7/21/2015
Seton Hall University
Layered Architecture

Shell interface architecture allows





Optimized or specialized calling patterns or asynchronous
messages
Wrapped sequences or selections of kernel calls
Leverage of implementation decisions in partners
Forwarding of calls/results from clients or to services
May also support


Support for optional extensions
Adaptation for changes in drivers and platforms
• May use different operator implementations
• May introduce different stresses & tradeoffs on memory,
performance, and integrity.
7/21/2015
Seton Hall University
Layered Architecture
 Auxiliary




services and adaptive data
System, history, profiling, configuration, and
other information
Developed in one component
Not part of interface semantics
But usable by other components
• Data structure size and complexity
• Tuning performance
• Sharing resources
7/21/2015
Seton Hall University
Supporting Shell and Service
Flexibility
 Design

Patterns
Adapter, Bridge, Façade, Mediator, Observer,
Decorator, Builder, …
 Aspects


Instantiate and modify aspect
Specialize by defining more precise pointcuts
 Add
calls or asynchronous messaging for
auxiliary services
7/21/2015
Seton Hall University
Examples

Forward identity of a service via Proxy



Shared data structure state information


Facilitates use of State or Strategy in advance of sequence of
calls to improve performance
History information




Remove the need for the component to find and connect to such
a service on its own
With Adapter, allows parallel or specialized components
Simpler to keep on the caller side
Dynamic specialization/optimization of component calls
Snapshots can be passed through use of Memento
Improve performance of shared databases/knowledge
bases with strategy and history using Observer
7/21/2015
Seton Hall University
RISK MANAGEMENT
7/21/2015
Seton Hall University
Risk management
A layered solution
1.
2.
3.
Modified internal RMMM plans
Shared inter-organizational plan
Structure for reporting,
mediation and resolution
7/21/2015
Seton Hall University
Risk management
Modified internal RMMM plans
Account for





Interface guarantees
Global or end-to-end constraints
Increased communication responsibilities
Collaborative risks
•
7/21/2015
Relationships, trust,
risk of contagion
Seton Hall University
Risk management
Modified internal RMMM plans
Enhance reporting structure

To notify partners
To communicate effects
on shared RMMM


Modify institutional practices and policies



7/21/2015
If endanger ongoing relationship
If seriously restrict communication
bandwidth or quality
Seton Hall University
Risk management
Modified internal RMMM plans
Report changes in





7/21/2015
Institutional practices and policies
Relevant national or local laws, statutes, and
regulations
Regional standards from professional or
industrial groups
Technical support environment for
development and for communication
Seton Hall University
Risk management
Shared inter-organizational plan
Address risks missed in local plans



Interface risks
Risks arising from global constraints
•
•


7/21/2015
Software risks more easily detected in integration
Communication and relationship risks relying on
reports from multiple partners
Risks to trust, cooperation, collaboration
Risks that will affect multiple partners in
different ways
Seton Hall University
Risk management
Shared inter-organizational plan
Be attentive to externally-introduced
discrepancies



7/21/2015
Conflicts arising from changes in laws,
statues, regulations, or standards
Problems arising from changes in
institutional practices
Seton Hall University
Risk management
Shared inter-organizational plan
Ensure




7/21/2015
Clear responsibility for customer contact and
policy for customer involvement
Clear process and practices for prioritizing
and assigning responsibilities for evolution
and maintenance
Clear plan for RMMM evolution
Seton Hall University
Risk management
Mediation and Resolution
Establish a structure for shared plan

Administration
Management policies and
practices
Evolution of shared plan



Establish a structure for
conflict resolution



7/21/2015
Procedure for internal resolution
External mediation or arbitration
Seton Hall University
Handling the Critical Risks
Communication
Technical communication

Assure proper IT support
Assure usability of tool-created artifacts
Check for cultural assumptions in
documentation, diagrams, figures, naming



Management coordination




7/21/2015
Assure regular communication
Create cultural awareness
Create work familiarity
Seton Hall University
Handling the Critical Risks
Communication
Interpersonal communication

Must be culturally sensitive
Must include technical staff,
not just management
Must be ongoing



Provide quality support for translation


7/21/2015
Handle cultural as well as language
differences
Seton Hall University
Handling the Critical Risks
Trust



Absence of trust responsible for 40-70%
of collaborative failures
Affects quality and effective bandwidth of
communication
Can compensate for deficiencies in IT
support and practice discrepancies
7/21/2015
Seton Hall University
Handling the Critical Risks
Culture
National, regional and language



Approaches to work and to learning
Interpersonal attitudes
•
•

7/21/2015
Superiors, elders, hosts and
guests, …
May not want to compromise
on race & gender
Language and idiom
Seton Hall University
Handling the Critical Risks
Culture
Professional and organizational




7/21/2015
Investment in education, knowledge, and
training
Work norms and expectations
Attitudes toward customers, contractors,
vendors, collaborators, clients, …
Seton Hall University
Handling the Critical Risks
Culture
Recommended steps





7/21/2015
Establish training and orientation programs
for cultural awareness
Examine organizational policies and
practices for inconsistencies
Seek to establish cross-organizational work
familiarity and shared mental models
Solicit input on communication quality and
problems
Seton Hall University
Parting Words
 Collaboration
is increasingly important
 Can deliver enormous benefits
 But calls for care and changes
 Fortunately, solutions can be found
7/21/2015
Seton Hall University
Acknowledgments
 Dr.
Fadi Deek, NJIT
 Dr. Stephen Masticola, Siemens CR
 Norbert Jastroch, MetConsulting
 Students and colleagues
Alcatel-Lucent
Seton Hall University
NJIT
 Dr. Cyril Ku, WPU
7/21/2015
Seton Hall University
References

Overview


Interfaces





“A Comparison of Three Modes of Collaboration”, submitted, AMCIS 2009.
“High-level Component Interfaces for Collaborative Development: A Proposal”, accepted,
IMETI 2009, July 2009.
"Prendre en compte les changements dynamiques dans le développement cooperative du
logiciel", Génie Logiciel, Decembre 2008. (Translation of “Enhanced Change Management
for Collaborative Software Development”, ICSSEA 08 Special Issue).
“Addressing Change in Collaborative Software Development through Integrated Artifact Flow
and Dependence Analysis”, ICSSEA08, December 2008.
“Addressing Change in Collaborative Software Development through Agility and Automated
Traceability”, WMSCI 2008, June-July 2008.
Risk Management


“Risk-Driven Management Contingency Policies in Collaborative Software Development”,
International Journal of Information Technology and Management, to appear, 2009.
“Risk Management for Collaborative Software Development”, Information Systems
Management, 25 (4), 20–30, Fall 2006. Reprinted in The EDP Audit, Control, and Security
Newsletter, 35 (3), March 2007.
7/21/2015
Seton Hall University