Software-Engineering in der beruflichen Ausbildung – Simulation realer Projektsituationen Dipl.-Ing. Heike Vocke

Dipl.-Kfm. Ulrike Woigk

Unternehmensberatung H. Vocke Manfred-von-Ardenne-Ring 20, F D-01099 Dresden [email protected]

b.i.b. Bildungszentrum für informationsverarbeitende Berufe gGmbH Paradiesstraße 40 D-01217 Dresden [email protected]

Abstract: Am b.i.b. Dresden werden Berufsfachschüler im Software-EngineeringProjekt mit möglichst realen Projektsituationen bei der Entwicklung objektorientierter Software konfrontiert. Neben den softwaretechnischen Anforderungen wird Wert auf eine Herangehensweise nach betriebswirtschaftlichen Notwendigkeiten, die Arbeit im Team, die Kommunikation mit dem Auftraggeber sowie die Präsentation der eigenen Projektergebnisse gelegt. Es werden Vorgehen, Organisation und Bewertung des Projektes beschrieben. An einem konkreten Beispiel wird dargestellt, welche Handlungskompetenz sich die Schüler erarbeiten sollen. Die Autoren gehen auf mögliche Problem- und Konfliktsituationen ein, nennen ihre Erfahrungen und stellen die Übertragbarkeit der Ergebnisse zur Diskussion.

1 Zielstellung und Motivation Im zweiten Ausbildungsjahr am b.i.b. Bildungszentrum für informationsverarbeitende Berufe gGmbH in Dresden wird von den zukünftigen „Staatlich geprüften Assistenten für Softwaretechnologie“ ein fächerübergreifendes Software-Engineering-Projekt zur Entwicklung einer objektorientierten Softwarelösung von der Aufgabenstellung über die Implementation bis zur Präsentation der Gruppenergebnisse durchgeführt. Über einen Zeitraum von 5 Wochen (30-40 h) bearbeiteten die Studierenden im Team eine Aufgabenstellung, die sie mit realen Projektsituationen von Softwareentwicklungsprojekten konfrontiert. Die Einschätzung der eigenen Teamfähigkeit, die Bewertung der Gruppenarbeit und der gemeinsam erbrachten Leistungen sowie eine kundenfreundliche Darstellung der Ergebnisse sind Fähigkeiten, die von den Studierenden entwickelt bzw. weiter ausgeprägt werden sollen. Die Teammitglieder müssen dabei ihre theoretischen Kenntnisse nicht nur aus dem fachbezogenen Unterricht wie „Software-Engineering“ und „Programmierung“ anwenden, sondern das Projekt auch aus betriebswirtschaftlicher Sicht betrachten lernen. Neben dem Praktikum in einem Unternehmen ist es für die Studierenden oft die erste Erfahrung, an der Realisierung einer komplexen Softwarelösung beteiligt zu sein. Dieser Herausforderung wollen sich in der Regel auch alle Teilnehmer stellen. Zu Beginn des Projektes fühlen sich die Studierenden erfahrungsgemäß oft überfordert - 297 -

oder denken, die Aufgaben auch allein lösen zu können. Am Ende sind sie immer erstaunt, welches umfangreiche Wissen anwendungsbereit sein muss sowie mit welchen Randbedingungen und Unwägbarkeiten man in Software-Projekten zu kämpfen hat. Um einen möglichst großen Lerneffekt zu erreichen, werden bei der Realisierung des Softwareprojektes folgende, realen Projekten entsprechende Situationen simuliert: • • • • • •

unklare Aufgabenspezifikation, Nichtverfügbarkeit von Ansprechpartnern des Auftraggebers, Selbstorganisation im Team, keine optimale Teamzusammensetzung, Schwierigkeiten bei der Aufwands- und Risikoabschätzung, Reviews mit dem Auftraggeber mit Präsentation der Teamleistung.

Dazu kommen weitere Situationen, die sich gesetzmäßig immer einstellen und damit gar nicht simuliert werden müssen: • • • • •

