Implications for the Design of Collaboration and Awareness Tools

 The coworkers should be maintained so as to develop a better and perform fast processing. Task dependencies refer to a matrix which keep into account which all task are dependent on what all tasks. It states the dependencies between various task. task dependencies to monitor the  coordination in the project. Coordination is required between team members also which can be monitored using the task dependencies. a method that could be used to design tools for coordination which will focus mainly on collaboration and awareness. congruence as the measure of the fit. Measuring the congruence can indicate the speed and efficiency of the work. Also it can be used to reduce the amount of time required to perform the tasks.

Coordination Requirements and congruence are used to monitor the coordination.Coordination requirements indicate the amount of coordination that is requirement and between which all developers. In GSD coordination requirements change rapidly and also because of social and cultural differences. The coordination requirements indicates the interdependencies between the task and also between the developers. The paper aims at determining how the coordination requirement change over time GSD involves a large number of developers, which are grouped into teams and they work parallel on different modules. The dependencies between these modules change with time and also the developers interact with different developers as time goes by .The method to indicate the dependencies and the interaction of the developers is very useful for the GSD projects. The paper presents the result on data collected from a data storage industry for three years of development activity and first four releases of the product. The unit of analysis used is modification request (MR) , which is the change request that comes from the developers or the customers after the code freeze phase. When MR is the change that is made to the existing system. The method used to coordinate between teams in the project were the Internet Relay Chat(IRC) and MR tracking system. Measuring coordination requirements require two matrices . The two matrices are the task assignment matrix which indicates which member is assigned which task and the task dependencies matrix which indicates which task is dependent on which task. That is the interdependencies of task is given by task dependencies matrix. Task Assignment matrix is multiplied to task dependencies matrix to give the set of task a particular member should be aware of. Now this matrix so obtained is multiplied by the transpose of task assignment matrix which indicates (cell ij) the extend to which member i works on tasks that share dependencies with the tasks worked on by member j. This gives the coordination requirements . The coordination requirement matrix was build by taking the information from the MR reports. The paper discusses the stability of the coordination requirements. The coordination requirements were calculated for every week and plotted.It was observed that the coordination requirements were very volatile in nature and no pattern was observed. Coordination requirements are highly unstable and change dynamically. This indicates that the extend to which to members will need to coordinate with each other is dynamic in nature and can not be predicted easily.

Congruence indicates the proportion to which the coordination requirements were satisfied. Higher the congruence , more accurate the predicted coordination between requirements were achieved. Congruence can be measured by comparing the actual coordination requuirements with the coordination requirements. The actual coordination matrix indicates the coordination that took place. If in coordination requirement matrix it was indicated that 20 pairs should coordinate and in actual coordination matrix only 4 pairs coordinated then , the congruence is (4/20) that is 0.25. The congruence value will always lie between the 0 and 1. The actual coordination matrix was constructed using the four congruence. They are

• Structural congruence : In this actual coordination matrix is build between those members that belong to the same team

• Geographical congruence: In this the actual coordination matrix is build between those teams that belong to the same location. If the congruence value so obtained from this matrix is high , it indicates the coordination is required in the same site and less coordination is required across sites.

• MR communication congruence : In this the actual coordination matrix is build between those members that were the part of the MR. That is they commented on the MR report.

• IRC communication congruence : In this the actual coordination matrix is build between those members who interacted on the IRC . This information is fetched through the IRC logs.

The impact of congruence on task performance was measured using the above four congruence and other measures . To measure task performance the correlation of the above four congruence measure and other measures with the resolution time was calculated. Resolution time indicates the time required to solve a MR . Using the previous year data , the mean , standard deviation , minimum value and maximum values which are needed to normalize the data , skew and kurtosis measures that indicate the bias in the values were recorded in the table. The table list few measures which are as below

• Dependency : This gives the number of modification requests that the main modification request depends on.

• Priority : The MRs were assigned the priority , which range between 1 to 5 , where 5 indicated the highest priority and 1 the lowest.

• Task reassignment : It indicates the number of times an MR was re-assigned to a different engineer or team.

• Release : It identifies the release of the product that the modification request is associated with.

• Change size : It indicates the number of files that were modified as part of the change for the main/focal MR .

• Programming Experience : It indicates the average number of years of programming experience prior to joining the company of all the engineers involved in the modification request.

• Tenure : It indicates the average number of months in the company of all the engineers that worked in the modification request at the time the work associated with the MR was completed.

• Component experience: It indicates the average number of times that the developers responsible for the modification request have worked on the same files affected by the focal modification request.

• Team load : It indicates the average work load of the teams responsible for the components associated with the modification request.

The regression was calculated to using adjusted square mean, and results on the how congruence effect the task performance were drawn.  It was found that if the task performance was directly proportional to the structural congruence. Which means that if the task is performed by the members belonging to the same team, task performance increases.

Also that as the geographical congruence increases that is task is performed by members belonging to same site , the time taken to resolve a modification request will decrease , that is increased task performance.

Change in congruence with time .All congruence measures were taken for all the releases and plotted. The coordination requirements for a n weeks were compared with the actual coordination for n-1 weeks , one week was given for discussion. The graph was plotted for all the releases and it was noticed that structural congruence decreases with releases whereas geographical congruence remains kind of same for all the releases. MR congruence and IRC congruence value increases with releases. This indicates as newer releases of the product are made , more and more coordination is required over MR and IRC channel.

The number of developers making the half amount of changes were computed and it was observed only 18 developers out of around 90 developers did 50% of the changes. Hence they divided the developers into two groups. Group 1 containing 18 top developers and Group 2 containing rest of the developers. It was observed that the group 1 developers coordinated or interacted more on IRC and MR congruence with releases whereas the developers belonging to group 2 interacted relatively less as compared to Group 1 on MR congruence and IRC . This shows that large number of developers consist of a set of developers that actively interact with releases and rest remain less interactive.

As discussed earlier the coordination requirements change with time and are highly unstable.future research on how can we monitor the nature of change of coordination requirement and discover a pattern that it follows. The technique discussed is useful to design collaborative tools and awareness tools. Tools like TeamSCOPE , TUKAN and Palantir  can be enchanced by making use of the congruence measures . The tools like TeamSCOPE can be enchanced by using the concept and technique to measure task dependencies .discussed various techniques that can be used to enchance or develop various collaboration and awareness tools. It provides effective technique to monitor the coordination between sites and hence improve the task performance and speed . also shows various relationships like the amount of interaction among developers belonging to same team or same location or using same communication medium over time. The congruence is used to measure task performance and the coordination. Also the number of developers that actively participate in the development of the project over time is also shown.

EVALUATION MODEL ::Global Software Development Patterns for Project Management

Pattern Language organization with PRINCE2

The PRINCE2 stands for the Projects in Controlled enviornment2. It comprises of 8 processes.

The eight processes are :

• Starting a project :

This process marks the start of the project and is results of the planning and hence give rise to directing the project.

• Intiating a Project:

After planning , the project is intiated after taking into accounts the direction.

• Controlling a Stage :

Controlling a stage , product delivery , managing stage boundaries and directing are interdependent. Each of them calls the other and provide feedback to each other till no information is achieved any longer.

• Managing Product Delivery:

Controlling a stage , product delivery , managing stage boundaries and directing are interdependent. Each of them calls the other and provide feedback to each other till no information is achieved any longer.

• Planning:

Controlling a stage , product delivery , managing stage boundaries and directing are interdependent. Each of them calls the other and provide feedback to each other till no information is achieved any longer.

