Offshore Challenges Affecting Coding Phase

As mentioned in an earlier post that there are four key challenges in offshore software development such as Trust, Socio-cultural, Communication and Coordination and Knowledge Transfer

In this blog  we have addressed how these challenges effect the coding phase of software development.

Trust: 

Insufficient social integration can degrade the performance, lower motivation and satisfaction of the developer. Resulting in creating mistrust between the client and the development team (Koehne et al., 2012). 

Socio-Cultural:  

Due to cultural differences, developers often misinterpretation each other, causing wrong requirements to be coded (Herbsleb et al., 2005). 

Misinterpretations of technical vocabulary due to dissimilarity in technical cultures causes misunderstanding, rework and consequently delays in the projects (Herbsleb et al., 2005). 

Developers at remote sites, insufficient use version control systems due to different organisational cultural habits (Cataldo et al., 2007).

Developers belonging to higher economy countries usually do not help people belonging to low economy countries in fear of losing their jobs to them (Bird et al., 2009).

Communication and Coordination: 

Usage of different process and disparity in process maturity at different sites can cause coordination problems (Bird et al., 2009; Herbsleb et al., 2005). 

Staff members at new offshore sites have a tendency to not reply quickly to emails of onshore members (Herbsleb et al., 2005).

·   Communicating all the details and norms of the process to be followed to remote teams is very time consuming (Mullick, et al., 2006). 

      

      Knowledge Transfer: 

      

   Difficulties in tracking information in distributed development (Herbsleb et al., 2005; Koehne et al., 2012). 

       

    Divergence in tools usage among different teams cause knowledge transfer problems (Bird et al., 2009) 

Reference: 

