Category Archives: Communication

Team Teaching: Make it two!

Team Teaching and Pair Lecturing

In team teaching, multiple teachers are involved in teaching a single course. Often, the format is to include different experts to teach different parts of a multi-disciplinary course. For example, I am currently taking a course on medicine for engineers. Here, lectures on different parts of the body, e.g., the cardiovascular system and the central nervous system, are given by different specialists in the respective areas.

Another case of team teaching is pair lecturing, giving a single lecture in a pair (or a team) of teachers. In this case, the teachers take turns explaining things and jump in when needed. The rationale is that multiple lecturers can give multiple explanations to a complex topic, thus facilitating understanding. Also, when one teacher is currently talking, the other teacher can observe. As most of us know from our student times (and from talks we have listened to at conferences), it rather easy to spot as a bystander when the audience is not following. In those cases, the bystander jumps in and gives another explanation that might help the audience to understand.

Pair Lecturing to Verbalise Cognitive Processes

When lecturing about software modelling, we often face the challenge that modelling is a cognitive process. Apart from design patterns, there are very few established principles on how software models are built, what they should contain, and how you construct them in a step-wise fashion. Essentially, the process of building an abstract model of something is mainly going on inside our heads. Making this process explicit to students is challenging.

One way to explain this process is, according to our experience, pair lecturing. In class, we exemplify the modelling process by constructing software models together at the whiteboard. While we built the model, we have to explain to each other what we are drawing. Additionally, we might have to clarify, if our explanation is insufficient, argue, if our approach is questioned by the other teacher, or correct, if we together reach the conclusion that a different solution is better. This discussion at the whiteboard is, essentially, a verbalisation of the cognitive process that would be hidden to students if we simply drew the solution on the board. Similarly, by just explaining our own solution, much of the discussion would be omitted.

Apart from verbalising the modelling process to students, a positive side-effect is that many of the questions students might have during class are already brought up by the other teacher. This encourages further questions and participation from student side (in our experience), and makes sure that questions are actually asked.

Teacher Synchronisation & Costs

Traditionally, pair lecturing has been criticised for its high costs. Clearly, including two teachers instead of one raises the teaching costs.

Our approach to lower these costs dramatically is to include PhD students instead of members of the faculty. As the main teacher is still present, the PhD student does not need to be as knowledgeable in the topic as the main teacher. In fact, not knowing too much might be helpful, as the PhD student will in this case ask similar questions as the audience would – he/she builds a bridge between the main teacher and the students.

Now you might ask yourself: “OK, so those guys just use their PhD students because they’re cheaper. That’s it?”. No. The use of PhD students in pair lecturing is far from accidental in our case. In the Swedish university system, PhD students have a certain percentage of teaching duties. Typically, this duty is spent on group supervision in labs or project work. This, however, means that the PhD students need sufficient knowledge to supervise. Furthermore, they constantly need to synchronise with the main teacher on course contents, progress, and similar issues.

Including PhD students in the lectures effectively removes the need for additional synchronisation. At all times, the PhD student is aware of what is going on in the lectures and knows what the main teacher explained. Hence, additional synchronisation meetings are not needed. Furthermore, there is a lower risk that the PhD student will give explanations in the supervision sessions that are in contrast to the lectures.

Finally, pair lecturing using PhD students facilitates teacher succession. In our case, we had a large staff turnover in the last couple of years. This turnover suddenly left a lot of courses without teacher. In the case of the software modelling course, the PhD student that was involved in pair lecturing knew about all course moments, rationale behind them, and could essentially take over the course, or at least easily hand it over to the new teacher. Even if the main teacher kept teaching the course, it was easier to handle issues such as sick leave, business travel, or other cases in which the main teacher could not be present.

Summary

To sum up the entire article: In our experience, pair lecturing (lecturing with two teachers at the same time) using PhD students as part of the lecturing team helps:

by giving students multiple explanations to a single problem,
by verbalising thought processes and discussions,
and by engaging the student audience more than traditional lectures.

Our course evaluations also clearly show that students see these benefits!

With respect to the course setup, pair lecturing helps:

by synchronising between the main teacher and the teaching assistants, effectively removing the need for synchronisation meetings,
by avoiding contradicting statements between main teachers and teaching assistants,
and by effectively creating a “backup teacher” in case the main teacher is not available or even leaves the university/the course.

The full article includes a lot more details, empirical data, and reflections!

LoCo CoCo: Use the full potential of your systems engineering data!

Leave a reply

In the previous article, I summarised our findings on communication problems in automotive Requirements Engineering (RE). While our interviewees during that studies mentioned several problems, at one of the case company they also highlighted frequently how it helped them in their daily work to have a tool that connects different kinds of data, e.g., requirements, hardware design, logical (software) design. While this clearly helps them already now to understand how their data is connected, we got the idea that this might as well be used to help them understand how people are or should be connected. This is the idea of LoCo CoCo.

LoCo CoCo (short for Low-Cost Communication and Coordination) is the idea to extract social networks from systems engineering data. That is, infer the relationship between people from items and relationships in data. Consider the example where you have a requirement, a hardware design of some sort, and two issues in your repository (see figure below). The different items could relate to each other (e.g., the hardware design contains the requirement or one of the issue relates to the requirement) and could be located in different tools (indicated by the colours). Additionally, different people might have created and/or changed those items. Based on this already existing data, we can derive a graph that connects people instead of work items. This is, in essence, what LoCo CoCo does. Using those graphs can then help engineers to find experts in a certain area (e.g., finding people knowledgeable in a particular area).