Kenntnisse und Fähigkeiten einzelner Teammitglieder reichen nicht aus, fehlende Kommunikation innerhalb des Teams und nach außen, Ressourcen wie Teammitglieder oder Rechner fallen aus, ungenügende Qualitätssicherung (z. B. Datenverlust), Terminschwierigkeiten.

Durch die Schaffung möglichst realer Projektsituationen werden Fähigkeiten und Fertigkeiten wie zum Beispiel Selbstdisziplin, eigene Motivation, Motivation im Team, kreativer Umgang mit auftretenden Problemen geschult und gefördert. Der Resignation bei Schwierigkeiten im Projekt wird durch die Teamarbeit stark entgegengewirkt. Die Unterstützung der Studierenden bzw. das direkte Eingreifen durch die Dozenten innerhalb der Projektgruppen wird bewusst zurückhaltend ausgeübt, damit die Studierenden nach eigenen Lösungswegen und -möglichkeiten suchen und sich nicht auf Hilfe von Außen (z. B. durch die Dozenten) verlassen. Dadurch sind die Studierenden darauf angewiesen, bereits Gelerntes selbstständig einzusetzen. Die neuen Rollen der Dozenten innerhalb des Software-Projektes werden außerdem besser wahrgenommen. Frau Vocke schlüpft in die Rolle des Auftraggebers, Frau Woigk übernimmt die Verantwortung als Gesamtprojektleiter und achtet damit auf Termineinhaltung. Außerdem gibt es einen fachlichen Coach für Softwareentwurf, Softwaretest und Dokumentation sowie einen für die Unterstützung bei der C++-Programmierung.

2 Vorgehen Zusammenfassend sind folgende Ziele der gewählten Vorgehensweise zu nennen: 1.

fachübergreifendes Umsetzen von Fähigkeiten und Kenntnissen,

2.

Umsetzen theoretischer Software-Engineering-Kenntnisse in realen Projekten, - 298 -

3.

klare Aufgabenformulierung,

4.

kundenfreundliche Aufbereitung und Darstellung der erbrachten Teil- und Gesamtleistungen,

5.

praktisches Erkennen der Vor- und Nachteile der Arbeit im Team.

Zu Beginn des Projektes bekommen die Studierenden eine Einweisung zu Zielen, erwarteten Ergebnissen, Projektablauf und Arbeit im Team sowie Bewertung und Einordnung in die Gesamtausbildung. Oft erfolgt in diesem Zusammenhang eine kurze Wiederholung der bereits vermittelten Unterrichtskenntnisse zum Projektmanagement. Nach der Phase der Teamfindung und Festlegung der Verantwortlichkeiten im Team startet die erste Projektwoche mit der Projektplanung und parallel mit der Analyse der Aufgabenstellung. In der zweiten Projektwoche folgt die Aufwands- und Kostenschätzung durch den Projektmanager, die Klärung der offenen Fragen mit dem Auftraggeber sowie die Ausarbeitung eines ersten objektorientierten Grobentwurfs. Sobald die Anwendungsfälle beschrieben und ein erstes Klassenmodell entstanden ist, wird ein Testkonzept erarbeitet. Hierbei erhalten die Projektgruppen fachliche Unterstützung sowie geeignete Vorgaben und Beispiele. Die Studierenden müssen die Anforderungen an die Teamarbeit, die Dokumentation und die Qualitätssicherung verstehen und parallel entsprechende Maßnahmen einleiten. Bereits zu Beginn der dritten Woche wird ein erstes Review durchgeführt, in welchem die Teams ihre Analyse- und Entwurfsergebnisse gegenüber dem Auftraggeber präsentieren und darstellen, welche Lieferungen und Leistungen der Kunde für welches Geld und in welcher Zeit erhalten kann. Mit dem Review des Entwurfs wird die Freigabe zur Realisierung durch den Auftraggeber erteilt bzw. Nachbesserungen am Entwurf gefordert. Die Arbeitsaufgaben in der dritten und vierten Woche sind ganz auf die Implementation und die Vorbereitung der Testphase ausgerichtet. Spätestens ab jetzt ist es notwendig, dass allen Teammitgliedern klar ist, wie das Gesamtergebnis der Lösung aussehen soll. Alle Mitglieder, die nicht an der Umsetzung des objektorientierten Entwurfs beteiligt sind, übernehmen Dokumentationsaufgaben zur Darstellung der objektorientierten Software-Lösung einschließlich Benutzerdokumentation sowie der Teilergebnisse zur Produkt- und Projektbeschreibung. Ein grober Projektplan wird den Studierenden vorgegeben. Sie müssen danach gemeinsam die terminlich fest definierten Meilensteine den entsprechenden Projektphasen zuordnen. Somit wird das Projekt für die Teilnehmer überschaubar und sie können es wo- 299 -

