by Stan Kurkovsky, kurkovsky@ccsu.edu, @SKurkovsky
Software engineering courses at the post-secondary level usually integrate students’ programming skills with their knowledge in many other areas of computing, such as databases, security, or computer networks. Software engineering, however, is much more than simply putting existing knowledge and skills to practice. There are many important principles and concepts that are central to the practice of modern software engineering, such as requirements engineering, emergent properties, socio-technical systems, etc. Given the engineering nature of the discipline, one of the best ways to learn these principles is usually to apply them in a practical context, such as a case study.
Lego Serious Play Case Study for Software Engineering – by Stan Kurkovsky
Recently, we began using LEGO SERIOUS PLAY as a foundation for hands-on case studies to teach the core concepts of software engineering to senior (4th year) students at a university. As with all LEGO SERIOUS PLAY workshops, students were first introduced to LEGO SERIOUS PLAY by participating in a skill building session, which took an entire 75-minute period. All of our case studies went beyond building individual models and included building either a shared, a landscape model, or both, which promotes team building and creating of shared understanding. These two kinds of models force students to compare their thoughts and views on the same concept, which helps each student correct any possible misconceptions and crystallize their understanding of that concept. We piloted several LSP-based case studies, one of which is described below.
Software dependability is one of the key concepts of software engineering. The objective of this case study was to identify, analyze, and mitigate the risks to dependability of a complex socio-technical system. In particular, this case study explored four different dimensions of dependability: availability, reliability, safety, and security. It is important to point out that system dependability also includes other properties, such as survivability, maintainability, integrity, etc., which were left out of the scope for the sake of simplicity These four properties were examined in the context of four different systems: an automatic parking garage gate, a smartphone, a digital picture frame, and a traffic light control system. We used two decks of cards to produce random combinations, e.g. reliability of a parking garage gate or security of a digital picture frame. Each card in one deck was labeled with one dimension of dependability, while the other deck included different systems. Each student picked a random card from each of the decks. Given these selections, students were asked to build a LEGO model and come up with an event/scenario illustrating the corresponding risk to dependability in the given system.
Once the individual models were built, students explained their models grouped by the dependability feature, e.g. reliability. After all stories related to system reliability were shared, all corresponding models were grouped together into a landscape model and the students were asked to reflect upon them: does each model create a good scenario illustrating a risk to the system’s reliability? Students were asked to pick the best or the most relevant scenario, improve upon it, if necessary, and briefly describe that scenario in their case study worksheets. This process was repeated for the models related to each of the remaining dimensions of dependability.
Lego Serious Play Case Study for Software Engineering – by Stan Kurkovsky
Once all models were discussed and the landscape models were built, students performed a risk-based analysis of their models, given the system/scenario combinations. Using the models they created, students were asked to identify and describe the specific risk factors, analyze and assess that risk based on its severity/probability, decompose the risk to identify its root cause, and reduce the risk by choosing an appropriate risk mitigation strategy to improve system dependability (risk avoidance, risk detection and removal, or risk tolerance). Students were asked to explain their reasoning to the team based on the models they’ve build and to write down the key points in their worksheets.
This particular case study sparked a lot of discussions among the students when they were comparing their individual elements on the landscape model to see which one would serve best to illustrate the concept of system safety.
One of the students said that
this case study translated best into diverse LEGO models that could be easily created. I distinctly remember a [minifigure] head chopped off because the system failed a safety requirement. Students could also see the benefits of using LSP in studying software engineering from a wider perspective: LSP certainly helped me formulate concrete representations of dependability concepts. I think LSP is particularly powerful for abstract ideas, as it requires innovative thinking to conceptualize a representation.
Student perception of LSP in general was very positive, which can be best summarized using the words of one student:
I believe that the concepts learned with LEGO go deep in my mind. I will remember them because I played. I explained my design to my teammates. When I build with LEGO, it creates more meaning to the concepts from each lecture.