• Managing Stage boundaries :

Controlling a stage , product delivery , managing stage boundaries and directing are interdependent. Each of them calls the other and provide feedback to each other till no information is achieved any longer.

• Closing a Project :

When no longer any nwe feature or information is there to be included , that is the loop of Controlling a stage , product delivery , managing stage boundaries and directingbreaks, then the project is closed.

• Directing a Project:

Controlling a stage , product delivery , managing stage boundaries and directing are interdependent. Each of them calls the other and provide feedback to each other till no information is achieved any longer.



Each pattern is affected by various patterns.

Assessing a pattern language for GSD Refer to section 4 in the paper

GSD consist of many scenarios, these scenarios have certain response associated with the scenarios. What the pattern language looks into is the quality that is needed in resolving a scenario. For this the model used is Q-PAM . The Q-PAM aims at finding out the patterns that will provide the desired quality. Also it associate with each pattern two variables , they are N and R , N indicates non-risk whereas R indicates risk. If the pattern so applied , has any risks associated with it , then it is recorded in a table. The Table is constructed for scenario, indicating the response , and the quality required and the patterns associated with them , with the indication that wheter there is any risk involved with them or not and finally the result is presented.

Evaluation Indicators

The scenarios and the patterns associated with them are evaluated so that we can deduce which pattern is of high relevance and which of low. A matrix is constructed  which will indicate which pattern is of high relevance , which pattern may result into problem and which will counteract the scenario. There are various indexes that help to figure out the above. They are IR , involvement ratio which is calculated by (N+R)/S , where N indicates the number of Non-risk , R indicates the number of Risks and S indicates the number of scenarios. The IR hence tell us about the relevance of the pattern, low value of IR indicates low relevance. Another parameter that can be used is the RR which gives the risk ratio. The RR, risk ratio, can be calculated using R/(N+R) , and it indicates that pattern may cause problem or benefit. As the value of RR gets near to 1 , it causes more problems then benefits. Also another parameter SI, support index, is calculated using (N-R)/P where P is the number of patterns. It indicates that wheter a scenario is strong enough to counteract the pattern. If the value of SI is negative then it can counteract the pattern.


GSD faces many challenges , these are common in almost all the projects. These problems should be solved at the management level for the success of the project. There are models that can be used to solve such problem and also understand the impact of one problem on the other and on the scenarios. These models can be very beneficial and can also used in the development of the tools which can perform project management for the GSD.

Global Software Development Patterns for Project Management :: Patterns

Global software development needs project management for a software to succeed.some of the problems that need to be monitored for the existing process model to function well, without the need of creating the new process model. There are a various ways to do the same. the pattern language Q-PAM and the model PRINCE2 which can easily deduct the quality that a particular scenario requires and also which all patterns need to be monitored for the same. The patterns exhibit a trade-off between themselves and have certain risks associated with them at times. Project management is a crucial activity and if it is performed well , it can result into the success of the project.



Project management deals with the organizing, planning, securing, managing, leading and controlling resources to achieve goals. Global software development needs good project management as the challenges of communication and coordination makes it more difficult to manage the global software development. The paper discusses various common problems encountered in the process model and present a few solutions for them. The paper calls those various problems as the “patterns”.

A research was performed to discover various problems faced during GSD and then the patterns were evaluated. For evaluation of the patterns the language used was called Q-PAM.

The patterns so identified are as follows :

• Pattern 1: GSD Strategy

GSD strategy to be followed by a company should be identified well before in advance and should be communicated to all the teams involved in the GSD. The GSD strategy might comprise of the motivation and the reason that lead to the adoption of GSD.The strategy should comprise of estimating the cost that would be incurred in GSD. Also the short term and long term planning should be well communicated to all the team members.

• Pattern 2: Fuzzy Front End

Often the need for the development of the product are not clear. To address this problem maintaining a global database in which both the internal and external needs can be entered will help a lot. The project manager then with the architect can sit and decide the need of on the product.

• Pattern 3: Communicate Early

Communication is one of the major problems in GSD, hence for the success of the project, communication should be monitored well. The possible solutions can be arranging a meeting of all the team members before the start of the project and discussing the roles of each team member. Also the use of common repositories can be done so as to keep all the team members updated with the latest happening in the project. Also common communication tools can be used to facilitate communication across geographically distributed sites.

• Pattern 4: Divide and conquer with iteration

The project should be carried out using the divide and conquer strategy and hence all the features to be developed during the project should be explained in iteration to the team members. This way there will be less confusion among the team members. Also the latest technology to be used should be explained to the team members in the very first iteration.

• Pattern 5: Key Roles in Sites

Many a times when there is some problem in the one of the sites then the team members are not aware whom to contact. A possible solutions to such problems could be that the sites should define the roles of the members working in the site like the team leader , site manager and all. A document should be prepared defining all the roles and then distributed to all the sites s or uploaded on the common repositories so that all the team members are aware of whom to contact in case of emegencies.

• Pattern 6: Communication Tools

The problem of communication gets worse when there is no common communication tools between the sites or some some site lack some of the communication tools used. In such cases the communication tools that would be used should be decided prior to beginning of the project and all the members should br trained in how to use them. The communications tools used for different processes could be different and this should be well communicated between the team members.

• Pattern 7: Common Repositories and tools
The problem arises when we cannot get the latest version of the project and this might result in problem when integrating the software. To solve such problems a common respository containing the updated information should be used.

• Pattern 8: Work Allocation

The problem may also arise if the work is not allocated properly , which may reult into two or more teams working in the same module or some module being left out. Hence work should be properly allocated

• Pattern 9: Architectural Work Allocation

The work can be allocated by modules that are mentioned in the architecture.

• Pattern 10 : Phase-based Work Allocation

The work can be allocated in phases too. For example a particular team can be asked to work on say requirements gathering phase whereas other team could be asked for the testing phase. This is much like the rapid application development.

• Pattern 11: Feature-based Work Allocation

The work can be allocated by features in which a team could be asked to develop a feature independent of the other.

• Pattern 12: Use common processes

The teams should share a common template for the reports they write. This will result into better synchronization among the teams and will not face much of the problem in understanding.

• Pattern 13: Iteration planning

Not all the features to be developed should be indicated in the first go. There should be well planned iteration and with every iteration few of the feature to be developed should be unleashed.

• Pattern 14: Multi level Daily Meetings

The meetings to be held daily at particular site to discuss what is going on in the project . And the meetings between different sites can be held weekly to discuss the happenings by the site manager.

• Pattern 15: Iteration Review

Better reviews for all the iterations should be delivered and updated at the common repository. This will help those who have missed the meeting by chance.

• Pattern 16: Organize Knowledge transfer

Knowledge transfer can be done so as to teach all the developers about different technologies and skills.

• Pattern 17: Manage Competence

The competence of each developer should be mantained by the site manager, this will help to assign a particular work to the developer as his competence has been monitored and graded over time.

• Pattern 18: Notice Cultural Differences

Cultural differences result into many problems like the communication , coordination and all. There should be meetings held between people of different cultural so that they understand each other well. Also certain visit to different sites can be arranged to make members understand the context of each other.

The impact of stakeholders’ geographical distribution on managing requirements in a multi-site organization

Global software development includes all the processes of the software engineering cycle. Of all the processes, requirements gathering form the foundation of all the subsequent processes. Requirements gathering includes various processes like the elicitation , prioritization , negotiation , managing uncertainity, validation , analysis and specification. The requirements gathering in GSD faces challenges time differences, cultural diversity, knowledge management and poor communication . All these forms the superset of the challenges faced during requirements engineering.

