RECONF - Veranstalter

10.-12. März 2003 in München

Montag 10. März 2003

09:30 - 10:30	Prof. Dr. Manfred Broy, TU München
	Was ist eine Spezifikation - und wie spezifizieren wir?
	In allen Phasen der System- und Softwareentwicklung sind Spezifikationen von größter Wichtigkeit. Für die Spezifikation von Domain Modellen, Anforderungen, Systemumgebungen, Architekturen, Komponenten, Modulen und Funktionen müssen wir sehr unterschiedliche Techniken verwenden. Auf dem Weg von informellen, unstrukturierten Spezifikationen über informelle, strukturierte Spezifikationen hin zu formalen Spezifikationen sind adäquate Modelle wesentliche Hilfsmittel.

11:00 - 11:45	Colin Hood, HOOD Group
	CMMI - Was müssen wir im Requirements Management & Engineering dafür verbessern?
	Um CMMI Level 2 oder höher zu erreichen braucht eine Organisation, neben anderem, Prozessfähigkeiten im Requirements Management & Engineering (RM&E). Wie kann das erreicht werden? Es werden die RM&E-Vorgaben von CMMI mit Hilfe von RM&E-Techniken untersucht. Wie in jeder guten Systemanalyse ist der Problembereich (Anwenderanforderungen) und der Lösungsbereich (Systemanforderungen und Design) getrennt. CMMI gibt die Anwenderanforderungen vor, und wir untersuchen die Systemanforderungen. CMMI beschreibt die Ziele, wir erarbeiten die Lösungen. Die erste Aufgabe ist die wirklichen Anforderungen von CMMI zu erkennen.

11:45 - 12:30	Dr. Frank Houdek, DaimlerChrysler AG
	Operatives Recycling von Anforderungen für Fahrzeugsteuergeräte
	Steuergerät, deren es im modernen Fahrzeugen eine Vielzahl gibt, werden typischerweise nicht auf der viel zitierten „grünen Wiese“ entwickelt. Vielmehr setzt die Entwicklung auf existierenden Arbeiten auf – und hier speziell auf existierenden Anforderungen und Lastenheften. In dem Vortrag wird ein Konzept zur baureihenübergreifenden Wiederverwertung von Anforderungen basierend auf konkreten Ablagestrukturen vorgestellt. In dem Konzept integriert sind auch Ansätze zur Generierung von Ausschreibungsunterlagen. Neben dem grundlegenden Konzept wird im Vortrag auch auf konkrete Erfahrungen eingegangen. Dazu gehört auch ein kurzer Einblick in die werkzeugtechnische Unterstützung des Ansatzes mit dem Werkzeug DOORS.

14:00 -14:45	Christian Missling, Telelogic GmbH
	COMMUNICATE collaborate validate
	Als Bestandteil der Systementwicklung sind Requirements mittlerweile akzeptiert und etabliert - doch woher kommen Requirements? Alle Gruppen von Marketing über Entwicklung bis zum Vertrieb in den Entwicklungsprozess so einzubinden, um die für sie relevanten Informationen einfliessen zu lassen, kann nur durch Kommunikation der Requirements geleistet werden.

14:45 - 15:30	Dr. Rolf Ebert, Berner & Mattner Systemtechnik GmbH
	Modellbasiertes Requirements Engineering
	Funktionale und manche nicht-funktionalen Anforderungen können in einem Modell dargestellt werden. Die Verwendung Computergestützter Modellierungs-Werkzeuge erlaubt das automatische Überprüfen auf verschiedenen Kriterien, wie zum Beispiel die dauerhafte Modellkonsistenz oder das Aufdecken offensichtlicher Widersprüche. Wir zeigen die Verwendung einer Mischung aus textbasierter Spezifikation, modellbasierter Spezifikation und modellbasierter Spezifikation mit Simulation. Der Vortrag befasst sich mit dem integrierten Konzept, zeigt die notwendigen Voraussetzungen in der Vorgehensweise und in den Werkzeugen, und das Zusammenwirken in der Praxis. Auf den ersten Blick erscheint die Erstellung von Modellen als ein zusätzlicher Aufwand, dessen Vorteil kaum messbar ist. Insbesondere in komplexeren Projekten konnten jedoch viele pezifikationsfehler mit Hilfe der Simulation gefunden werden. Der Schlüssel für ein wirtschaftliches Requirements Engineering liegt in einem ausgewogenen Verhältnis von modellbasierter und textbasierter Spezifikation.