chenweise und ergebnisorientiert steuern. Die Anforderungen an die jeweiligen Meilensteinergebnisse werden zu Beginn des Projektes erläutert, bei Dokumenten eine grobe Inhaltsangabe vorgegeben und während des Projektablaufes entweder durch den Projektleiter oder den Auftraggeber präzisiert.

Nr. 1. 1.1. 1.2. 1.3. M1 2. 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. M2 M3 M4 3. 3.1. 3.2. 3.3. M5 4. 4.1. 4.2. 4.3. M8 M9 5. 6. 6.1. M6 6.2. M7

Arbeitspaket Analyse Analyse der Aufgabenstellung Anwendungsfallbeschreibung Offene Fragen Analyseergebnis / Fragen Entwurf Systemgrenzen, -umgebung Systemobjekte (Klassen) Systemfunktionen (Methoden) Schnittstellenbeschreibung Architekturbeschreibung Präsentation vorbereiten Review Entwurf Architekturbeschreibung Systembeschreibung Design / Programmierung Implementierung Klassen Implementierung Methoden Implementierung Testrahmen Softwarelösung Test Testfälle u. Testdaten Funktionstest durchführen Bedien- u. Schnittstellentest Testkonzept Testprotokoll Projektmanagement Projektmanagement Dokumentation Systemdokumentation Systemdokumentation Benutzerdokumentation Benutzerdokumentation

KW 01 KW 02 KW 03 KW 04 KW 05

Abbildung 1: Projektplan als Balkendiagramm mit Meilensteinen

- 300 -

3 Organisation und Arbeitsweise Das Softwareprojekt wird parallel in zwei Klassen mit Teams von 4-5 Mitarbeitern durchgeführt. Bisher bekamen die Gruppen jeweils die gleiche Aufgabenstellung. In diesem Jahr erfolgte zum ersten Mal der Versuch, eine komplexe Aufgabenstellung mit Teilteams, also für jede Gruppe eine separate Aufgabenstellung, zu bewältigen. Der Aufbau der Organisation erfolgt aufgrund funktionaler Leistungs- und Aufgabenorientierung im Team. Teammitglieder sind Experten mit unterschiedlichem Wissen und Fertigkeiten. Die koordinierte Bewältigung der Teamaufgaben erfolgt durch die Teammitglieder selbst (Selbstorganisation im Team, Dozenten stehen als Coach zur Verfügung). Verschiedene Funktionen werden über definierte Aufgaben (Rollen) wahrgenommen (Rollenverteilung: soziale Rollen und fachliche Rollen). Die Zusammensetzung des Teams ist je nach Bedarf an Experten innerhalb des Projektes änderbar (Unterschied zwischen Verantwortlichkeit und Ausführung der Aufgaben). 3.1 Projektorganisation