The paper presents a short case-study before in which a GDS is being considered that took around 18 months for development when 120 developers were involved full time. They had the headquaters in US and teams distributed globally. The roles of the business management and development management were defined  and these were distributed globally on the development management . Business management was located in US. The requirements were gathered at all the sites and were passed to the US Business management group and it was here in the Business management group where business logic was added to the requirements being gathered and was updated into the database. Whenever the request for new requirements came it was again transfered to the BM , then database was updated and then passed to the developers to be developed. These processes took place in iteration till no new feature was added further. To convey each other the requirements back and forth , they needed to collaborate among themselves using certain technologies like email and then audio video conferencing , microsoft excel to communicate about the context diagrams. But they faced certain problems with the usage of these technologies , like for the email they were not aware wheter the right information being conveyed or answered and there was no instant feedback or answered recieved. Also with the audio-video conferencing they faced problems of lack of common communication tools and time differences and difficulty in understanding the accent of the other collocated team. From the case study the paper concluded the factors that effect the requirements engineering. They can be broadly classified as :

• Inadequate communication : This is due to lack of communication tools as well as lack of informal communication between the teams which result in incomplete information being gathered and in wrong information due to cultural and ccent differences.

• Knowledge management : The Knowledge is not being shared effectively in GSD. This is because of no common repositories and not updation of the information available on the repositories. Also common processes are not being used across sites that result in ambiguous information.

• Time differences : Different time zones result into less communication and less time to collaborate.

• Cultural Diversity : Different cultures have different way of treating each other and also there are different festivals and holidays which hinder the progress of the software.

The challenges can be discussed more holistic as below :

• Diversity in customer culture and business
The diversity in culture impacts many processes of the requirement engineering . It creates a problem in eliciting the requirements which requires better understanding of the requirements. Due to this the requirements are not prioritized effectively hence effecting prioritization. As culture differences hinder communication and coordination , requirements are not negotiated properly and also not validated.

• Achieving appropriate participation of system users and all
As there was less participation of the users and the personnel , who were distributed globally , due to time difference and poor communication , it effected many processes of the requirements engineering . Due to poor communication it becomes to elicit , priortize , manage and negotiate the requirements.

• Lack of informal communication and diminished awareness of local working context 

It becomes very difficult to communicate effectively and gather complete information in a single formal meeting. Informal communication plays a vital role in all software development. Due to lack of informal communication all requirements could not be gathered and specified and also , it is very important that the collocated coworkers be aware of each other expertise and working context as it keeps the teams informed about the knowledge about expertise , skills e-communication tools, various softwarea nd work style being used on other site. As there was lack of communication , so the requirements could not be validated effectively.

• Reduced level of trust

As discussed above , lack of informal communication resulted into lack of trust. As all the communication was formal , the categorization took place, for example in-group / out-group categorization , this resulted into collocated coworkers to suspect each other and made them think there was some information to which they were not exposed to. This led to ineffective negotiation of the requirements and priortization was also effected as it became difficult to negotiate the priorities as they lack personal relationship. This directly impacted the management of the requirements.

• Difficulty in managing conflict and having open discussions of the interests
Due to lack of informal communication , there was no personal relationship developed across teams on different sites. This greatly impacted when there was some conflict as the team members had the lack of trust and inaccurate impression which restricted in resolving conflicts. Due to use of e-communication tools for discussions , not all the interests were conveyed and conflicts could not be resolved effectively as the teams had no expectation of future face to face interactions. Hence the requirements were not elicited well, also as the conflicts were had to manage , it impacted the negotiation and the management of uncertainity.

• Difficulty in achieving common understanding of requirements

Due to timely meetings across sites and time differences , there was less discussion done on the requirements and to understand them.Mostly the changes are updated on repositories and are conveyed through email, this resulted in ambiguous requirements, as the teams at different site understood requirements differently. This was a result lack of open discussion and inefficient conflict management. As there was no common understanding of requirements , it effected all the processes of requirements engineering from eliciting to validation.

• Ineffective decision-making meetings
The meetings that were held across sites were few as it involves a fair amount of pressure to arrange such meetings as all the sites should have all required members present at the same time, which becomes difficult due to time differences. And due to lack of informal communication the decisions so formed were ineffective as there was lack of discussions on matters.This impacted the analysis of the requirements and due to ineffective decision , wrong analysis was done . Also it became difficult to negotiate and validate the requirements.

• Delay

GSD faces the major problem of delay. This is because for a matter which can be sorted out in an hour, it takes around a day to get resolved as mostly communication takes through email, which results into delay. This delays project too.


There are few solutions discussed in the paper to resolve above problems.The cultural differences can be resolved by proper awareness to all the team members about each others culture. Also the work allocation can be done accordingly.This would ensure greater trust among the team members and better communication. Communication problems can be tackled to a great degree by use of proper and common communication tools. Also a kickoff meeting prior to the start of the project , can serve as an informal meeting between team members and build personal relations. This would ease the problem of communication. Also different tools can be used for different processes. A common process for all reports will also serve as a effective means of communication. The teams can also be trained about the accent, languages and gestures and all so that proper communication takes place. Knowledge can be management by increasing the trust which would come from personal relationship build. Also common repositories should be used to keep all the latest information at a common place. Competence of the members should be measured so as other members know about each other expertise and skills. Also the working context should be made familiar to all. There is no way to overcome the problem of time differences, but it can be used effectively in around the sun development , that is full time development.


Global software development has requirement engineering as one of the important process which builds the foundation of the software development. Requirements faces a lot of challenges which broadly are culture differences, time differences, knowledge management and communication . The paper discusses the factors that effect the process of requirements engineering. Also it indicate what all processes of requirement engineering get effected due  to those challenges. The paper presents few solution to the problems faced. Also there is a need to monitor the requirements engineering phase as it will greatly effect the other phases of software engineering cycle. There is a need to develop a  requirement engineering tool that would be ease the process of requirement engineering for GSD. The tool should consider the problems discussed in the paper which are mainly lack of informal communication , delay , lack of trust, poor communication and work allocation.

From a distance: Impression formation and impression accuracy among geographically distributed coworkers

Global Software development(GSD) involves interaction among developers, leaders and other members. It is different from the traditional software development as the cultural differences , time zone differences comes into play. So there are challenges of communication and coordination among the different sites. These problems arise due to wrong impression that team members form about each other, that could result into poor communication , less and incomplete information being gathered, less motivation for the development of the project and competition between groups. Impression formation is a very important part of the project and is involved from the start till the end of the project. The paper discusses about the factors that restrict formation of individuated impressions and that result into more category based impression formation. Also, the paper discusses about the methods that could help to form accurate impression.

GSD involves many challenges which boils down to the problem of communication and coordination.Research have found that most of the problems arise due to wrong impression formed about each other, which might result into poor communication, wrong information being gathered and demotivation.

Impression formation is one of the most important factor that can result into problems of the communication and coordination and can impact the project. There are two types of impression that one person forms about the another. They are category-based and individuating based. In category based , a member forms impression about other by categorzing them for example based on gender and race whereas in individuating process , a member form the impression about the other based on the qualities. Individuating processes are better than the category based as they provide more appropriate information about the other member. There are various factors that restricts the impression formation when working in a GSD . They are distance , technology mediation , heterogeneity and dynamic structure.