Bird, C., Nagappan, N., Devanbu, P., Gall, H., and Murphy, B. (2009). Does distributed development affect software quality? An empirical case study of Windows Vista. In Proceedings of the 31st International Conference on Software Engineering (ICSE '09). IEEE Computer Society, Washington, DC, USA, 518-528. 

Cataldo, M., Bass, M., Herbsleb, J.D., Bass, L. (2007). On Coordination Mechanisms in Global Software Development. In Proceedings of the International Conference on Global Software Engineering (ICGSE '07). IEEE Computer Society, Washington, DC, USA, 71-80.

Herbsleb, James D., Audris Mockus, Thomas A. Finholt, and Rebecca E. Grinter (2001). "An empirical study of global software development: distance and speed." In Proceedings of the 23rd international conference on software engineering, pp. 81-90. IEEE Computer Society, 2001.

Kausar, Maryam and Adil Al-Yasiri (2015).“Distributed Agile Patterns for Offshore Software Development” 12th International Joint Conference onComputer Science and Software Engineering (JCSSE), IEEE 2015 

Kausar, Maryam, and Adil Al-Yasiri. "Using Distributed Agile Patterns for Supporting the Requirements Engineering Process." In Requirements Engineering for Service and Cloud Computing, pp. 291-316. Springer, Cham, 2017.

Koehne, B., Shih, P.C., and Olson, J.S. (2012). Remote and alone: coping with being the remote member on the team. In Proceedings of the ACM 2012 conference on Computer Supported Cooperative Work (CSCW '12). ACM, New York, NY, USA, 1257-1266.

Mullick, N., Bass, M., Houda, Z., Paulish, P., and Cataldo, M. (2006). Siemens Global Studio Project: Experiences Adopting an Integrated GSD Infrastructure. In Proceedings of the IEEE international conference on Global Software Engineering (ICGSE '06). IEEE Computer Society, Washington, DC, USA, 203-212.

Offshore Challenges Affecting Design Phase

As mentioned in an earlier post that there are four key challenges in offshore software development such as:

• Trust
• Socio-cultural
• Communication and Coordination
• Knowledge Transfer

In the presentation below we have shown how these challenges effect the design phase of software development.

Reference: 

Bosch, J., and Bosch-Sijtsema, P. (2010). From integration to composition: On the impact of software product lines, global development and ecosystems. J. Syst. Softw. 83, 1 (January 2010), 67-76

Cataldo, M., Bass, M., Herbsleb, J.D., Bass, L. (2007). On Coordination Mechanisms in Global Software Development. In Proceedings of the International Conference on Global Software Engineering (ICGSE '07). IEEE Computer Society, Washington, DC, USA, 71-80.

  

Clerc, V. (2008). Towards architectural knowledge management practices for global software development. In Proceedings of the 3rd international workshop on Sharing and reusing architectural knowledge (SHARK '08). ACM, New York, NY, USA, 23-28. 

Herbsleb, James D., Audris Mockus, Thomas A. Finholt, and Rebecca E. Grinter (2001). "An empirical study of global software development: distance and speed." In Proceedings of the 23rd international conference on software engineering, pp. 81-90. IEEE Computer Society, 2001.

Jaakkola, H., Heimbürger, A., and Linna, P. (2010). Knowledge-oriented software engineering process in a multi-cultural context. Software Quality Control 18, 2 (June, 2010). 299-319.

Kausar, Maryam and Adil Al-Yasiri (2015).“Distributed Agile Patterns for Offshore Software Development” 12th International Joint Conference onComputer Science and Software Engineering (JCSSE), IEEE 2015 

Ovaska, P., Rossi, M. and Marttiin, P. (2003). Architecture as a coordination tool in multi-site software development. Softw. Process: Improve. Pract. 8(2003) 233–247.

Sengupta, B., Chandra, S., and Sinha, V. (2006). A research agenda for distributed software development. In Proceedings of the 28th international conference on Software engineering (2006). ACM, New York, NY, USA, 731-740. DOI=http://doi.acm.org/10.1145/1134285.1134402. 

Research Methodology

Research methodology can be defined as something people undertake in order to find out things in a systematic way thereby increasing their knowledge (Saunders et al., 2007).  There are many ways in which research methods can be explained. 

The research onion was developed by Saunders et al. (2007) to illustrate the stages that must be covered when undertaking research. Each outer layer in the research onion describes a more detailed stage of research process and contains different ways in which a layer of research can be conducted. This approach provides an effective progression through which a research methodology can be designed and its usefulness lies in the fact that it can adapt to almost any type of research methodology and can be used in a wide range of contexts (Bryman, 2012).

The presentation below shows each stage of the research onion: 

Reference:

Bryman, Alan (2012). Social research methods (5th ed.). Oxford: Oxford University Press.

Flick,Uwe. (2011). Introducing research methodology: A beginner's guide to doing a research project. London: Sage.

Goddard, W. & Melville, S. (2004). Research Methodology: An Introduction, (2nd ed.) Oxford: Blackwell Publishing.

Hussey, Jill, and Roger Husse (1997)y. "Business research." Hampshire: Palgrave(1997).

May, Tim (2011). Social research. McGraw-Hill Education (UK), 2011.

Saunders, M., P Lewis (2007)- Research methods for business students, 2007

Yin, R. K. (2003) Case Study Research Design and Methods, Thousand Oaks, 3^rdEdition, Sage Publications, Inc. 

Offshore Challenges Affecting Requirement Phase

There are four key challenges in offshore software development such as:

• Trust
• Socio-cultural
• Communication and Coordination
• Knowledge Transfer

In the presentation below we have shown how these challenges effect the requirement phase of software development.

References:

Alnuem, Mohammed Abdullah, Arshad Ahmad, and Hashim Khan (2012). "Requirements Understanding: A Challenge in Global Software Development, Industrial Surveys in Kingdom of Saudi Arabia." In 2012 IEEE 36th Annual Computer Software and Applications Conference, pp. 297-306. IEEE, 2012).

Berenbach, B. (2006). Impact of organizational structure on distributed requirements engineering processes: lessons learned. In Proceedings of the 2006 international workshop on Global software development for the practitioner (GSD '06). ACM, New York, NY, USA, 15-19. 

Bhat, J.M., Gupta, M., Murthy, S.N. (2006). Overcoming Requirements Engineering Challenges: Lessons from Offshore Outsourcing. IEEE Softw. 23, 5 (September 2006), 38-44. 

Bird, C., Nagappan, N., Devanbu, P., Gall, H., and Murphy, B. (2009). Does distributed development affect software quality? An empirical case study of Windows Vista. In Proceedings of the 31st International Conference on Software Engineering (ICSE '09). IEEE Computer Society, Washington, DC, USA, 518-528. 

Damian, Daniela E., and Didar Zowghi (2003). "RE challenges in multi-site software development organisations." Requirements engineering8, no. 3 (2003): 149-160.

Herbsleb, James D., Audris Mockus, Thomas A. Finholt, and Rebecca E. Grinter (2001). "An empirical study of global software development: distance and speed." In Proceedings of the 23rd international conference on software engineering, pp. 81-90. IEEE Computer Society, 2001.

Niazi, M., El-Attar, M., Usma, M., and Ikram, N. (2012). GlobReq: A framework for improving requirements engineering in global software development projects: Preliminary results. In proceedings of the 16th International Conference on Evaluation & Assessment in Software Engineering (EASE 2012). (May 14-15, 2012) 166-170.

Sengupta, B., Chandra, S., and Sinha, V. (2006). A research agenda for distributed software development. In Proceedings of the 28th international conference on Software engineering (2006). ACM, New York, NY, USA, 731-740. DOI=http://doi.acm.org/10.1145/1134285.1134402. 

How to decide on a research topic for your PhD?

This video will give you an overview of 3 key steps that will guide you on deciding your PhD topic.

Tips for Preparing for PhD Viva

Well.. now since I have been through that hell and seen a lot of my fellow researcher go through it, I can share things that helped make that process painless and actually an experience that I ended up really enjoying.   

So here are some tips that I would  recommend anyone who is preparing for their viva should consider:

• Look up recent publications of your external supervisor and think of ways how you can link it with your work so that the examiner knows that you have done the background work which is expected from a PhD researcher.

• Prepare the basic questions that are always asked in a viva, my university had a template of the frequently asked questions, so I'm assuming most universities have one too and if you don't have one, just ping me, I'll share the document given to me by my university with you.

• Read your complete thesis again a week before going into the viva and make sure if you have identified a typo or error you make a list of them and take it with you in the exam so that you can inform the examiner that you have already noted that mistake and intended to fix it in the final version.

• An important tip given to me by my supervisor was to again search for new articles that might have been published once you have finalised your results and make sure to prepare a valid argument on how they may or may not effect your main contribution. 

• Lastly, its always good to have one or two articles published before your viva and if you haven't been able to publish, at least make sure you have sent a paper to be published before your viva so that you can say that your paper is currently under review and will be published soon. 

If you have any more questions let me and I'm looking forward to answering them. 

Tips on how to clear PhD Proposal Defence

I went through my PhD proposal defence this February so I would like to share things that worked for me:

i) Your supervisor should be happy with your work.
ii) Do not go into an exam until your supervisor says you are ready.
iii) Question all your work. Why do you think your work is finished?
iv) Your hypothesis should be clear. You must have a reason for why you think that your solution is correct.
v) Be confident and smile, trust me it helps a lot.
vi) If you are wrong, accept your mistake and convince your examiners that you will fix it.


Conclusion: Your supervisor is happy you will pass else you are in trouble. Good luck