Vor Projektstart ist es wichtig, die externen und internen Verantwortlichkeiten zu erklären, damit die Teams ihre Ansprechpartner genau kennen und in der Lage sind, die Rollenverteilung innerhalb des Teams selbstständig vorzunehmen. Die Dozenten übernehmen die Rollen als Auftraggeber (Frau Vocke), Projekteigner (auch Gesamtprojektleiter - Frau Woigk) und der Niederlassungsleiter als Projektsponsor. Darüber hinaus sind weitere Dozenten zur fachlichen Unterstützung (Coach) benannt. Bei den internen Rollen unterscheiden wir soziale und fachliche Rollen. Jedes Teammitglied übernimmt dabei mindestens eine fachliche Rolle verantwortlich. Zu den sozialen Rollen gehören der Projektmanager (PM), Dokumentationsverantwortliche (Dok) und der Qualitätssicherer (QS). Die fachlichen Rollen wie Analytiker (A), Designer (E/D), Programmierer (P), Tester (T) orientieren sich am Softwareentwicklungsprozess.

Abbildung 2: Projektorganisation (nach Karol Frühauf, INFOGEM AG)

- 301 -

Die Studierenden merken schnell, dass es zwischen Verantwortlichkeit (Rollenfestlegung) und Tätigkeitsausführung Unterschiede gibt und dass diese bewusst bei der Projektplanung berücksichtigt werden müssen. Außerdem finden sie in kurzer Zeit heraus, dass sie eine Stellvertreterregelung (x – verantwortlich, o – stellvertretend verantwortlich) brauchen, um den geplanten Projektablauf sichern zu können. Name Vorname Kern Silvio Hamann Rolf Robin Stiller Beyer Steve Stundensätze in

PM DOK x x o o 50 40

QS x o 40

A o x 50

E x o 50

D o x

P

50

30

o x

T

x 30

Abbildung 3: Beispiel einer Verantwortungsmatrix (Rollenverteilung)

3.2 Teambildung

Die Studierenden im 2. Studienjahr haben bereits gemeinsam kleinere Gruppenprojekte gelöst und kennen die Stärken und Schwächen der anderen. Das Software-EngineeringProjekt wird lange vor Projektbeginn angekündigt und den Studierenden der Auftrag erteilt, ihre Gruppe selbst zu bilden. Dazu werden ihnen die Rollen sowie die dazugehörigen Aufgaben innerhalb des Teams erklärt und einige Tipps gegeben. Das bewusste Nicht-Eingreifen der Dozenten in die Teambildung erhöht die Motivation der Gruppen enorm. 3.3 Regeln für die Arbeitsweise im Projekt

Mit den Studierenden werden zu Beginn des Projektes einige grundlegende Regeln des Umgangs innerhalb von „Expertengruppen“ erarbeitet und die Vor- und Nachteile der Teamorganisation besprochen. Diese Diskussion ist für die Teilnehmer besonders wichtig, um zu verstehen, dass jeder zu dem Gruppenergebnis seinen Beitrag leisten muss und kein Teilergebnis wichtiger ist als das andere. Die Festlegung, dass jeder mindestens eine fachliche Rolle verantwortlich übernehmen muss, garantiert, dass nicht nur einer die Verantwortung trägt und die anderen „arbeiten“ müssen. Weiterhin werden strenge Regeln für die Kommunikation mit dem Auftraggeber festgelegt. Einige Studierende lernen in diesem Rahmen das erste Mal, dass auch in Projekten eine email-Kommunikation bestimmten Mindestanforderungen genügen muss. Die Festlegung von Regeln innerhalb der Gruppe unterliegt der Selbstorganisation und wird von außen nicht beeinflusst. In diesem Punkt mussten auch die Dozenten lernen, in der Projektphase als Coach und nicht als Lehrkraft aufzutreten. Damit jedes Teammitglied aber bei gravierenden Problemen auch die Möglichkeit hat, diese nach außen zu kommunizieren, wurden den Studierenden Projektsituationen geschildert, in denen Maßnahmen zur Eskalation greifen können.

- 302 -

3.4 Projektplanung