Distance plays a hinderance in GSD. It inhibits the face to face interaction between the team members and also result into less informal communication. Distance has effect on the information being gathered and also result into less motivation in the project as it may be possible that the member in power is located at different site and hence communication is too formal and restricted. The distance has effect on the information , as the situations and the context of the team members differs from site to site , and this information is not avaibable to members at different site. Also researches have found that members form impression about the other members by observing the way they behave to other members, and when they are not at the same site , they cannot gather such information. Also as it is found that informal communication results into better productivity and solutions, when team members are at the same site , they come to know about each other by incident for example , at the canteen or some informal meetings. But in GSD , this is not possible between members over different sites. So this restricts the right impression formation , that could be individuated and hence result into more category based impression. Observing the above factors , the author presents a proposition , which says that distance result into decreased informal meetings and interactions , that can reult into wrong impression formation and hence effect the project. Also distance has a effect on motivation as when working in GSD, there is frequent need to interact or consult the member at different site. It make be possible that the person in power can be placed at a different site , and hence the members may not interact that frequently and also when they interact , it becomes difficult as they may not be aware of the member they need to communicate. Hence there can be situation of unequal power distribution in which case the impression so formed about the member is directly proportional to the type of communication that will be held between them. It might result into hesitation or incomplete information being gathered , which would demotivate the growth of the project as well as the impression formation of the team members. Hence the coworkers ,who are present at the same site with all the leaders and the managers tend to form more individuated impression about each other as compared to those who are collocated. Also it has been observed that when a project is developed globally, the teams at one site tend to treat the team at other site as differnt . There is always the scenario observed where the teams think that the other team is different from their own. Cultural differences plays an important role in such impressions being formed. The teams tend to compete with each other and lack socialization. This could be the result of lack of informal communication between the team members. Such conditions prevails the in-group/out-group categorization. Such categorization result into the impressions again being formed on category , this time the categorization could be based on false belief about the cultural a particular team belongs to.

Technology mediation is very common in GSD  as most of the interaction in the forms of meeting takes place through web or by the use of communication tools. The members of GSD rely heavily on technologies for their interaction and formal communication. This result into more of meeting formal communication and less informal communication between the team members. And hence the information gathered about each other in the technology mediated enviornment  gets effected due to high dependency on technologies for the discussion between team to take place. In such cases , there is lack of non-verbal communication between members , which would result into wrong information being conveyed across the team members , resulting into wrong impression formation. Also the information like the gestures, expressions  are not conveyed , therefore the impressions so formed will be less complex, but as the team members rely on what has been conveyed , the impressions formed are more intense in nature.

Heterogenity refers to the GSD team being comprising of members belonging to different cultural and of different skills and expertise.It also restricts the impression formation as there are members who might be very skilled particular field and might not understand other team member seeking help. And hence this result into wrong and category based impressions being formed about the other. This impacts the motivation of the correct impression formation of the members. Such conditions starts to frame impressions based on groups as discussed above. Team members start to believe that their groups are different and hence conclude to wrong impression formation which is mostly category based and less individuated as the particular attribute of the member like the expertise and skill may be percieve differently by other coworker.

Dynamic structure refers to frequent change in role of the members. The role of a particular member is volatile and changes frequently. For example a member may be a project leader of a particular project. But as when when the members of the project transit their impression about the project leader from category based to individuated impression , the project leader might get replaced by other. This again restricts the impression formation as by the time th impression gets refined , the person is changed and it gets fall back to category based for the new leader.

All these factors might effect the impression formation and hence have a effect on information and motivation, but there could be ways in which the impressions so formed can be refined by few facilitators like the travel, shared identity, use of electronic interpersonal information , expectation of future interaction ,sharing of contextual information .

Travel to various sites  should be arranged so as to make members aware of the context in which other collocated coworkers work. Travel also exposes members to different situations and different culture , which help them modify their preconcieve notions and impressions of the members at other site. Travel should be planned and everytime different members should be sent to different site so that all are exposed to the culture , context and situations of their collocated coworkers. This results into  better impressions being formed as they are based on contextual knowledge , culture, and situations and hence are individuated in nature.

Shared Identity refers to discussion about other members with  few members. As it has been observed that people react differeently at different situations, hence instead of forming wrong impression about a person belonging to different group or of different power , it is better to discuss about them , and refine the impression so formed. When the identity about a coworker is shared among members , it erradicates wrong impression so formed due to in-group /out-group categorization or due to unequal power distribution .

Electronic Interpersonal Information can be very useful to form better and individuated impression about the team members. This is because when teams share their views on blogs or other such medium , they tend to personalize the content, which reveals more information about a particular members,hence unleasing certain attributes of them that result in the formation of individuated impression.

Expectation of Future Interaction makes members gather more personal information of the member that expect a future interaction with . They tend to exchange more information , being informal and more personal . This result into again motivation for the coworkers to develop better understanding of each other and hence formation of more attribute based impression.

Sharing of contextual information results into context and situations the collocated coworkers are working on . This has a greater impact on the impression so formed as the team member are exposed to the context lik ethe software etc. used by them , and also the situtions. All these  result into attributes like the expertise ,skills being unleashed and hence more individuated impression formation.

Feedback and repair refers to the ability and the motivation for the impression so formed being refined. This can result into the impressions that were formed on category to be changed and formed on attributes. Hence feedback can help in impression refinement.As it has been noticed that the impressions once formed are hard to repair , but it could be done with effective and timely feedback. Hence the catefory based impressions can be repaired and more realistic and attribute based , that is depending on the skill and expertise on the person can be formed.

Impression accuracy should be achieved and hence impressions should be formed based on work style , expertise and contextual knowledge. When impressions are formed taking into account the work style , expertise and knowledge of the context , it would result into less bias and category based impressions being formed.

Behaviour of the members can be categorized to predictive and explanatory. When team members have formed impression , they are liable to predict the behaviour of other member , and also explain the behaviour. When wrong impressions are formed , then it becomes difficult to rightly predict and explain the behaviour of a member. This could also help in indicating the accuracy of the formed impressions.

Impression formation has a high impact on almost all the processes of GSD. It forms the foundation for the success of the project as when team members form individuated impressions about each other , they tend to communicate and coordinate far better then when wrong and category based impressions are formed. Hence impression formation is a continuous process of the process model adopted for the GSD. As studied , there is no such stage as the impression formation , still it begins as the project starts and is involved at all the points during the project. Impression formation plays an important role in carrying out the project as planned and achieving the motives.

A case study of globally distributed software development with A-Square project.

You can download the paper from here: A case study of globally distributed software development with A-Square project. - Paper
You can download the presentation from here: A case study of globally distributed software development with A-Square project. - Presentation

Implementation of Global software development : a Structured approach.

Abstract:

In Globally distributed software development (GDSD), People are separated over different locations of the world developing software together. The complexity dramatically increases due to the geographical, temporal, and socio-cultural distance. This paper identifies and analyzes problems that occurred in a GDSD project called A-SQUARE, which was carried out as a project-based course called practicum in the KAIST-CMU Master of Science in Information Technology - Software Engineering (MSIT-SE) program.
The three distance dimensions that should be managed to succeed in a project, and they are communication, coordination and control. Communication is the exchange of complete and unambiguous information, so the sender and receiver, both can have shared understanding. Coordination is the management of dependencies
among tasks for achieving a goal. Control is defined as the process of satisfying to goals, policies, standards, or quality level.

