Termine, Vortragende, Titel und Zusammenfassungen für das Kolloquium im Sommersemester 2006.
Die Vorträge finden in unregelmäßigen Abständen in der Regel Freitags um 14:00 Uhr im Seminarraum 049 in der Takustr. 9 statt. Vorläufige Terminreservierungen ohne Gastname sind als"(reserviert von [Einladende/r])"
einzutragen; Termine noch ohne Gewähr als "(wahrscheinlich)"
o.ä. zu markieren. Im Rumpf des Eintrags steht jeweils, wer den Vortrag organisiert. (Zur technischen Notation siehe ShortHand.)
Ab spätestens einen Tag vor dem Vortrag sollte auch eine Zusammenfassung dabeistehen.
Information zum Anlegen von Kolloquiumseiten pro Semester findet man unter KolloWeitereInfosDarf Informatikunterricht Spaß machen?
Schülerinnen und Schüler wählen aus verschiedenen Gründen Informatik als Unterrichtsfach; oft aus Spaß am Umgang mit dem Computer: spielen, chatten, surfen, Musik hören, mailen, … Im Unterricht selbst werden jedoch Aspekte der Wissenschaft Informatik vermittelt. Dieser Gegensatz zwischen Informatik und Computernutzung führt immer wieder zu – auch öffentlichen – Diskussionen über die Rolle des Informatikunterrichts.
Anhand der didaktischen Grundfrage „Wer soll was, wie lernen?“ werde ich an drei Beispielen fachdidaktische Forschung diskutieren: Erwartungen und Wahlverhalten von Schülerinnen und Schülern, die soziotechnische Sichtweise auf Informatiksysteme und Ansätze eines Modells zur Beschreibung der Programmierkompetenz.
Möglicherweise gibt es auch eine Antwort auf die Frage, ob Informatikunterricht Spaß macht.
Large Scale Software Development or "What?? Why didn't you tell me 6 months ago! Now I have to rewrite all my code!"
Large software development projects today need to implement new functionality, be standard compliant and maintain compatibility with previous versions of the same software. In some cases, they also need to evolve in lockstep with other large development projects, e.g. the associated tooling. The projects need to achieve these functional and non-functional goals while involving large teams of developers from a wide variety of backgrounds and while observing time and budgetary constraints. This is clearly not a trivial task.
A practical approach used in the software industry to organize such complex development tasks is "scenario based development". In this approach, architecture, design and development decisions are guided by normative application or infrastructure scenarios rather than by specific, isolated requirements.
The term "scenario" is not meant to be (a variation of) a Use Case (UC)in this context. Rather, a scenario represents typical end-to-end customer situations at a reasonable level of detail. Just what is "reasonable" is subject to much debate. Scenarios can serve as the basis for developing UCs to further clarify specific aspects of the target system. However, the UC definition is usually left to individual development teams who work on one specific aspect of the target system. For example, a Logon UC could clarify the behavior of the security service of the target system. The main purpose of a scenario is to ensure that any such additional UCs are compatible with one another, and that they are based on a consistent set of assumptions. For example, the Logon UC may need to allow for system actors who cannot respond to visual challenges; this point is relevant not only to the security development team but also to the adapter developers. Such cross cutting characteristics of a target system often are not accurately conveyed by isolated requirements; however, they can easily be captured in an appropriate scenario. Thus, with scenarios, the functional description of the software is raised to a more generic level. The approach therefore helps to facilitate and unify the communication of various interrelated requirements to large development teams.
The talk will cover the experiences of the speaker during a scenario based development effort for the WebSphere Process Server at IBM. The speaker was responsible for working with various development teams to define scenarios, document them and communicate them across various organizations. We will discuss the general benefits of scenario based development as well as its shortcomings.
Bio: Rainer Kerth has spent the last 9 years in various functions at IBM. For the last 6 years, he worked as a Senior IT Architect in IBM's Software Group in Somers, New York. His responsibilites there included coordinating IBM's comments on the J2EE standard and documenting the programming model of WebSphere Application Server as well as the WebSphere Process Server. In recent years, he was responsible for defining the technical architecture of IBM's RFID offering. Kerth has holds a Master degree in Mathematics from the Technical University of Berlin and a PhD in Mathematics and Foundations of Computer Sciences from the University of Paris 7.Nächstes Semester
InformatikKolloquiumWiSe2006Frühere Semester
InformatikKolloquiumWiSe2005