Für die Projektplanung wird ein schrittweise Vorgehen gewählt, damit die Projektmanager der Teams sich auf die gerade aktuellen Aufgaben konzentrieren und alle Teammitglieder so schnell wie möglich effektiv nach dem Plan arbeiten können. Dazu wird zuerst ein Meilensteinplan mit Terminen und Ergebnissen erstellt. Dieser wird durch Arbeitspakete untersetzt, denen Rollen (siehe Projektorganisation) zugeordnet werden. Die jeweiligen Verantwortlichen schätzen danach grob den Aufwand für jedes Arbeitspaket ein. Ist der geschätzte Aufwand größer als 2 Manntage, müssen die Arbeitspakete in Teilaufgaben unterteilt werden. Die geplanten Kosten werden nach vorgegebenen Stundensätzen berechnet. Nr. Arbeitspaket Rollen Ress. SOLL IST SOLL IST Gesamtaufwand 20,5 MT 18,5 MT 7.160,0 MT 6.440,0 MT 50 3,5 MT 3,5 MT 1.400,00 1.400,00 1. Analyse 1.1. Analyse der Aufgabenstellung A 1,5 MT 1,5 MT 600,00 600,00 1.2. Anwendungsfall-Beschreibung A 1,0 MT 1,0 MT 400,00 400,00 1.3. Offene Fragen A 1,0 MT 1,0 MT 400,00 400,00 M1 Analyseergebnis / offene Frageliste 2. Entwurf 50 7,0 MT 5,0 MT 2.800,00 2.000,00 2.1. Systemgrenzen, -umgebung beschreiben E 1,5 MT 0,5 MT 600,00 200,00 2.2. Systemobjekte (Klassen) E 1,0 MT 0,5 MT 400,00 200,00 2.3. Systemfunktionen (Methoden) E 2,0 MT 1,0 MT 800,00 400,00 2.4. Schnittstellenbeschreibung E/D 1,5 MT 1,5 MT 600,00 600,00 2.5. Architekturbeschreibung E/D 0,5 MT 0,5 MT 200,00 200,00 2.6. Präsentation vorbereiten E 0,5 MT 1,0 MT 200,00 400,00 M2 Review Entwurf

Abbildung 4: Ausschnitt aus Projektplan

Erst wenn jedes Teammitglied seine Verantwortung innerhalb des Teams kennt, werden den Aufgaben die Personen (Ressourcen) zugeordnet, die jeweils die Aufgabe ausführen sollen. So lernen die Studierenden, eine situationsbezogene Arbeitsteilung und eine konsequente Übernahme von Verantwortung vorzunehmen. Durch die Integration des Projektmanagement in die Projektarbeit sind die Studierenden gezwungen, Softwareprojekte nicht nur fachspezifisch zu betrachten. Sie müssen ihre Projekte ebenfalls unter wirtschaftlichen Gesichtspunkten erarbeiten, bewerten und dem Markt zum Angebot bringen. Dabei werden folgende Fähigkeiten trainiert wie • • • • •

Planung von Teilschritten, Aufwandsschätzung und Terminplanung für die einzelnen Arbeitspakete, Kostenplanung für die einzelnen Arbeitspakete und Gesamtkostenplanung, Selbstmanagement und Kommunikationsfähigkeit sowie Abrechenbarkeit von Teilschritten gegenüber dem Auftraggeber.

Bei der Projektplanung wird den Studierenden freigestellt, welche Werkzeuge sie verwenden. Von Seiten des Gesamtprojektleiters wird dabei nur darauf geachtet, dass die Projekte vergleichbar bleiben.

- 303 -

3.5 Projektcontrolling