GDSD also has three major types of distance: Temporal, Geographical, and Socio-cultural.
Temporal distance is defined as a directional measure of the dislocation in time experienced by two team
members desiring to cooperate.
Geographical distance is a directional measure of the effort required for one member to visit another at the latters site.
Socio-cultural distance is defined as a directional measure of one members understanding of another members values and normative practices.

The paper discusses about a case study which achieved support from the strategies of GSD employed and evaluate for their usage of it.

Objectives of Paper:

1. The importance of strengthening of documentation (ex; ETVX with google docs) and SE PM technique (ex: wide band delphi estimation).
2. Selection of reducing dependencies among tasks by feature based assignment rather than layer based.
3. Understanding the importance of project management tools and technique for managing project artifacts.
4. Importance of documenting and tracking issues for effective sharing.
5. Importance of formal and informal communication for its much need coordination among different location team members.

Motivation for Paper:

1. Understanding the problems of Lack of project management, different cultures in communication and control dimension.
2. Understanding the difficulty in management of project artifacts at control dimension with increase in geographical and temporal distance.
3. Understanding the inefficiency of sharing issues, dealing with higher complexity tasks in collaboration dimension.
4. Evaluation of strategies employed are very necessary to achieve efficiency and increase productivity.
5. Need to evaluate the methods, processes and environments of software development for their effective use.

Lessons learned through the Paper:

           There are several points that can lead the success of GDSD projects and mitigated the effects of the problems by applying the strategies.
A. Team Building : Building cooperation and trust- enable team by making to learn backgrounds, which results higher productivity of project.
B. Secure Synchronous Communication Channel-Communication should be efficient and concise. The team members should analyze time differences among several separated sites and find overlapped hours to reach each other synchronously as a secure synchronous communication channel.
C. Follow-the-sun Approach- GDSD projects can make a good use of distributed sites time differences for boosting time-to-market of the project.

Concluding Remarks

In the paper, The problems that can occur in a GDSD environment are identified and also evaluated the strategies that the A-SQUARE team took to cope with them and discussed their effectiveness. The problems that can arise from the temporal, geographical and socio-cultural distance with the A-SQUARE project are also dealt in detail and solutions are put in place and evaluated for its effectiveness.

Implementation of Global software development : a Structured approach.

You can download the paper from here: Implementation of Global software development : a Structured approach. - Paper
You can download the presentation from here: Implementation of Global software development : a Structured approach.- Presentation

Implementation of Global software development : a Structured approach.

Abstract:

Globalization of software development is the strategy that organizations endeavoring to gain and maintain competitive advantage. This advantage is attributed to the benefits provided by labour arbitrage, which offers the opportunity for reduced development costs, which continues to be facilitated by the availability of well
educated and technically competent software engineers in low-cost centre's in Eastern Europe, Latin America, India and the Far East. The difficulties encountered include factors such as the problem of
understanding requirements, testing of systems, coordination, cultural and language differences, lack of communication, geographical and temporal distance from team members and the customer, different process maturity levels, development and testing tools, standards, technical ability and experience.

Distance has been identified as a key problem and by its very nature introduces barriers and complexity into the management of globally distributed projects
1. Geographical distance introduces physical separation between team members and management.
2. Temporal distance hinders and limits opportunities for direct con-tact and cooperation
3. Linguistic distance limits the ability for coherent communication to take place
4. Cultural distance negatively impacts on the level of understanding and appreciation of the activities and efforts of remote colleagues and teams Coordination, visibility, communication and cooperation are all negatively impacted with distance.

The paper explains the 10 key GSD factors needed to establish and facilitate the operation of globally distributed virtual teams. Each of these factors are implemented in five phases namely, Initiating, provisioning, establishing, managing, and leveraging.

Objectives of Paper:

1. To understand the opportunity for round the clock development facilitated by the temporal difference between remote development locations.
2. To come up with a strategy for the establishment, operation and the effective management of virtual software teams (GSD).
3. To understand the difficulties in GSD caused by cultural and language differences, lack of communication, geographical and temporal distance from team members and the customer, different process maturity levels, development and testing tools, standards, technical ability and experience.
4. Building up effective project management strategy, popular communication tool, effective coordination and control structure needed.
5. Achieving a motivated and cohesive team with a common purpose and shared goals and objectives in a globally distributed virtual team.

Motivation for Paper:

1. Understanding the GSD key factors enable us to achieve a simpler and structured approach in implementing GSD, which has complex barriers.
2. Change of Strategy in Implementation of an outsourcing needed than that of prior applying strategy of collocated software development.
3. Benefiting from competitive pricing and reduce time to market, thus enabling companies to compete more effectively in global market.
4. To study on facilitating collaboration and cooperation within the distributed team, Enforcement of trust between team members.
5. To study on the importance of investment in key infrastructure, pervasive risk management, investing time, effort and money in training.

Lessons learned through the Paper:

           There is a need to facilitate competitive pricing and reduce time to market, thus enabling companies to compete more effectively by gaining, expanding or maintaining their market share, when operating in what are increasingly dynamic and volatile markets.

The IDEAL-sm model presented a simple, but comprehensive framework on which the GSD Implementation Model could be based. The GSD Implementation Model had five phases with their constituent key factors. They are as follows:

INITIATING - Determine why, if and how the GSD approach is to be implemented.
1. Understand why and at what cost and risk the strategy is undertaken.
PROVISIONING - Ensure provision of effective infrastructure and documented process.
2. Provision of effective infrastructure, process and documentation
ESTABLISHING - Requirement to effectively establish the GSD teams.
3. Requirement to effectively establish the teams
MANAGING - Implementation of an efficient GSD project management strategy.
4. Implement an efficient distributed team project management strategy
5. Ensure the development of common goals, objectives and rewards
6. Need for the clear definition of roles and responsibilities
7. Address issues related to culture, communication, motivation and fear
8. Ensure provision of adequate training and knowledge transfer
9. Facilitate and monitor the operation of collaborative and supportive teams
LEVERAGING- Document and leverage lessons learned for existing and future projects.
10. Document and leverage lessons learned

Concluding Remarks

The GSD Implementation Model provides a process through which organizations can approach the implementation of a GSD strategy. Within its five phases it addresses the specific requirements of operating in a GSD environment,taking the ten GSD Key Factors which we identified into account. The required infrastructure, processes and supports are put in place, Senior management support, and an effective project management strategy based on the needs of the GSD environment is implemented. The documenting and leveraging of the experience gained during implementing is the key for long term success of this GSD approach.

Global software development in practice - lessons learned

You can download the paper from here: Global software development in practice - lessons learned - Paper
You can download the presentation from here: Global software development in practice - lessons learned - presentation

Global software development in practice - lessons learned

Abstract:

Organizations seeking lower costs and access to skilled resources began to experiment with remotely located software development facilities. This change is having a profound impact not only on marketing and distribution but also on the way products are conceived, designed, constructed, tested, and delivered to customers. As a result, software development is becoming a multi-site, multicultural and globally distributed undertaking.

This Paper explains types of Offshore Outsourcing and Offshore In-sourcing, factors and outcome with GSD trend. The paper also explains about other models namely Carmel (1999) model of software development for global teams, Evaristo (2003) model of distributed project, and a case study involving different stakeholders having differences in distance. Lessons were learned on the basis of case studies in two software development units from multinational organizations.

Under Carmel model for global teams, The centrifugal forces were loss of communication richness, coordination breakdown, geographic dispersion, loss of teamness and Cultural differences. The Centripetal forces were Development Methodology, Collaborative Technology, Managerial Techniques, Product Architecture, Team Building and Telecom Infrastructure.