16:00 - 16:45	Bernd Freyenberg-Richter, T-Systems
	Requirements Verification & Management
	Speziell bei der Entwicklung von komplexen Algorithmen oder bei der Spezifikation von MMI-spezifischen Aspekten -wie sie z.B. im Bereich der Navigation des Taktischen Transport Helikopters NH90 derzeit implementiert werden- mussten innerhalb kurzer Zeit Methoden bzw. Vorgehensweisen entwickelt werden, die es ermöglichen, sowohl schnell und effizient die Konsistenz / Richtigkeit der kompletten Spezifiaktion zu verifizieren, alsauch komplexe Test-Fälle und hohe Test-Abdeckung zu erzielen. Im Vortrag wird eine Eigenentwicklung eines Tools, das sich mit dem Thema "Requirements Engineering / Verification" beschäftigt, vorgestellt. Es wird auf die historischen Entwicklungsstände bzw. Entstehungsgeschichte des Tools als auch auf die derzeitige Nutzung im Projekt "NH90 Avionic Software" bei der Firma Eurocopter eingegangen werden.

16:45 - 17:15	Volker Kopetzky, Rational Software GmbH
	Festpreis ade: Wege aus der Risikomisere
	Toolvortrag

17:15 - 17:45	Ulrich Hörmann, Borland GmbH
	„Featured Driven Requirements Engineering with RDDP” (Requirements Driven Development Process)
	Toolvortrag

Dienstag 11. März 2003

08:30 - 09:00	Almudena Diez, TCP Sistemas e Ingenieria S.L.
	IRqA Integral Requisite Analyzer - Beyond Requirements Management
	Toolvortrag

09:00 - 09:30	Christian Missling, Telelogic GmbH
	communicate COLLABORATE validate
	Toolvortrag

09:30 - 10:15	Dr. Antje von Knethen, Dr. Barbara Paech, Frauenhofer IESE
	Wie sollte ein Anforderungsdokument des Auftraggebers aus Sicht des Auftragnehmers geschrieben sein? – ein Erfahrungsbericht
	Die Auslagerung der Entwicklung einzelner Komponenten oder sogar des gesamten Systems stellt besondere Anforderungen an die Formulierung der Anforderungsdokumente, die als Vertragsbasis zwischen Auftraggeber und Auftragnehmer dienen. Die Herausforderung für den Auftraggeber liegt einerseits darin, die Anforderungen an die vom Auftragnehmer zu entwickelnde Komponente möglichst abstrakt beschreiben (d.h. ohne Preisgabe eigener Unternehmenskompetenz und Vorwegnahme von Entwurfsentscheidungen). Andererseits muss das Anforderungsdokument möglichst präzise beschreiben, was die Komponente leisten soll und welche Schnittstellen zu anderen Komponenten, die vielleicht von anderen Auftragnehmern entwickelt werden, existieren. Im Vortrag werden Ergebnisse und Erfahrungen eines konkreten Software-Entwicklungsprojekts aus dem Bereich Verkehrszugangssysteme vorgestellt. In dem Projekt war das vom Auftraggeber vorgegebene Anforderungsdokument keine geeignete Basis für den Auftragnehmer zur Entwicklung einer Komponente. Insbesondere musste - eine Black-box Verhaltensbeschreibung der zu entwickelnden Komponente rekonstruiert werden, - die Schnittstellen aus Sicht der zu entwickelnden Komponente definiert werden und - explizit zwischen physikalischer und logischer Aufteilung in Teilkomponenten unterschieden werden. Die aus den Erfahrungen abgeleiteten Qualitätskriterien für Anforderungsdokumente führen zu einem besseren Verständnis des Auftragnehmers und des Auftraggebers (!) über die gewünschte Funktionalität der Komponente. Außerdem erleichtern so erstellte Dokumente die Erstellung des Entwurfsdokuments.

