Security Engineering (Chapter 6) 1 Security Engineering Chapter 6 Distributed Systems.
6 Distributed
-
Upload
tuomasniinimaki -
Category
Documents
-
view
351 -
download
0
description
Transcript of 6 Distributed
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.5612 Software Project Management Spring 2010
6: Distributed Software Projects
Tuomas Niinimäki
Department of Computer Science and Engineering Helsinki University of Technology
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Why distribute a software project?
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Goals of distribution
Cost reduction Access to competent labor force Presence in new markets Around-the-clock / Follow-the-sun development Focusing on core competencies
(Carmel 1999)
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Distributed Software Development Project can be distributed by
Geographical location (~ offshoring) Organizational boundaries (~ outsourcing)
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Distributed Project Types
2 or more organizations
1 organization
Same location
Same country
Different countries
Geographical distance
Organizational distance
Traditional
intra-organizational
Locally distributed
inter-organizational
Global
inter- organizational
Locally distributed
intra-organizational
Collocated
inter-organizational
Global
intra-organizational
(Paasivaara 2005)
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Geographical distance Organizational distance
Cultural distance
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Benefits
Cost-reduction Access to new markets Access to competent labor Follow the sun – development
Focus on core competencies Access to competent labor Cost-reduction
Geographical distance Organizational distance
Cultural distance
Access to new markets Access to competent labor
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Challenges
Location Time zones
Command & Control Practices
Geographical distance Organizational distance
Cultural distance
Conventions Assumptions Language
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Geographical distance – near/offshore Offshoring
Globally distributed software development projects E.g. in different continents, across multiple time-zones Higher potential to leverage cost differences
Nearshoring Not going too far, e.g. in the same continent / time-zone Reducing risk by having
similar culture business conventions legal system less geographical distance between sites
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
NEARSHORING
OFFSHORING
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Allen curve (Allen 1978) Probability of Communication at least once a week
Distance
30 m
10%
30%
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Geographical distance - summary
Goals: Cost-reduction Access to new markets Access to competent labor Follow the sun –
development
Risks: Communication delays Lack of awareness,
visibility Division of work Language problems and
cultural conflicts Different business
conventions, legislation, …
Collocated Distributed in one country
Nearshoring Offshoring
Low risk = less benefits High risk = more benefits
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Organizational distribution
Goals: Focus on core
competencies Access to competent labor Lower cost
Risks: Differences in practices,
conventions Division of tasks Command & control Lack of visibility Contracts Conflicts of interest,
competition
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Organizational distance
Resources managed by the customer
Independent subcontractor
teams
Black box
Broad
Small- scale
Project management resposibility
Customer Subcontractor
Transparent Box
Broadness of the task
Subcontractor uses customer’s process
The subcontractor uses its own process
Collaboration practices need to be defined
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Challenges of Distribution (1/4) Coordination breakdown
Difficult to divide tasks
Geographical distance Limits informal communication and face-to-face meetings Traveling is expensive and time-consuming
Time-zone differences Around-the-clock development? Limits face-to-face meetings and synchronous
communication Problem solving, integration and testing is hard and slow
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Challenges of Distribution (2/4) Communication breakdown
Lack of communication richness Cultural differences Language barrier Differences in terms used
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Challenges of Distribution (3/4) Loss of “teamness”
Lack of motivation/incentive to communicate Lack of feedback Lack of transparency
Lack of trust Fear, uncertainty, doubt Company/Organization borders restrict information flow
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Challenges of Distribution (4/4) Organizational borders
Roles and responsibilities?
Differing processes, tools and working practices
Lack of visibility Context of work unclear Information needs unclear Forgetting or disregarding the informing of distant sites or
partners
Lack of contacts
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
How to reduce risk in distributed software projects?
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Risk from geographical distance Reduce risks from geographical distance
Travel enough especially when problems in the beginning of the project in testing and integration phases
Face-to-face communication essential for Grounding of terms and concepts (= shared
understanding) Informal communication Teamness (= trust, togetherness)
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Reducing risk from time zone difference Reduce risk from temporal distance
Working across time-zones reduces possibilities for communication
Choose sites and partners preferably within same time-zone, if frequent communication is needed
Use asynchronous communication configuration management testing tools bug repository…
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Reducing risks from cultural differences Reduce cultural distance
Bridgehead: e.g. 25% of personnel onshore close to customer and 75% offshore
Cultural liaison: e.g. a native of India settled in Finland serving as a cultural liaison with the offshore team in
India Rotate management across locations to create awareness for
cultural diversity and how to cope with it
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Practices for managing distributed software project
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Visiting Engineer Visits the collaboration partner (customer, subcontractor,
subsidiary) Stays and works there for a longer period of time
1 week – several months Main task is to facilitate communication between sites
Passing information and knowledge Facilitates grounding (common concepts) Creates contacts Helps to solve problems (both technical and organizational) Is available for face-to-face discussions
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Frequent Deliveries Especially beneficial in distributed projects
E.g., weekly deliveries Integration Feedback from remote site, from customer
Benefits Creates transparency Ensures understanding of requirements Brings real check points Avoids “big bang integration” Gives instant feedback Improves developer motivation
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Frequent Deliveries Delivery / Release cycles should be synchronized
The same cycle length should be used by all sites
Schedule for deliveries should be planned Processes and practices for incoming deliveries Resource allocation for evaluating the delivery
Too frequent deliveries increase overhead But may still be beneficial for e.g. risk management, quality
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Example: Different Delivery Cycles
Company Alpha let their North American site deliver to us once every two months. We were required to deliver once a week. When we noticed that something was missing, we had to wait for two months.
We complained about that, and finally they changed to this same once-a-week delivery cycle, but it took all too long to do this change.
Two month delivery cycle was one of the biggest mistakes made in this project. Our bug fixing average times were somewhere between two and three months before the change.
Our scheduling was ruined. We got all the complaints because we were subcontractors.
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Peer-to-Peer Links Establishment of peer-to-peer links between organizations at
several levels Improves communication Enhances teamness
Links can be created between named roles Management level: Subcontracting Project level: Project managers Team level: Domain / Technology experts
Proper and updated organization chart easily available E.g. photos, roles and contact information at project’s web-
site
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Example: Team level links “As a project manager my task is to create the right contacts
between the developers, so that I don’t slow down the work and communication.
Instead, as soon as possible, the right persons will discuss directly, and I just follow that it is working and there isn’t problems.
When I meet the customer’s project manager and he introduces me to somebody [from the customer company]. When I find out that he works with certain module and that we have one person working with another [related] module, we arrange a meeting either through email, phone, or face-to-face. Then they can solve common problems together.”
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Problem solving practices Problem solving communication is even more important in
distributed projects than in collocated projects Often neglected in the project planning phase
Includes discussion related to Requirements Design interfaces technical environment project context
Lack of answers delays the project Barrier to ask / motivation to answer?
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Problem solving practices The lack of answers delays the project
Barrier to ask questions <-> motivation to answer? Consumes time and resources!
Solutions: Problem solving responsible Discussion forums Direct contacts between developers (e.g., chat) Workshops, camps
Face-to-face problem solving E.g. collocated integration and testing
Building trust between teams and individuals
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Sharing information In a distributed project people get only the information you give
them
Formal communication: Make sure important decisions and other information is
shared efficiently Make sure all sites have the access to relevant sources of
information Make sure they know they have the access to information
Tacit knowledge: “There is a lot of information at the corridors” Do not expect anyone to know anything
Make sure they know! Context information helps to understand other messages
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Sharing information Practices:
Inform in the beginning Give reasons and background information Regular meetings
Weekly meetings, e.g. teleconference Issue trackers, task trackers, repositories
Various systems for managing changes and bugs Can your subcontractor access?
Peer-to-peer links in all levels of organization Informal communication Sharing project context
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Monitoring and Giving Transparency Visualize and communicate project status
Follow-up in both directions From the subcontractor to the customer About project progress to the subcontractor
Transparency is important Team members at all distributed sites need progress
information -> a motivating factor One site only managing and controlling the other can be
really annoying and demotivating Open communication about problems and challenges both
ways!
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Monitoring and Giving Transparency Practices:
Regular meetings Who should attend which meeting? Managerial & technical meetings?
Progress reports E.g., tasks done, open questions, problems, future
estimates
Frequent deliveries and integration
Peer-to-peer communication
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Feedback Subcontractors appreciate all feedback - also positive!
A motivating factor What kind of indirect feedback are you giving? Do you listen to the subcontractor’s ideas?
Practices: Design and code walkthroughs Lessons learned Frequent deliveries
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Example: Give Feedback "Sometimes I feel that this is like a black hole, we make [code], and send it somewhere. (...) If you haven't got any feedback for your work during the last half year, then you just start to wonder whether it is ok or not. Of course it is not, because when they start to test after that half a year, then you get the mistakes. It is difficult because you have already forgotten what you did a half year ago."
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Building relationships All communication affects relationship building
Especially meetings in the beginning are important
You cannot have too many face-to-face meetings Travel!! Use “visiting engineer” practice Make visits from all sites possible
Arrange a common kick-off Whole project team, or for each sub-project Both formal and informal agenda Make it possible for people to interact and get to know each
other Maintain relationships with subsequent team events
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Building relationships Alternatively other possibilities to meet, e.g.
Steering group meetings at different sites Provide context from all sites
Trainings hands-on training! Pair programming
Workshops, camps, planning and problem solving meetings Practices:
Give Faces Kick-off Trust building based on professional skill Organization Chart
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Example: Relationship Building We had difficulties to get our acceptance testing people to
understand that we are in the same boat [with our subcontractors] and it is no use to be enemies.
The reasons behind might be that when these developers get a delivery and it is not functioning perfectly well, and they know that it is not made by their friends here, but by someone living in Turkey and trying to do it as cheap as possible.
And that was the reason why testing was delayed here, because it was not motivating.
In this project we learned a lot about communication and how much it actually helps to see those subcontractor’s faces. It was difficult to believe it beforehand!
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Summary
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Geographical distance Organizational distance
Cultural distance
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Lessons learned Distributing a software project does not make it easier to
manage If you don’t know how to do the software yourself, it’s
probably not worth it distributing the work It takes time
to reach the goals: e.g. cost savings, building up competencies
It takes more time Communication delays and overhead Sharing knowledge and competence Motivational issues
Communication is the essential key to success!
SoberIT Software Business and Engineering Institute
HELSINKI UNIVERSITY OF TECHNOLOGY
Thank you.
Questions?
Tuomas Niinimäki