Dieses Buch enthalt eine Sammlung von Aufgaben, wie sie typischerweise in Ubungen und Priifungen zur Einflihrungsvorlesung in die Informatik gestellt werden. Es ist speziell abgestimmt auf das bereits erschienene Lehrbuch von Appelrath und l Ludewig (im Rest des Buches kurz "Skriptum" genannt) und solI dem Lernenden helfen, den umfangreichen Stoff aktiv aufzuarbeiten. Der beste Weg dazu ist, die neuen Konzepte und Vorgehensweisen selbst anzuwenden. Bei der Auswahl und Uberarbeitung der Aufgaben wurde besonders auf eine genaue Orientierung am Skriptum geachtet, angefangen bei vordergriindigen Dingen wie dem Layout und der Reihenfolge der Themen bis hin zu den verwendeten Begriffen und dem Umfang des Stoffes. Das Skriptum wird hier durch Aufgaben illustriert; nicht mehr und kaum weniger als der Stoff des Skriptums wird vorausgesetzt. Dieser Ubungsband soUte damit jedem, der sich den Inhalt des Skriptums aneignen will, eine wertvolle Hilfe sein, sei es zum reinen Selbststudium, als Begleitung einer Vorlesung oder zum "Pauken" vor der Priifung. Dieses Buch kann nicht die Ublichen vorlesungsbegleitenden Ubungen ersetzen. Das Lemen in der Gemeinschaft bietet in vieler Hinsicht Moglichkeiten, die ein Buch nicht bieten kann, vor allem Antwort auf Einzelfragen und die gezielte Hilfe bei Ver stiindnisschwierigkeiten. Ebensowenig kann und solI dieses Buch "die Praxis" darstellen und einUben. Der Leser muB sich daruber im Klaren sein, daB die Aufgaben kaum mehr als Sand kastenspiele sind, verglichen mit der tatsachlichen Berufspraxis eines Informatikers."

Am 27. und 28. Februar 1992 fand im Informatik-Bau der Universitat Stuttgart der Workshop "Software Engineering im Unterricht der Hochschulen" statt. Mit Unterstiitzung der GI-Fachgruppen 2.1.1 (Software Engineering) und 4.3.1 (Require- ments Engineering in der industriellen Anwendung) sowie des German Chapter of the ACM wurde erstmals ein Treffen derer organisiert, die -im deutschsprachigen Raum -Software Engineering an einer Hochschule unterrichten. Drei Ziele standen im Vordergrund: - Zunachst ging es darum, die spezifischen Probleme des Unterrichts im Fach Software Engineering zu erortern. - Dann sollte das Arbeitstreffen auch Gelegenheit bieten, die Kolleginnen und Kollegen des eigenen Fachs kennenzulernen und gemeinsam nach der Identitat dieses Gebiets zu suchen. - SchlieBlich war zu klaren, ob es gemeinsame Positionen und Interessen gibt, die es sinnvoll erscheinen lassen, ein Forum zu schaffen, das eine Fortsetzung der gegenseitigen Information und der Diskussionen gestattet. Insgesamt 46 Personen als Vertreter aus 36 Hochschulen (Universitaten sowie Fachhochschulen und Berufsakademien) waren unserer Einladung gefolgt, darunter acht, die ebensoviele Hochschulen in den neuen Bundeslandern reprasentierten. Entsprechend der Zielsetzung wurde den Diskussionen viel Zeit gewidmet; die insgesamt 14 Kurzreferate (in der Regel zwei zu Beginn jeder Sitzung) hatten vor aHem den Zweck, das Thema zu umreiBen und der Diskussion Nahrung zu liefern. Mit dem hier vorliegenden Tagungsband, der gegeniiber den verteilten Unterlagen vollig revidiert und wesentlich erweitert ist, wollen wir unser Treffen dokumen- tieren und - durch den Studienfiihrer Software Engineering - einer engeren Zusammenarbeit derer, die dieses Thema an den Hochschulen vertreten, den Weg ebnen.

Meilensteine sind Entscheidungspunkte im Projekt. Sie haben finanzielle Konsequenzen, entweder in Form von Zahlungen (Auftragsprojekte) oder in Form der Freigabe oder Sperrung von Mitteln (Entwicklungs- oder interne Projekte). Die Grundlage des Entscheids bilden die Empfehlungen von Sachverstandigen, die die Teilergebnisse OberprOft haben. Die PrOfungen finden in Form von Reviews und Tests statt. Zu beachten gilt: Reviews und Tests sind einzuplanen. Reviews sind ein sehr effizientes und kostengOnstiges PrOfverfahren. Die Review-Befunde und die Testergebnisse sind zu dokumentieren. Die Tests sind in Form von Testverfahren zu spezifizieren (erwartete Resultate nicht vergessen ). Reviews und Tests sind an eindeutig gekennzeichneten, jederzeit wiederherstellbaren Versionen von Software-Einheiten vorzunehmen. Die Meilensteine mOssen so definiert sein, daB ihr Erreichen eindeutig OberprOfbar ist. Die festgelegten PrOfberichte liegen vor. Die Detailpliine der niichsten Phase und die Prognose bis zum Projektende (d.h. der nachgefOhrte Meilensteinplan) mOssen fOr die Entscheidungsfindung vorliegen. Der Meilenstein-Entscheid ist zu dokumentieren und allen Beteiligten ZUf Kenntnis zu bringen. Bei den Abnahmetests ist die Formalitiit zu wahren. Die Ergebnisse der einzelnen TestfAlle sind gegenzuzeichnen. Die erfolgreiche Abnahme ist zu zertifizieren. 53 4. ProJekt-Controlllng Was kontrolliert wird, hat die Tendenz zu entstehen."