10:45 - 11:30	Knut Salomon, Modulo3
	„Was kümmert mich mein Geschwätz von gestern?“
	Als Konrad Adenauer angesichts der Wiederbewaffnungsdebatte des deutschen Bundestages in den fünfziger Jahren des letzten Jahrhunderts diesen Satz prägte nahm er für sich selbstverständlich das Recht in Anspruch, „nichts dafür zu können, dass er jeden Tag klüger werde“. Wie also wollen wir unseren Kunden das Recht absprechen, jeden Tag neue Erkenntnisse zu erlangen. Und neue Erkenntnisse heißt nicht einmal, dass zuvor etwas vergessen oder übersehen wurde. Vielleicht hat sich die Welt unserer Kunden lediglich in einer Weise geändert, die eine Änderung ihrer Vorstellungen geradezu herbei zwang. Wie schade, wenn wir uns in einer solchen Situation in ein Festpreisprojekt verbissen haben, in dem von Anfang an kein Platz mehr für kostenlose Änderungen und Ergänzungen war. In dem natürlich aber auch kein Budget für kostenpflichtige Änderungen mehr zur Verfügung steht.

11:30 - 12:15	Volker Kopetzky, Rational Software GmbH
	Baukunst: Anforderungen und Architektur
	Neben dem Anforderungsmanagement spielt auch das Thema Achitektur in der Software Entwicklung immer mehr eine Rolle. Ohne konkretisierte Anforderungen ist jedoch eine stabile und wertvolle Architektur nicht realisierbar. Der Vortrag stellt die beiden Begriffe vor und diskutiert die notwendigen Entscheidungen, Rollen und Vorbedingungen, um Anforderungsmanagement für iterative und architekturelle Softwareentwicklung erfolgreich einzusetzen.

13:45 - 14:30	Stefan Gläser, Volkswagen AG/ Bernd van Vugt, Extessy AG
	Integrative Entwicklungsprozesse am Beispiel einer automotiven Anwendung
	Infotainment als immer wichtiger werdender Wettbewerbsfaktor für die Automobilindustrie erfordert branchenübergreifendes Denken und Planen, da zur Integration von multimedialen Funktionen ins Fahrzeug zwei höchst unterschiedliche Entwicklungsprozesse zusammengeführt werden müssen: Für ein neues Fahrzeugs kann man von einer Entwicklungszeit von ungefähr fünf Jahren ausgehen, wogegen der Entwicklungszyklus in der Informationstechnologie zwischen einem halben und zwei Jahren anzunehmen ist. Die Zusammenführung dieser Prozesse gestaltet sich nicht zuletzt deswegen problematisch, weil die Struktur der Automobilindustrie nahezu vollständig auf den bestehenden, konventionellen Entwicklungsprozess ausgerichtet ist und damit wenig Freiheitsgrade für eine adäquate Reaktion auf die dynamischen Anforderungen des Multimediamarktes läßt.Hier kann ein durchgängig tool-unterstützter Entwicklungsprozess helfen, beide Prozesse zu einem einzigen zu verschmelzen. Eine besondere Bedeutung fällt dabei dem Requirements Engineering zu, welches Anforderungen für beide, Fahrzeug und Multimediasystem, als eine zentrale „Wissensbasis“ identifizieren und spezifizieren soll. Eine objektorientierte Vorgehensweise, welche die Schnittstelle zwischen einzelnen Modulen auf funktionaler Ebene definiert, ermöglicht die Entwicklung ausführbarer Modelle anhand eines digitales Lastenheftes. Die Komponenten dieser Modelle sind nun beliebig austauschbar. Es können dann nicht nur beliebig Module ersetzt, sondern auch SW-Module gegen echte HW ausgetauscht werden.Auf diese Art erhält man einen Katalog von Anforderungen, welche, unabhängig von ihrer Granularität und Maturität, den Ausgangspunkt für eine konsistente Zusammenführung beider Entwicklungsprozesse darstellen.

14:30 - 15:15	Udo Apel, Borland GmbH
	Die Relevanz des Requirements Driven Development Process im Umfeld von Application Lifecycle Management
	In der Softwareentwicklung ist Requirements-Management ein kosten- und zeit-optimiertes Vorgehensmodell. Dieser Vortrag beschäftigt sich mit der Integration und Abstimmung des Requirements-Management in den gesamten Entwicklungsprozess. Im Besonderen soll dem Zuhörer aufgezeigt werden, wie ein iteratives & toolbasierendes Requirements-Engineering in einen modernen und fortlaufenden Softwareentwicklungsprozess integriert und verwirklicht werden kann. Requirements-Management zeichnet sich als Kommunikationsbrücke zwischen allen involvierten Fachbereichen und Unternehmen aus.

