Presentation of Case Studies
Presentation of Case Studies
After you finish writing the case study and the questions, the time arrives to present your case study in class. Here is a recommended format. It is
using the IDEIDE case study:
Start by presenting your classmates with a general question
to the case study. For example, Does
work with an IDE? Can you tell us your
? Benefits of IDEs? Pitfalls? Dedicate to this stage only a few minutes. The idea is to get a brief
about what your classmates know about your topic.
Tell the case study. If possible, connect the case study to what your classmates have said before.
Present your classmates the questions you developed about the case study. When they discuss these questions, try to talk as little as possible and let them talk as much as possible. Invite them to respond to each other s
Summarize on the board the main points raised by your teammates.
Ask your classmates to propose additional questions about the case study.
Discuss your classmates questions as well.
Summarize the entire discussion with a few sentences that capture your perspective of the case study, taking into account the audience s
After all the case studies are presented in class, it is worth discussing with students both the process of constructing the case studies and the lessons learned from the class presentations and the discussions that followed them. Each instructor can find his own relevant structure for such a summary lesson.
Engineering Case Studies
Remarks about Software Engineering Education
In the past couple of
, terms such as
in discussions about computer science and software engineering in general and their education in particular. Here are several examples: Glass s paper Revisiting the Industry/Academe Communication Chasm [Glass97]; El-Kadi s paper Stop That Divorce! [El-Kadi99], which urges us to stop the divorce between computing and software engineering since there is too much at stake (p. 28); and Gudivada s paper [Gudivada03] The Computing Profession at the Crossroads, which calls industry and academia to work together to chart the best course for the profession s future (pp. 90 “92).
In parallel (and perhaps as a result of these voices), educators suggest exploring new directions for the education of future software
. Among others, Denning in his Educating a New Engineer article [Denning92] suggests that if a curriculum wants to prepare students for a changing world, it must
new elements, such as effective interaction with others and a greater sensitivity to the historical and cultural spaces in which we live and work. [Yeh02] says that in addition to the traditional
study of computer science and engineering education, we must also integrate into the software engineering curriculum the basic knowledge of business performance and measurements, fundamental skills of communication, and human problem solving in team environments.
Each of the aforementioned articles emphasizes a different gap or elements to be added to the software-engineering curriculum. Some refer to the lack of human skills in the training of new software engineers and others suggest strengthening the mutual responsibility of industry and academia when a new curriculum for software engineering is
. One common idea stands behind all these calls for action, however: all suggest broadening the education of software engineers beyond the scientific theoretical courses. This book about human aspects of software engineering is written in that spirit. We hope that it will be useful in computer science and software engineering programs.