You are here: Home > Knowledge Base > Software Engineering Blog > Indtroducing ATAM with Technical Drama
Log in

Forgot your password?

Indtroducing ATAM with Technical Drama

This blog entry presents Technical Drama knowledge transfer approach, its application for teaching ATAM (Architecture Tradeoff Evaluation Method) and summarizes the results we obtained in two case studies - at university and in software companies.

Technical Drama

Technical Drama is an approach to teach complex, expert-based methods used in software development (e.g., ATAM, SAAM) developed at Poznan University of Technology by B. Michalik, J. Nawrocki and M. Ochodek. It can be used in both industrial and academic settings. The knowledge transfer is divided into three steps called acts - lecture, exemplary session, and learning-by-doing session. Practical and theoretical aspects are taught using different techniques e.g., active learning, learn-by-doing, influencing different human senses.
Act I - is a lecture aiming at introducing participants into the context, rules of the complex method. Act II is an exemplary session of the complex method performed by trainers playing the major roles of the method and by trainees playing some minor roles. Act III is a real session of the complex method performed by trainees on their project.

Technical Drama for ATAM

The Technical Drama approach can be used to teach ATAM - Architecture Tradeoff Analysis Method (more about ATAM [2]). The first step is then to explain in a 1.5-hours-long lecture ATAM (the goals of ATAM, the participants roles, the plan, the actions that should be taken etc.). The second act is an exemplary session of a non-trivial system and consists of: a presentation about business drivers, a presentation about architecture (system design), eliciting scenarios and evaluating approaches. The trainers play the main roles of ATAM (Architect, Moderator, Scribe, Experts) and trainees plays some minor roles (Experts or Audience). In the third act the roles switch and the trainees created the ATAM evaluation team and the trainers were experts. They evaluate their own system and the trainers look for problems or issues worth improvement.

Case studies

We carried out two case studies to understand and evaluate the process of transferring knowledge about ATAM using Technical Drama. The first case study results were promising as the practitioners claimed that this way of teaching is good for them. So in the second case study we taught ATAM in 3step approach students of PUT taking part in SDS framework (so they were taking part in real projects). We used surveys discovering the general impression and satisfaction of trainees and knowledge tests. In the study with participants from software development companies the overall knowledge gain and satisfaction was evaluated. In the academic case study the knowledge delta was checked before the study and after each step. The studies detailed results are to be published soon, but overall the conclusion is that the score of the tests increases from act to act (the significance of the change was statistically confirmed for the first and last acts). The results from both studies are aligned with each other i.e. participants are not overwhelmed, are able to evaluate their architectures.

If you would like to use Technical Drama for ATAM or any other method, you can find the more detailed description in [1] and we will be pleased to answer any of your questions. Here you can find the satisfaction survey and an exemplary knowledge test (the knowledge tests were constructed by choosing at random questions from  the list containing developed by us based on [2] questions of different difficulty set by reaching consensus of 3 members of our group - researchers).

[1] B. Michalik, J. Nawrocki, and M. Ochodek, “3-step knowledge transition: a case study on architecture evaluation,”  in ICSE ’08: Proceedings of the 13th international conference on Software engineering, 2008, pp. 741–748.
[2] R. Kazman, M. Klein, and P. Clements, ATAM: Method for Architecture Evaluation.   Carnegie Mellon University, Software Engineering Institute, 2000.

Document Actions
Supporting only the best, so that they can become even better