15:45 - 16:30	Matthias Recknagel, DaimlerChrysler/ Jan Ebert, HOOD Group
	Änderungen, Konfigurationen, Versionen und Baselinesvon Spezifikationen ohne Chaos-Risiko
	Die Erweiterung eines existierenden Anforderungs-Management Prozesses um ein kontrolliertes Änderungs- und Konfigurations-Management gehört zu den essentiellen Prozess-Verbesserungs-Maßnahmen, sobald ein omplexeres Projekt seine Initialphase verlässt. Um die Spezifikation auch in den nachfolgenden Projektphasen aktuell zu halten, müssen die in realen Projekten unvermeidbaren Änderungen kontrolliert in die laufenden Prozesse und die spezifizierten Inhalte eingebracht werden. Dabei ist neben der formellen Verfolgung und Entscheidung der Änderungen auch die inhaltliche Kommunikation und Klärung der Änderungen sowie die Dokumentation der verschiedenen Projektinhalte abhängig von der Zeit sicherzustellen. Die Schwierigkeit und die Kunst des RMPI liegt jedoch darin, alle Projektbeteiligten bei der Einführung jeder Maßnahme mindest soweit wie für seine Rolle erforderlich auch "mitzunehmen". Deswegen ist der Versuch zum Scheitern verurteilt, das Projekt ruckartig auf einen formalen, ggf. mehrstufigen, Änderungs-Freigabe Prozess umzustellen. Andererseits ist kein nachhaltiger Erfolg zu erwarten, wenn nur der nach dem initialen Spec.Freeze erforderliche Änderungs-Freigabe-Prozess informell definiert wird; zu leicht passiert es, dass durch ein derartiges Vorgehen später notwendige Wege verbaut werden, z.B. die formale Einbindung der kaufmännischen Freigabe durch hinzukommende Rollen wie Einkaufsabteilungen. Der Vortrag zeigt, wie für ein Änderungs- und Konfigurationsmanagementsystemerfolgreiches RMPI frühzeitig mit Hilfe von UseCases und Prozess-Modellen der vollständige Ä&KM Prozess für das Gesamt-Projekt bis zu seinem Abschluss spezifiziert wurde. Die Einführung und Umsetzung erfolgt im Interesse einer möglichst hohen Akzeptanz bei den Anwendern in mehreren Stufen, wobei die jeweils aktuellen Projektphasen durch das System optimal unterstützt werden soll., von vorherein jedoch die stufenweise Einführung (durch Tailoring) für die Machbarkeiten und Erfordernisse der jeweiligen Projektphasen bis dahin geplant wurde. Notationen und Detaillierungsgrade, in denen einerseits die Prozessmodelle erstellt und diskutiert werden, andererseits dazu genutzt werden, Dokumentation und Schulungsunterlage für die beteiligten Anwender-Rollen des Ä&KM zu sein, unterscheiden sich grundsätzlich. Das Feedback aus den Einführungs-Stufen in den laufenden Projekt-Phasen dient zur iterativen Optimierung der zugrundeliegenden Final-Prozess-Spezifikation.

16:30-17:15

Moderation: Dr. Armin Schulz, GfSE/ Colin Hood, HOOD Group

Podiumsdiskussion:
Spezifikationen im Spannungsfeld
Anforderungsqualität – Domainwissen – organisatorischer Reifegrad
Zur Qualitätssicherung von Requirements und Requirements Spezifikationen sind konstruktive und analytische Verfahren bekannt und im Einsatz. Das Domainwissen und das Wissen über mögliche Architekturen entstehender neuer Systeme ist aber für die Software- und Systementwicklung mindestens genauso wichtig wie qualitativ hochwertige Anforderungen. Der organisatorische Reifegrad eines Unternehmens ist vermutlich entscheidend für die Tiefe des Einsatzes qualitätssichernder Maßnahmen für Anforderungen und Spezifikationen.
Die Diskussion startet mit Kurzvorträgen mit den unterschiedlichen Standpunkten und soll dann im weiteren Verlauf die verschiedenen Positionen näher beleuchten.

Back to top