Während des Gesamtprojektes werden die Aufgabenpakete detailliert und die Ressourcen zugeteilt. Die entstandenen IST-Aufwände werden beim Projektmanager abgerechnet, so dass jederzeit ein aktueller Projektfortschritt erkennbar ist. Die tatsächlichen Aufwände der einzelnen Teammitglieder werden nicht nach außen bekannt gemacht, sondern am Ende jeder Woche ein Fortschrittsbericht beim Gesamtprojektleiter abgegeben. Dieser beinhaltet eine Zusammenfassung der Wochenarbeitsergebnisse, der erledigten Arbeitspakete (bezugnehmend auf den Projektplan) sowie erkannter Probleme mit Lösungsvorschlägen und eingeleiteten Maßnahmen. Durch das strukturierte Vorgehen können die Teams ihre Planungen und ihren Arbeitsfortschritt miteinander vergleichen. Jedes Team muss im wöchentlich stattfindenden Projektmeeting benennen können, wie viel Prozent vom geplanten Aufwand bereits verbraucht wurde und eine Prognose abgeben, wie viel noch benötigt wird. Am Ende des Projektes visualisieren die Teams den SOLL-IST-Vergleich bezüglich der Aufwände und der Kosten nach den Projektphasen und für das Gesamtprojekt. Die Abbildung 5 zeigt beispielhaft die Verteilung der tatsächlichen Aufwände aus einem konkreten Projekt. Anhand der graphischen Darstellungen werden in der Auswertung die Projekte miteinander verglichen und Schlussfolgerungen für eine verbesserte Projektdurchführung gemeinsam mit den Studierenden erarbeitet.

Verteilung der IST-Aufwände 6. Dokumentation 11% 5. Projektmanagement 5%

1. Analyse 19%

4. Test 16% 2. Entwurf 27%

3. Design / Programmierung 22%

Abbildung 5: Ausschnitt aus dem SOLL-IST-Vergleich

Eine Auswertung zur prozentualen Verteilung der Aufwände wird außerdem dazu genutzt, die ersten Erfahrungen der Studierenden bei der eigenen Aufwandsabschätzung und von gesamten Softwareprojekten zu evaluieren. Die Planabweichungen werden diskutiert und gemeinsam Gründe für die entstandenen Differenzen gesucht und benannt.

- 304 -

4 Darstellung eines Projekt-Beispiels 4.1 Aufgabenstellung

Im letzten Jahr wurde von den Teams ein Projekt für eine objektorientierte Realisierung für den Zahlungsverkehr einer Bank (Backoffice) mit folgendem Inhalt durchgeführt: Entwerfen und entwickeln Sie ein komplettes Informationssystem zur Abwicklung der Zahlungsverkehrsvorgänge in einer Bank. Folgendes Systemverhalten ist zu realisieren: „Der Kunde kann am Geldautomaten Geld einzahlen, Geld abheben, sich einen Kontoauszug seiner letzten Buchungen ausdrucken, Geld von eigenen Konten auf andere eigene Konten bei der Bank überweisen und sich über die Kontostände aller Konten bei dieser Bank eine Kontoinformation anzeigen bzw. ausdrucken.“ Erstellen Sie dazu eine Spezifikation (Entwurf) nach definiertem Vorgehen und vorgegebener Gliederung. Beschreiben Sie die Schnittstellen zum Geldautomaten. Benutzen Sie die Textanalyse und die Methode der Objektorientierten Analyse. Die Realisierungsvariante (Architektur) ist bekannt und soll kurz beschrieben werden. Programmiersprache ist C++. Die realisierte Lösung ist sowohl für andere Entwickler (Systemdokumentation), als auch für die späteren Benutzer zu beschreiben (Benutzerdokumentation). Nutzen Sie neben den Office-Werkzeugen Visio zur Modellierung mit UML sowie Visual Studio zur Umsetzung. Präsentieren Sie Ihre Ergebnisse gegenüber dem Auftraggeber. 4.2 Ergebnisse

Die Projektteams reichen am Ende eine komplette Projektdokumentation sowie eine Produktdokumentation mit Systemabgrenzung, fachlicher Spezifikation (UML), Architekturbeschreibung, System- und Benutzerdokumentation sowie die realisierte SoftwareLösung zur Bewertung ein. Bestandteil der Produktdokumentation ist eine Testdokumentation mit Testkonzept und Testprotokoll. 4.3 Bewertung

Bewertet werden die Projekte in vier Teilen: 1.

Gesamtleistung des Teams,

2.

Einschätzung jedes Teammitglieds durch die Gruppe,

3.

Anteil der Einzelleistung am Gesamtergebnis des Teams,

4.

Präsentation der Projektleistung.

