Software-Engineering in der beruflichen Ausbildung – Simulation realer Projektsituationen
Dipl.-Ing. Heike Vocke Dipl.-Kfm. Ulrike Woigk Unternehmensberatung H. Vocke b.i.b. Bildungszentrum für informations- Manfred-von-Ardenne-Ring 20, F verarbeitende Berufe gGmbH
D-01099 Dresden Paradiesstraße 40
h.vocke@gmx.de D-01217 Dresden
ulrike.woigk@bib.de
Abstract: Am b.i.b. Dresden werden Berufsfachschüler im Software-Engineering- Projekt mit möglichst realen Projektsituationen bei der Entwicklung objektorien- tierter 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äsen- tation der eigenen Projektergebnisse gelegt. Es werden Vorgehen, Organisation und Bewertung des Projektes beschrieben. An einem konkreten Beispiel wird dar- gestellt, welche Handlungskompetenz sich die Schüler erarbeiten sollen. Die Auto- ren gehen auf mögliche Problem- und Konfliktsituationen ein, nennen ihre Erfah- rungen 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 Softwareentwicklungs- projekten 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 fach- bezogenen 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
oder denken, die Aufgaben auch allein lösen zu können. Am Ende sind sie immer er- staunt, 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 Fertig- keiten wie zum Beispiel Selbstdisziplin, eigene Motivation, Motivation im Team, kreati- ver 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 Studie- renden 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 Terminein- haltung. 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,
3. klare Aufgabenformulierung,
4. kundenfreundliche Aufbereitung und Darstellung der erbrachten Teil- und Ge- samtleistungen,
5. praktisches Erkennen der Vor- und Nachteile der Arbeit im Team.
Zu Beginn des Projektes bekommen die Studierenden eine Einweisung zu Zielen, er- warteten Ergebnissen, Projektablauf und Arbeit im Team sowie Bewertung und Ein- ordnung 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 Pro- jektmanager, die Klärung der offenen Fragen mit dem Auftraggeber sowie die Ausar- beitung eines ersten objektorientierten Grobentwurfs. Sobald die Anwendungsfälle be- schrieben 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äsen- tieren 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 Auftragge- ber 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 Soft- ware-Lösung einschließlich Benutzerdokumentation sowie der Teilergebnisse zur Pro- dukt- und Projektbeschreibung.
Ein grober Projektplan wird den Studierenden vorgegeben. Sie müssen danach gemein- sam die terminlich fest definierten Meilensteine den entsprechenden Projektphasen zu- ordnen. Somit wird das Projekt für die Teilnehmer überschaubar und sie können es wo-
chenweise und ergebnisorientiert steuern.
Die Anforderungen an die jeweiligen Meilensteinergebnisse werden zu Beginn des Pro- jektes erläutert, bei Dokumenten eine grobe Inhaltsangabe vorgegeben und während des Projektablaufes entweder durch den Projektleiter oder den Auftraggeber präzisiert.
Abbildung 1: Projektplan als Balkendiagramm mit Meilensteinen Nr. Arbeitspaket
1. Analyse
1.1. Analyse der Aufgabenstellung 1.2. Anwendungsfallbeschreibung 1.3. Offene Fragen
M1 Analyseergebnis / Fragen 2. Entwurf
2.1. Systemgrenzen, -umgebung 2.2. Systemobjekte (Klassen) 2.3. Systemfunktionen (Methoden) 2.4. Schnittstellenbeschreibung 2.5. Architekturbeschreibung 2.6. Präsentation vorbereiten M2 Review Entwurf
M3 Architekturbeschreibung M4 Systembeschreibung
3. Design / Programmierung 3.1. Implementierung Klassen 3.2. Implementierung Methoden 3.3. Implementierung Testrahmen M5 Softwarelösung
4. Test
4.1. Testfälle u. Testdaten 4.2. Funktionstest durchführen 4.3. Bedien- u. Schnittstellentest M8 Testkonzept
M9 Testprotokoll 5. Projektmanagement
Projektmanagement 6. Dokumentation 6.1. Systemdokumentation M6 Systemdokumentation 6.2. Benutzerdokumentation M7 Benutzerdokumentation
KW 05 KW 01 KW 02 KW 03 KW 04
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 Aufgaben- orientierung im Team. Teammitglieder sind Experten mit unterschiedlichem Wissen und Fertigkeiten. Die koordinierte Bewältigung der Teamaufgaben erfolgt durch die Team- mitglieder selbst (Selbstorganisation im Team, Dozenten stehen als Coach zur Verfü- gung). Verschiedene Funktionen werden über definierte Aufgaben (Rollen) wahrge- nommen (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 Rol- lenverteilung innerhalb des Teams selbstständig vorzunehmen. Die Dozenten über- nehmen die Rollen als Auftraggeber (Frau Vocke), Projekteigner (auch Gesamt- projektleiter - 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 Teammit- glied ü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)
Die Studierenden merken schnell, dass es zwischen Verantwortlichkeit (Rollenfest- legung) 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 her- aus, dass sie eine Stellvertreterregelung (x – verantwortlich, o – stellvertretend verant- wortlich) brauchen, um den geplanten Projektablauf sichern zu können.
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-Engineering- Projekt 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 wich- tig, 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 festge- legt. 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 ge- schildert, in denen Maßnahmen zur Eskalation greifen können.
Name Vorname PM DOK QS A E D P T
Kern Silvio x x o
Hamann Rolf x o x o
Stiller Robin o x o x
Beyer Steve o o x x
50 40 40 50 50 50 30 30
Stundensätze in
3.4 Projektplanung
Für die Projektplanung wird ein schrittweise Vorgehen gewählt, damit die Projektma- nager der Teams sich auf die gerade aktuellen Aufgaben konzentrieren und alle Team- mitglieder 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) zugeord- net 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.
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 ver- wenden. Von Seiten des Gesamtprojektleiters wird dabei nur darauf geachtet, dass die Projekte vergleichbar bleiben.
Nr. Arbeitspaket Rollen Ress. SOLL IST SOLL IST
Gesamtaufwand 20,5 MT 18,5 MT 7.160,0 MT 6.440,0 MT
1. Analyse 50 3,5 MT 3,5 MT 1.400,00 1.400,00
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
3.5 Projektcontrolling
Während des Gesamtprojektes werden die Aufgabenpakete detailliert und die Ressour- cen zugeteilt. Die entstandenen IST-Aufwände werden beim Projektmanager abgerech- net, 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 abgege- ben. Dieser beinhaltet eine Zusammenfassung der Wochenarbeitsergebnisse, der erle- digten 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 Arbeits- fortschritt 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 Projekt- durchführung gemeinsam mit den Studierenden erarbeitet.
Verteilung der IST-Aufwände
1. Analyse 19%
2. Entwurf 3. Design / Pro- 27%
grammierung 22%
4. Test 16%
5. Projekt- management
5%
6. Dokumen- tation
11%
Abbildung 5: Ausschnitt aus dem SOLL-IST-Vergleich
Eine Auswertung zur prozentualen Verteilung der Aufwände wird außerdem dazu ge- nutzt, 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.
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 Konto- auszug seiner letzten Buchungen ausdrucken, Geld von eigenen Konten auf andere ei- gene 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 vorge- gebener Gliederung. Beschreiben Sie die Schnittstellen zum Geldautomaten. Benutzen Sie die Textanalyse und die Methode der Objektorientierten Analyse. Die Realisierungs- variante (Architektur) ist bekannt und soll kurz beschrieben werden. Programmierspra- che ist C++. Die realisierte Lösung ist sowohl für andere Entwickler (Systemdokumenta- tion), als auch für die späteren Benutzer zu beschreiben (Benutzerdokumentation). Nut- zen 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), Archi- tekturbeschreibung, System- und Benutzerdokumentation sowie die realisierte Software- Lösung zur Bewertung ein. Bestandteil der Produktdokumentation ist eine Testdoku- mentation 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-
tung der Einzelleistung erfolgt nach einem vorgegebenen Fragebogen durch die Gruppe.
Mit einem weiteren Fragebogen hat jeder Teilnehmer die Möglichkeit, die Gruppenar- beit und seine eigene Leistung einzuschätzen sowie ein generelles Feedback zu geben.
Der Anteil der Einzelleistung wird aus den Angaben zu übernommener Verantwortlich- keit und ausgeführten Aufgaben durch den Dozenten bewertet.
5 Erfahrungen
Da die Studierenden den Gewinn an fachlichen sowie sozialen Fähigkeiten und Fertig- keiten 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 Moti- vation 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 Prob- lemen. 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 Durch- gä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 vorzu- bereiten sowie im integrierten Einsatz von Softwareentwicklungswerkzeugen. Um die Studierenden auf Anforderungen in der Wirtschaft vorzubereiten, sollte eine Projektauf- gabenstellung 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 durchzu- fü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 entsprechen- der 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!
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.