The dimensions of distributed projects under Evaristo model were: Trust, levels of dispersion, Synchronicity, Complexity, Systems Methodology, Culture, Percieved distance, Policies and standards, type of projects and stakeholders.

Objectives of Paper:

1. Distinguishing GSD from normal (centralized) with respect to Software development.
2. Identifying the Strategic Issues, Cultural issues, knowledge management and technical issues effected by distance, time-zone and culture changes.
3. Understanding the Centrifugal and Centripetal forces involved in the Carmel's Model of Software development for the global teams.
4. Discussing and managing of the critical problems associated with model of Dimensions for Distributed projects (Evaristo).
5. Finding Solutions for identified problems with focus on technical (or, and) non-technical dimension. ( starting from planning to Integration phase).

Motivation for Paper:

1. The business market proximity advantages, including knowledge of customers and local conditions favor GSD to have footprint globally.
2. Pressure to improve time-to-market by using time-zone differences in round-the-clock development favor quick product delivery and low costs.
3. Cost-competitive global resource pool, wherever located need to be used successfully.
4. The need for study on work standardization, investment in planning, process engagement, and continuous risk management can be solutions.
5. Exploring the effectiveness of leadership, communication, culture,context sharing, project management, and technical training.

Lessons learned through the Paper:

           As the software community appreciates the economy of merging diverse development skills and domain expertise and as communication media become more sophisticated, the cost and technology
pressures push more organizations toward GSD. The Author describes 8 lessons that can be learnt from this paper. They are:

Lesson 1: Project management and, in particular, risk management need additional effort and steps.
Lesson 2: The existence of a well-defined software development process is responsible for many advantages in distributed projects.
Lesson 3: Knowledge management stimulates the information sharing and stimulates the learning from experience.
Lesson 4: Requirements engineering is the main challenge for the software development process point of view.
Lesson 5: The planning phase is important to organize and manage the distributed projects properly.
Lesson 6: The investment in recruiting and training global teams can minimize the difficulties related
to the nontechnical dimension.
Lesson 7: Tools can act as a facility in the distributed interaction.
Lesson 8: Distributed Software Development is a maturity process

Concluding Remarks

The existence of a formal software development process, Large investments in training resulting in improved relationships, Process engagement, Integration activities improved soft skills of individuals, increasing trust and minimizing cultural differences resulting in improved the communication and feedback. The search for greater formalism and the selective utilization of international patterns will provide full conditions to overcome the problems originating from the dispersion of software development, with support from communication techniques, primarily e-mail, conferencing. The challenge in GSD is to create strategies, techniques and practical lessons from experience to alleviate such problems.

Global Software Engineering and its Challenges

You can download the paper from here: Päivi Parviainen - Global Software Engineering and its challenges
You can download the presentation from here: Global Software Engineering and its Challenges

Global Software Engineering and its Challenges

Abstract:

Global Software Engineering means product-development activity that involves two or more companies, departments or teams that combine their competencies and technologies to create new shared value while, at the same time, managing their respective costs and risks.

Global Software Engineering has a number of potential benefits, including
• Shortening time-to-market cycles by using time-zone differences.
• Improving the ability to quickly respond to local customer needs.
• Organizations benefit from access to a larger qualified resource pool with the promise of reduced development costs.
• Innovation, as the mix of developers with different cultural backgrounds may trigger new ideas.
• To reduce development costs, to acquire competence (technology competence or knowledge of a specific market)
• To avoid investing in a company's non-core competence areas.

The general risks mentioned in the Paper are:
• had to do with the openness of communication between partners; for example, problem-hiding may be an issue in customer supplier relations.
• Furthermore, unclear assignments, lack of trust between partners, difficulties in agreeing on intellectual property rights and the unreliability of the partners development schedule were seen as risk factors for any mode of collaboration.
• From the suppliers or licencor's viewpoint, the risks mentioned concerned the continuation of the collaboration in the future and predicting the most sale-able product features correctly during road-mapping.
• From the customers point of view, the quality of the acquired product (e.g.,reliability and performance) and becoming too dependent on one partner were seen as risks.
• Finally, competence issues such as the competence of new partner's and a weakening of ones own competence were also mentioned as risks.

Objectives of Paper:

1. It talks about various GSE interaction modes like Hierarchical, Swap meet, Asymmetrical and Dialogic.
2. It describes about mode of collaboration : 1. Equity and non-equity. 2. Upstream, horizontal and downstream. 3. Dyadic alliances, alliance constellations and alliance networks. 4.Explorative and exploitative.
3. Capturing the industrial views under Contracting and requirements definition, Project planning and tracking, Architecture analysis/design, Integration and testing, Co-operative work.
4. It talks about modes for coordinating R and D work across multiple sites like Functional areas of expertise, Product structure, Process steps, Customization.
5. Root causes of challenges into Basic Circumstance, derivative cause and Consequent Cause.

Motivation for Paper:

1. As World market is getting closer day by day, It is necessary to understand the benefits and risks involved in Global software engineering.
2. Detailed viewpoint of the stakeholders involved can help to understand the challenges at the root level and help to solve it at lower level, thus not eliciting such problems to the higher level of decisions.
3. This paper is a step towards better, more productive and higher quality GSE, as it helps companies to be aware and address potential challenges early via the GSE framework.
4. Although GSE is common, it is still challenging and companies should carefully weigh the benefits and costs of doing the work in distributed setting vs. doing it single site.
5. Analyzing the problems in more detail helps to improve situation that can be implemented in practice. Under the current market pressures, companies need to use their existing resources(also global resource and expertise pool) as effectively as possible.

Lessons learned through the Paper:

           For a successful implementation of any project, It is very necessary to carry out background knowledge, survey to better understand the scenarios that can come across. Hence, better preparation of solutions can be implemented to minimize the risk and to increase benefit to cost ratio. 

The risk associated with GSE are: Project-delivery failures, Insufficient quality, Distance and culture