Die Bewertung der Gesamtleistung erfolgt entsprechend Korrektheit des Entwurfs und Durchgängigkeit der Umsetzung sowie der Einhaltung der Anforderungen. Die Bewer-

- 305 -

tung der Einzelleistung erfolgt nach einem vorgegebenen Fragebogen durch die Gruppe. Mit einem weiteren Fragebogen hat jeder Teilnehmer die Möglichkeit, die Gruppenarbeit und seine eigene Leistung einzuschätzen sowie ein generelles Feedback zu geben. Der Anteil der Einzelleistung wird aus den Angaben zu übernommener Verantwortlichkeit und ausgeführten Aufgaben durch den Dozenten bewertet.

5 Erfahrungen Da die Studierenden den Gewinn an fachlichen sowie sozialen Fähigkeiten und Fertigkeiten selbst als sehr hoch einschätzen, wird das Software-Projekt bereits zum 5. Mal durchgeführt und ist damit integraler Bestandteil der Ausbildung am b.i.b. Dresden. Die Studierenden sehen das Projekt als Herausforderung an und gehen mit großer Motivation an die Realisierung der Projekte, weil sie eine reale Aufgabenstellung umsetzen. Ernüchterung tritt oft ein, weil sie mit vielen ungewohnten Dingen konfrontiert werden. Fast alle Studierenden erkennen, dass sie ihre bisherige Einstellung zur Realisierung von Software überdenken müssen und sie im „Alleingang“ keinen Erfolg haben werden. Der größte Effekt ist jedoch die verbesserte Kommunikation und der Umgang mit Problemen. Die Studierenden bewerten die eigene Teamfähigkeit und die Gruppenleistung erstaunlich objektiv. Von ihnen wird eingeschätzt, dass viele Zusammenhänge durch das Projekt erst klar werden und sie lernen müssen, sich selbst zu managen und ihre eigenen Leistungen anderen zu „verkaufen“. Eine genaue Planung und eine ergebnisorientierte Vorgehensweise machen die Durchgängigkeit des Software-Projektes in so begrenzter Zeit erst möglich. Potenziale sehen wir bei der Abstimmung zwischen den Fachdozenten für Programmierung, Datenbanken und Oberflächenprogrammierung, um die Studierenden intensiver auf das Projekt vorzubereiten sowie im integrierten Einsatz von Softwareentwicklungswerkzeugen. Um die Studierenden auf Anforderungen in der Wirtschaft vorzubereiten, sollte eine Projektaufgabenstellung entsprechend komponentenbasierter Softwareentwicklung aufbereitet und die notwendigen technischen Voraussetzungen dafür geschaffen werden. Auftraggeber aus der Industrie und ein größerer Zeitfond wären wünschenswert, um das Software-Projekt wie an der TU Darmstadt [BS97] stärker qualitätsgetrieben durchzuführen und den Einsatz der Dozenten auf die fachliche Unterstützung zu konzentrieren. Unsere Erfahrung zeigt, dass die Studierenden einer Berufsfachschule (16 - 20 Jahre) sehr gut mit komplexen Aufgabenstellungen umgehen können, dass sie bei entsprechender Vorbereitung schwierige Problemsituationen meistern und die Eigenmotivation in dem Maße steigt, wie sie eigene Lösungsansätze gefunden haben und umsetzen konnten. Der Einsatz und Aufwand aller Beteiligten hat sich gelohnt!

- 306 -

Literaturverzeichnis [Ba00]

Balzert, H.: Lehrbuch der Software-Technik I. Spektrum-Verlag, Berlin, 2000.

[BS97]

Brunner, M.; Schroeder, U.: Anwendung innovativer Lernformen bei der Software Engineering Ausbildung mit Unternehmensbeteiligung, TU Darmstadt, 5. Workshop "Software Engineering Unterricht an Hochschulen" Februar 1997.

[Fr02]

Frühauf, K.: Software-Projektmanagement, Seminarunterlagen. IT Akademie, 2002.

[Wu00]

Wunderer, R.: Führung und Zusammenarbeit. Luchterhand, 2000.

- 307 -