Clearly, there is related work around in the community. Two of the approaches to be mentioned in this context are Codebook and StakeSource. Ours differs in a number of ways. First, we are providing details on the implementation, whereas related work is on a rather high level. Secondly, we focus on high-level artefacts, i.e., abstract work items without a focus on (software) development. Hence, LoCo CoCo aims at early communication in an interdisciplinary environment, where code might not or not yet play a central role. Finally, we made the conscious choice not to employ any machine learning or other techniques that could introduce false positives. Instead, we intentionally only expose data that exists already in the tools. This is to avoid any false positives, but also to uncover incorrect ownership data in the systems engineering data. For example, an engineer might be listed as an owner of a requirement even though he/she is no longer in the company. In this case, an engineer consulting the social network might realise this and update the data.

We piloted LoCo CoCo at one automotive company based on data in two tools: SystemWeaver (by Systemite) and Clear Quest (IBM). While we were, so far, not able to roll out the tool, we asked practitioners at the company about the potential and their impression.

Our results show that, while LoCo CoCo has great potential, social data in systems engineering tools is often outdated, simply because it is not used. Our interviewees indicated that this might change as soon as the data is used in a meaningful way. For example, if engineers see the benefit of using social networks to contact the “right” people, they might be willing to update social data. Similarly, it could be possible to introduce simple changes in the tools to increase the data quality. For example, currently changes on systems engineering data is not logged at the case company. However, this is a common feature in most modern tools and should therefore be easy to change.

Finally, we discovered a number of ethical issues using social networks that are, to our knowledge, not commonly studied in related work. We found that the social networks created with LoCo CoCo might cause wrong perceptions when used naively. For instance, engineers might tend to believe that a person with few/no connections in a social network is not important or not working hard enough. However, the lack of connections might be related to several other factors, e.g., low data quality, a lack of trace links in the person’s work environment, or simply the role of that person. Hence, even though we only use existing data, highlighting social aspects holds a number of challenges which need to be investigated further in future work.

Based on the initial prototype, we are currently extending LoCo CoCo to extract data from OSLC adapters, one of the bigger standards for tool interoperability. Additionally, we are implementing an open source tool based on Gephi, which will include the OSLC adapters and several design considerations outlined in the current article.

(This is a summary of the article published in Information and Software Technology. If you want to know details, plus more numbers and figures, you can read it here!)

Communication in RE: Where does it hurt?

Leave a reply

As a part of my research in model-based requirements engineering, we conducted a case study a while ago to investigate how models are/can be used in automotive requirements engineering. While running the interviews at two automotive companies, we discovered that interviewees regularly talked about problems that occur during everyday work. What stood out to us was that they all mentioned communication issues frequently.
We decided to first investigate these issues further, instead of prioritising the original analysis regarding modelling. From our interviews, enhanced with an online survey among practitioners in the automotive industry, we extracted a list of seven problems in automotive RE – all related to communication and coordination:

P1: Lack of Product Knowledge: the lack of sufficient knowledge about
the product in early stages.
P2: Lack of Context Knowledge: the lack of context information regarding
requirements on low levels of abstraction.
P3: Unconnected Abstraction Levels: a mismatch between requirements
on different abstraction levels.
P4: Insufficient Communication and Feedback Channels: lacking communication
with other people within or across the organisation.
P5: Lack of Common Interdisciplinary Understanding: the lack of common
understanding across multiple disciplines.
P6: Unclear Responsibilities and Borders: the lack of clear and communicated
responsibilities between different parts of the organisation.
P7: Insufficient Resources for Understanding and Maintaining Requirements:
to lack enough resources in early phases to get an understanding
of the needs and to maintain requirements later on.

We found that these problems were the main issues mentioned by multiple interviewees in both our case companies and in the survey we conducted.

Clearly, some of these issues are related to a cost-benefit trade-off. For instance, P7, how to deal with a limited amount of time and money, is omnipresent in daily life and can only be solved by lowering the expectations towards certain quality aspects in parts of the requirements specification. Similarly, P3, abstraction gaps between requirements abstraction levels, can only be reduced by extra effort in both specification and maintenance of requirements (which would then inevitably lead to P7 again).

However, we also find a number of issues that are strongly related to the automotive reality. For example, both the lack of product knowledge (P1) and lack of context knowledge (P2) are related to the large number of sub-contractors in automotive engineering. Sub-contractors are typically very specialised to certain parts of the automobile (their specific expertise), leading to a lack of product knowledge in other areas. Similarly, the lack of context knowledge is typically related to this issue and to concerns regarding intellectual property (i.e., only making very limited parts of the requirements specification available to sub-contractors).

Based on these findings, there are a number of issues that, we believe, should be addressed in future work. First, there is a need for a process that allows for sufficient levels of uncertainty during early phases of RE. This is certainly not a new finding, but increasing speed of technological change makes this more and more important. Also, while I personally come from the ‘formal world’ and, ideally, would like to specify everything so that you can verify it for correctness (or what ever else comes to mind), it is important to accept reality, i.e., that not everything is certain and can be specified. Secondly, there is a need for an organisation structure that effectively supports interdisciplinary RE, taking into account the central role of software. While automotive companies are often ‘traditional’ and have a purely mechatronic background, software is becoming increasingly important. The companies need to be aware of this and adapt. In contrast, the software engineering community would be strongly advised to not ignore other disciplines. Hardware and mechatronic components in automobiles still have long lead times and do often not adhere to agile practices. This already causes frictions between the two worlds (see also our recent Paper on challenges in large-scale, agile requirements engineering: Kasauli et al., 2017, “Requirements Engineering Challenges in Large-Scale Agile System Development”, Proceedings of 25th International Requirements Engineering Conference).

(This is a summary of the article published at Requirements Engineering Journal. If you want to know details, plus more numbers and figures, you can read it here, free of charge!)