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.