I have been teaching students Global Software Engineering (GSD) since 2006, and more and more I realize that the learning I am trying to create in the classroom is not related to technical skills at all. It is about discovering yourself. Very few problems in GSD are of technical nature. Advances in distributed version control and integrated collaborative development environments have made most of technical issues conquerable. It is about how these infrastructures get used by people in different parts of the world, with different styles of work and communication, but more interestingly, different expectations of success and of others. In a recent course I run at the University of Victoria in collaboration with the Finnish Aalto University — see here for a slide deck outlining our great GSD experience — I had the incredible experience that any teacher is hungry for: a student’s reflection on what learning GSD meant for him. Although my intention was to facilitate the UVic students’ international collaboration with the Finnish students, our UVic class was international in itself and we had many great discussions of what working in an international team really meant. In very few classes we get the chance to really reflect on our experiences and learning, and we had many opportunities to share the good and the hard. Trust, large time zone differences and teamwork were among the few things that we talked in almost every class. My student’s report — a reflection from a reserved person most often not able to contribute to what were felt as advanced discussions, though his report is very telling about his learning — highlights in fact why collaborating across borders (whatever they are: physical, cultural, emotional, ideological) is important to (re-)discover oneself: where one comes from, how one approaches particular challenges and how one is willing to search for solutions. It reminded me, once more, how much I… read more →
The SEGAL lab received great news yesterday: one of the three smartphones that our ToTEM system was implemented on survived being capsized! We have yet to determine what data survived on the smartphone. However, a recent project by Angela Rook determined that it is possible to get strong results through data mining with a subset of even just 15 days of consistently collected data. Given that the rowers of OAR Northwest were on the water for 73 days, we have high hopes that we will be able to extract sufficient data for statistically significant research results. We are so grateful to OAR Northwest for recovering this smartphone for us. We are excited to examine the data collected when it arrives at the Lab. Adam Kreek was interviewed on Friday by CBC after he arrived back in Victoria. If you would like to see the interview, please click here.
One of the most intense and enjoyable events last year was the Ready-set-transfer panel (or: show) at Requirements Engineering Conference. I had the pleasure to present my work on the V:issue:lizer and to argue why I think it was ready for transfer into industry. The following video* (1:46 min) was part of my pitch on why the V:issue:lizer is relevant for software development: So how can the V:issue:lizer help in this situation? Let’s first look on the visualization of the clarification trajectory derived from the discussion in the video (see a transcript in the making of section below).
Although we designed V:issue:lizer as a research tool, we think that it is also a good prototype for tool support for managers that need to deal with information overload in distributed software projects. We demonstrate this in a short video (5 min).
This poster was presented at REFSQ’12 in Essen, Germany and highlights our vision for this project: investigating patterns of requirements related discussions that can help projects continually monitor the health of requirements-driven collaboration. Introduction Effective collaboration during Requirements Engineering is essential for project success and includes the discussion and negotiation of requirements with dierent stakeholders, deriving, assigning, and scheduling tasks and subtasks from these requirements. Problem: Existing requirements management tools offer limited support. Practitioners rely on a combination of collaboration tools such as email and issue-trackers. No overview of the state of the requirements-related discussion. Lost opportunity in leveraging the wealth of requirements-related communication data available in projects. Research Goal In our research we aim on investigating patterns of requirements related discussions that can help projects continually monitor the health of requirements-driven collaboration. Research Method Based on a framework for analyzing requirements-driven collaboration , we offer to analyze requirements-driven communication by developing stakeholder requirements centric social networks (RCSN). Based on our ability to automatically detect requirements clarication in this communication (by using machine learning, c.f. ), we can identify patterns of requirements clarication. Anticipated benefits for software engineering practice Support for Seeking Domain Experts as well as Technical Experts Identifying the brokers of requirements related information to make project managers aware of critical people in a project Assessing the health of requirements and their development. References Damian, D., Kwan, I., Marczak, S.: Requirements-driven collaboration: Leveraging the invisible relationships between requirements and people. In: Mistrik, I., Grundy, J., Hoek, A., and Whitehead, J. (eds.) Collaborative Software Engineering. 57-76. Springer, Berlin Heidelberg (2010). Knauss, E., Houmb, S., Schneider, K., Islam, S., Jürjens, J.: Supporting Requirements Engineers in Recognising Security Issues. In: Proceedings of REFSQ’11. Springer, Essen, Germany (2011).