clashes, Staff turnover (mostly for captive centre's), Poor supplier services (only for outsourced GSE), Instability with overly high change rates, Insufficient competences, Wage and cost inflation, Lock-in (only for outsourced GSE), Inadequate IPR management etc.

The top-five challenges for GSE were effective communication, cultural differences, coordination, time-zone differences and trust.

The reasons or causes for these Challenges are: Communication breakdown (loss of communication richness), Coordination break-down, Control breakdown (geographical dispersion), Cohesion barriers (loss of teamness) and Culture clash (cultural differences). 

The root causes can be classified into:

1. Basic Circumstances: Caused by Time difference and distance, Multiple parties/ Stakeholders. 

2. Derivative Cause: Lack of communication, communication breakdown, different backgrounds and tacit knowledge. 

3. Consequent Cause : Lack of Teamness, Trust.

Concluding Remarks

In Today’s market, the increasingly complex and competitive market situation has resulted in Global Software Engineering (GSE) becoming more and more common practice. Companies need to use their existing resources as effectively as possible.They also need to employ resources on a global scale from different sites within the-company and even from partner companies throughout the world, in order to produce software at a competitive level.Thus, the ability to collaborate effectively has become a critical factor in today’s software development.

The main expected benefits from GSE are improvements in development time, being closer to the customers and having flexible access to better specialized and less costly resources. Main reasons behind this productivity drop are misunderstood or mismatched processes between teams, and poor visibility into and

control of the development activities atall sites involved. This paper helps us to understand and improve the situation that is in practice in companies.

Experiences adopting an integrated gsd infrastructure

Abstract:

In this paper the author states how using only a particular tool and/or process is not much useful, Instead an augmenting set of tools and processes can be used and effect GSD in a positive manner.Tools in GSD toward integrated solutions that attempt to cover the full range of needs of distributed projects. The proper usage of tools will help in: Decoupling of work, give importance of unplanned and informal communication, ensure project management must be more flexible and more rigid. The various risk factors were studied by surrogating the project to student simulation teams. This paper describes the tools and processes developed, and insights gained from applying them to the GSP

Discussion:

The global Software Project (GSP) was split into two distinct years with a particular set of student teams being involved for one year. For the second year the infrastructure and processes were refined to address the issues experienced and lessons learned during the first year. Findings have been separated into themes that ended up being central in this project in one way or another. Set of finding were done to understand the issues of GSD concerned to centralized management, information and awareness, iterative development process, and balancing of formal and informal specialization.

A set of issues related to the findings were noticed during the the first year of software development, they were:

• Unclear process communication
• Inconsistent communication from the supplier manager
• Centralized Management and infrastructure problem
• Frequent re-planning required
• Interdependence of tasks not well understood
• Work assignment not easily understood
• Integration test were not easy to execute
• Issue with formal specification language like the UML diagram (issues like: different interpretations, machine friendly, etc..)

To tackle with those issues, a set of possible solutions were proposed int he second year of the GSP, they were:

• Maintain consistent communication with remote team by suing tools like MediaWiki
• The project should be transparent to all the people working on the project rather than specific to a individual person his module
• Keep a mandatory central version control than that of distributed version control system
• Put more upfront effort to better understand the needs and requirements of the project by using UI mockups, understanding the dependencies between different views
• Improved tools support by using Wiki updates, traceability matrix. It was observed no explanations were required after the first iteration
• Enable proper awareness to ensuring consistent understanding
• Maintain consistent communication
• Make every person of a team participate in the project
• Apart from UML specification, provide text based specification to the project.  

The paper was trying to summarize:

1. Try to introduce more informal communication techniques
2. Project management should be more flexible and rigid Eliminate the source of problem
3. Put more efforts in the early stages to avoid many problem like re-plan, re engineering, etc..
4. Make people more aware of the work and kind of work
5. Understand the technical and requirement bridge

Planning and improving global software development process using simulation

Abstract:

      Global software development (GSD) is highly dominant in almost every growing firm over the world. It has various advantages like reduction in development cost , time , etc. . and disadvantages like distance, language, etc. . For GSD model to be successful, it should Incorporate new processes, methods, tools and software development operations. A strong project plan should be followed by proper management tracking and control. One way to ensure this by software process simulation model (SPSM). SPSM is used to improve GSD processes and support the organizational decision-making by creating a software process simulation, hence figuring out the bugs in the decision making face, thereby reducing cost of non quality. The paper propose hybrid simulation model combining system dynamics and discrete-event models is needed to effectively model GSD projects to increase the productivity.

 

Discussions:

 

      The Paper proposes three sub-models in the simulation model. The three major components were Discrete even sub-model, System dynamics sub model, Interaction effect sub-model. The discrete event sub-model addresses different process steps depending on task allocation strategy a development site may have. the System dynamics sub-model deals with the dynamic nature of global software development. The interaction effect sub-model show the interaction effect when the staff from distributed teams collaborate or communicate. Main concentration was given to the Interaction effect sub-model as communication plays a crucial role in GSD environment. The IE sub-model calculates the coordination efficiency of the distributed team (relative to single site coordination) and then applies the coordination effect to the productivity before sending it to the DES sub-model. As observed productivity is directly proportional to Coordination effect. There are two more major factors that determine the coordination efficiency: Communication frequency and Trust .

     Communication is extremely important in GSD. The IE sub-model will determine the relative frequency of communication when team members are at different sites compared to when they are at the same site. The relative communication frequency has a positive impact on productivity. Distance between the team members has negative effect on Communication frequency.

The other most important factor which was notes was trust. Trust has a positive impact on coordination, Teams with higher trust tend to coordinate better, thus achieve better performance which require cooperation and interdependence. Trust is has a Negatively impact on cultural differences, Positive on Familiarity and Positively on Meetings.

      GSD SPSM helps in project planning activities (like: Which development site should be included in the project?). It also helps in Software process improvement (i.e. The project manager can compare the current performance (as-is) versus the expected performance after the improvement (to-be) and then decide whether or not to implement the change).

      Based on a sample simulation of two real time GSD projects observation was made on efforts, quality, and duration. Efforts had inverse relation on duration and a direct effect on quality was the observation made.

      In this paper, it was shown how GSD model that features an innovative hybrid architecture which combines the system dynamics paradigm with the discrete-event paradigm. The hybrid feature allows the GSD model to better represent the GSD project. It is believed that such a model can be used as a decision support tool to help project managers plan, manage, and improve global software development process.

 

Improving validation activities in a global software development

Abstract:

        Compared to the traditional software development global software development posses a large risk and error prone development. That is due to lack of proper communication, interaction, cultural effects, and lots more. This obviously impacts a great amount of organizations resources. To overcome with that problem, and issues its important to take early measure by introducing proper validation in the system. In this paper validation activities in a global setting within Alcatel's Switching and Routing business was studied. The author of the paper proposed 3 hypotheses for cost reduction by earlier defect detection and less defects introduced. The propositions were 1. Collocating peer reviews 2. Effective process coaching 3. Introduction of Teamwork and Continuous build. The challenges addressed with these hypothesis were to support validation in a global product line concept, to facilitate early defect detection with an improved validation process, and to reduce overall cost of non-quality (cost of rework) 

Discussions:

        As per the study made in the paper, introducing some changes towards improving the sense of responsibility for end results, it is possible to keep quality and productivity standards and to improve performance even with this changing work environment. With the attention on collocating peer reviews, embarking on better process coaching, and introducing incremental build principle into the projects, it is possible to improve cost of non-quality by a factor of over 50% . Although the direct impact is visible on defects and quality level, it is possible to achieve both cost and cycle time improvements. This is obvious if teams are encouraged to focus on the right quality level as long as they are in full control of the results, and not to wait until the next project phase.

          Summarize the overall practices related to improve validation activities, which were identified over the past years that clearly support global software development:

•  Communicate at project start the respective project targets to reduce the cost of non quality
• Make teams responsible for there results (expose them to the project environment and set up, rather than simply doing some module)
• Define at the beginning which teams are involved in what activity at which location 
• Setting up a project homepage for each project that summarizes project content, progress metrics, planning in-formation, and team-specific information 
• Collocates as much as possible 
• Provide necessary coaching 
• Provide necessary tools and technologies 

            Collocating peer reviews improves both efficiency and effectiveness of defect detection and thus reduce cost of non-quality. Providing a certain level of coaching within the project reduces cost of non-quality. Re engineering the development process towards team-work and continuous build allows to better managing glob-ally distributed projects, and thus reduces cost of non-quality.

Does Distributed Development Affect Software Quality? An Empirical Case Study of Windows Vista

Christian Bird, Nachiappan Nagappan, Premkumar Devanbu, Harald Gall, and Brendan Murphy.
Does distributed development affect software quality?: an empirical case study of Windows Vista.
Commun. ACM, 52(8):85–93, August 2009.

View the paper here.
View the presentation here.

Abstract:-

    This paper tries to analyze the effects of distributed development over collocated development. The case-study taken is of the product of Microsoft Vista. Some of the authors of this paper are the developers and researchers from Microsoft and they have good idea what happened during the development of Microsoft Vista. The authors are trying to assess where more number of failures occurred, was it in development of files being developed in distributed manner or in collocated manner. So this paper is about analyzing post-release failure components. The authors have found almost negligible differences in case of the failure rate between distributed development and collocated development. The authors have also contrasted why the differences was so little when it was likely that failure rate of distributed development should have been quite high. The authors have also spoken a little about Microsoft’s approach to achieve proper global software development.

Discussions:- 

    The authors are making a pioneering approach in a study which is first of its kind that distribution development has been divided into multiple levels of separation like building, campus, continent, etc., the software to be studied is composed of thousands of executables, libraries and thousands developers, individual files among these thousands of files have been characterized numerically with different quality attributes and the developers involved in the project are quite skilled and have years of experience in their domain.

    The authors have divided the distribution into various types. The first type of distribution is of building. A file classified at the building level may have been worked on by developers on different floors of the same building. Developers who work in the same building will enjoy more face to face and informal contact. The second type of distribution is of cafeteria. In Microsoft, a cafeteria can be seen between one and five nearby buildings. Developers who belong in this set of buildings are said to have developed the file in cafeteria distribution. Developers may share meals together and meet by chance during meal times. The third type of classification is of campus. A campus represents a group of buildings in one location. The fourth type is locality. This refers to different campuses present in a city or group of adjacent cities. The fifth type is continent. Whichever campus falls in the geographical landmass of same continent, fall under this category. The last is of world. This consists of collection of continents. A file is assigned the lowest level in the hierarchy from which at least 75% of the commits were made. Commits are made after significant amount of change has been done in the code or some function point has been added in the code.

    The Microsoft architects had distributed the work in a manner such that majority of the work being done was at hierarchy of building level. The total number of files being developed came up to 68 percent. Now, with analysis done by Mann Whitney test it was found that on an average, only 8 percent more failure rate is found in files being developed in distributed manner. Further analysis revealed that if number of developers are non-uniformly distributed with different distribution of work happening in different teams, this error rate can be brought down to 4.6 percent. When analysis was done for different levels of distribution, it was found that at continent level the error rate is lesser than the error rate of collocated development.

     To investigate this peculiar behavior, the authors studied the various characteristics of the files present in Microsoft Vista. They studied the characteristics of size, complexity, code churn, test coverage, dependencies and people involved in the project. It was found that the files developed in distributed manner were less complex, had less code churn and had fewer dependencies than collocated files.

     Authors also spoke about the approach taken by the Microsoft to improve global software development. Microsoft treats all its employees equally and hence there is usually no negative competition spirit among different team members. So there is a good relationship among different sites. Microsoft tries to reduce the cultural barriers among the different teams by promoting tours to different sites across different parts of the world, so that employees understand the cultures, ethics and behavior of their compatriots in other parts of world. Microsoft encourages its employees to stay in touch with different employees present in different parts of world and hence takes care that synchronous communication happens among different sites. Microsoft employs only one type of configuration management tool so that similar process is performed in all the sites. Every file has a defined owner in Microsoft who is responsible to see that file falls under correct hands in different phases of development lifecycle of the product. Microsoft keeps common schedules of deadlines across all its sites. Microsoft keeps organizational integration by keeping managers at the same site so that face to face communication takes place between their managers.

    It is desired that when files are going to be developed at distributed level, it is necessary that file is having less complexity, less code churn and has fewer dependencies. If good software engineering practices are employed, distributed development is as good as single-site development. An organizationally compact but geographically distributed project would be better than a geographically local, organizationally distributed project.

Globally Distributed Software Development Project Performance: An Empirical Analysis

Narayan Ramasubbu and Rajesh Krishna Balan. Globally distributed software development
project performance: An empirical analysis. InESEC-FSE’07, Cavtat, Croatia, September 2007.
ACM.

View the paper here.
View the presentation here.

Abstract:- 

    This paper is about the effect on productivity of employees and quality of code when development takes place in a distributed manner. The paper is based on results of an extensive two year done by the authors. They first develop a model of distributed software development to study the impacts. The model is highly a mathematical based model with the use of several concepts in it. The authors make use of a company which has obtained the rating of level 5 in capability maturity model (CMM). The unnamed company worked on a total of 42 projects for the two years and all the quality attributes obtained in these projects were given as input to the mathematical model developed by the authors. The results obtained by using the parameters of quality attributes were tested for its validity using different types of validation tests. These validation tests gave good results to the model so that model could be used at any place where the scenarios are similar to that of studied company. The results obtained by this mathematical model were that the dispersion effect had the impact on productivity of employees and quality of code.

    To counter these negative effects, several steps have to be adopted. All these steps were based on following good software engineering practices throughout the lifecycle of the product development. The authors have classified these practices into three approaches oriented on prevention basis, appraisal basis and failure basis. Each of these approaches has its own significance in its way in some part of the development phase of the project. The authors observed that when the practices in a company are oriented towards the above mentioned approaches, the company does well to mitigate the effects of dispersion on productivity of employee and quality of code and on the contrary, even improves the performance better than collocated development.

Discussions:-

    

     We learnt about the creation of a model from scratch and what elements is author considering in construction of it. At first, author considered all the factors affecting software development. First factor is work dispersion for which author had made use of Herfindahl-Hirschman index to obtain a numeric value of work dispersion. The other factor is a collection of approaches which the author describes are necessary to be followed by the companies working in dispersed manner. The first approach is of prevention-based which speaks about the various types of training an employee has to undergo before working on a project and various types of configuration management, task planning and scheduling processes. The second approach is of appraisal-based which speaks about practices to be followed while project is ongoing like review, inspection etc. The last approach is of failure-based which talks about various practices to be followed once the project is in the completion stages like testing, error tracking and correction.

    The model consists of two indicators that is development productivity and conformance quality. Then there are five types of control variables which are team size, code size, reuse, upfront investment and design rework. Some of these control variables are dependent on development productivity or conformance quality or both. The model tries to establish the relation between these factors affecting software development, indicators and control variables. The relation is about establishment of two equations of indicators in terms of functions as of above entities.

    The obtained model’s coefficients are obtained by making use of empirical data obtained from an unnamed CMM level 5 company’s quality attributes and other parameters. Durbin-Wu-Hausman endogenity method of two-stage least squares test is used to obtain these coefficients. The significance of the obtained model with coefficient value is tested by making use of two-tailed hypothesis test. The validity of the whole model on the whole was tested by making use of F-Test. Both the validity tests gave positive results signifying the model obtained is mathematically correct.

    Then using the values from the model, it was established that productivity of employees decreases with increase in dispersion and productivity of employees has an inverse relation with quality of the code. The values obtained in model also denoted that increase in appraisal-based and failure-based approaches will help to reduce productivity loss caused by dispersion. The model also indicated that more failure-based approaches will help to increase the quality of the product.

     The main concluding remark will be stated as dispersion significantly reduces development productivity and has effects on conformance quality. But these negative effects of dispersion can be significantly mitigated through deployment of structured software engineering processes in terms of various types of approaches described by the authors. Companies when going for distributed development have to account for the inevitable loss in productivity and quality when deciding to move software production to a second or third location to reduce labour costs, etc. The model results suggested that companies that institute high quality software processes are far more likely to overcome the effects of dispersion than companies that don’t.