ZIDline
TISS Epistemologie I
M. Suppersberger, P. Leitner, A. Knarek, W. Kleinert, Th. Grechenig
Die Perspektive moderner Softwaretechnik und die Projektziele 2010

TISS hat im Jahr 2009 die ersten leistungsfähigen Services eingeführt, im Hintergrund die fundamentale Neustrukturierung der Systemlandschaft vorbereitet und die Basis für die kommenden entwicklungstechnischen Herausforderungen gelegt. Der vorliegende Artikel befasst sich mit den Perspektiven moderner Softwaretechnik, dem de facto Status der Softwaretechnik als Ingenieursfach und reflektiert damit den epistemologischen Kontext des Projektes.

Der Mittelpunkt der pragmatischen Arbeit an TISS waren Tätigkeiten an der Infrastruktur im Hintergrund sowie deren Prüfung an ersten belastbaren Applikationen: die Etablierung einer zukunftsweisenden technischen Architektur, die interne und externe Systemanbindungen möglichst einfach gestaltet und flexible Anpassungen erlaubt, sowie die parallele Einführung von leistungsfähigen Anwendungen. Die Projektpraxis zeigte, dass bei der Ablösung und Migration der teilweise sehr alten Systeme viele oftmals nicht bzw. nie kommunizierte oder dokumentierte Probleme und Anforderungen sichtbar werden, die im Neusystem zu berücksichtigen sind. Der vorliegende Artikel zeigt diese Herausforderungen und Erfahrungen am Beispiel der erfolgreichen Einführung des Student Self Service und setzt TISS in den Rahmen der Perspektiven moderner Softwaretechnik. Der Artikel schließt mit den daraus abzuleitenden, wesentlichen Projektzielen für das Jahr 2010.

Start für das Student Self Service

Ende Mai 2009 wurde das Student Self Service an der TU Wien eingeführt, das allen Studierenden ermöglicht, Einzel- und Sammelzeugnisse sowie die FLAG-Bestätigungen selbst zu generieren und auszudrucken. Für alle (Verwaltung, Post, Studierende) eine Verbes­serung, 200.000 Zeugnisse finden pro Jahr einen neuen Weg. Da mit der Einführung die gleichzeitige Einstellung der alten Prozesse des Dokumentendrucks einherging, galt es von Beginn an eine leistungsfähige Plattform, die modernes interagierendes Workflow- und Applikationsmanagement erlaubt und dadurch eine effiziente Universitätsverwaltung ermöglicht, bereitzustellen. Der Nutzungsverlauf des Student Self Service innerhalb der ersten 5 Monate wird in Abbildung 1 durch die Anzahl der täglich erstellten Dokumente visualisiert. Aktuelle Zahlen zeigen, dass innerhalb dieses Zeitraums rund 34.000 Einzelzeugnisse, 11.300 Sammelzeugnisse und 3.200 FLAG-Bestätigungen von den Studierenden selbst generiert wurden. Diese Dokumente können nun von zu Hause oder von jedem beliebigen Zugang aufgerufen, als PDF heruntergeladen und bei Bedarf ausgedruckt werden. Neben den Einsparungen für die Universität aufgrund des verminderten Papierverbrauches, bringt dieses Service auch zahlreiche Entlastungen auf Mitarbeiterebene mit sich. Rückmeldungen von Seiten der Studierenden zeigen, dass das Student Self Service, aufgrund der zeiteffizienten und flexiblen Handhabung, ausgezeichnet angenommen wird.

Bei der Entwicklung und Einführung des Student Self Service wurden die absehbaren Anforderungen berücksichtigt und in der Gesamtarchitektur nachhaltig integriert. Das Team geht davon aus, dass die Arbeitspragmatik mit einer derartigen Online-Systematik zu analogen Neu- und Zusatzforderungen führt, und ist darauf vorbereitet. Nach der Service­einführung wurde mit der Implementierung von weiteren Funktionalitäten begonnen. Verbesserungsvorschläge der Anwender wurden evaluiert und werden schrittweise umge­setzt. So wurden beispielsweise erweiterte Funktionalitäten zur Validierung der Dokumente durch Dritte sowie die Kontrollmöglichkeiten durch die Studierenden auf der Plattform berück­sichtigt. Auch weitere Dokumente, wie die Studienerfolgsbestätigung und die Frem­den­studienbestätigung können mittlerweile generiert werden. Das Studienblatt sowie die Studienbestätigung werden folgen.

Aus projektspezifischer und softwaretechnischer Sicht ergaben sich bei der Einführung und Erweiterung des Student Self Service die folgenden wesentlichen Herausforderungen:

  • Aufwändige Analyse von komplexer Logik im Altsystem, wobei kaum oder nur spärlich Dokumentationen vorhanden waren.
  • Kompensation fehlender und fehlerhafter Attribute durch Entwicklung geeigneter Algorithmen zur Vervollständigung der inkonsistenten Datensätze.
  • Identifikation signifikanter Testfälle zur Prüfung spezifischer Kombinationen von Studien und Prüfungen für mehr als 130.000 aktive Studierende, Absolventen und Studienabbrecher.
  • Prüfung, Erkennung, Koordination, Abgleich und zweckmäßige Migration von 40 Jahren (TU- und Gesetzes-) Geschichte.

Durch entsprechende Maßnahmen und besonderen Einsatz des gesamten Projektteams sowie durch die ausgezeichnete Unterstützung der Fachabteilungen und Spezialisten im Haus ist es gelungen, auch solche Hürden zu überwinden und damit erste wichtige praktische Schritte in Richtung eines modernen Hochschulsystems zu setzen. Letztendlich zeigte sich, dass bei der laufenden Optimierung des Services das konstruktive Feedback der Anwender von ganz essentieller Bedeutung ist.

Moderne Softwaretechnik in einem komplexen Haus wie der TU Wien ist keine Einbahnstraße. Es wird hier ein System mit TU-Angehörigen von TU-Angehörigen für TU-Angehörige etabliert. Ihre Mitarbeit, Ihr Input ist laufend wichtig. Ihr Verständnis für diese Aufgabe auch.

Zum besseren Verständnis der Aufgabe wollen wir hier den industriellen und fachlichen Kontext eines sehr großen Werkstückes wie TISS allgemeiner beleuchten: ein Exkurs über die Rahmenbedingungen und Herausforderungen moderner Softwaretechnik:

Perspektiven moderner Softwaretechnik

Software wird nunmehr „erst“ seit gut 50 Jahren entwickelt und ist damit ein ver­gleichs­weise junges Ingenieursfach. Im Verhältnis etwa zum Hochbau oder zum Maschinen­bau. Ein halbes Jahrhundert Softwaretechnik mag einem talentierten jungen Web-, Embedded- oder Mobile-Programmiertalent als ewig lange Zeit erscheinen, im Sinne einer qualifizierten, etab­lierten und industrialisierten Ingenieursdisziplin ist das eine kurze, ja in mancher Hinsicht viel zu kurze Zeitspanne. Das Bauwesen etwa (Beispiel Brückenbau) ist so alt wie die Zivilisation der Menschheit. Der industrielle Maschinenbau (Beispiel Buchdruck) existiert zumindest seit 500 Jahren und sogar die sehr moderne Ingenieursdisziplin „Automobilbau“ hat mit dampfge­triebenen Fahrzeugen schon vor 200 Jahren begonnen.

Komplexitätstreibend kommt hinzu, dass sowohl im Brückenbau als auch im Automobilbau der Auftragsgegenstand in der Regel deutlich genauer spezifizierbar ist als im Softwarebau.

Es geht hier um den Reifegrad eines Fachbereiches. „Reife“ (= erfahrene und industriali­sierte) Disziplinen zeichnen sich u. a. dadurch aus, dass ihre Standardfälle wohl­definiert, gut genormt, kosten- und zeitmäßig in kleinen Bandbreiten verlässlich schätzbar sind. Ein­familienhäuser und Abwasserkanäle kann das industrialisierte Bauwesen heute sehr verläss­lich bepreisen und fertigstellen, wenn die Ausführenden professionell sind und keine besonders unvorhergesehenen äußeren Umstände auftreten.

„Industrialisierung“ bedeutet, dass eine Disziplin die Transformation vom genialen Kunstwerk und Meister-streich (der erste Brennstoffmotor) zum Kunsthandwerk (der erste Porsche) und schließlich zum industrialisierten Produkt (Kleinwagen in Großserie) über einen ganzen Wirtschaftsraum und Markt hinweg soweit in mehreren Wellen hinter sich gelassen hat, dass die Disziplin genau weiß,

  • was ein „Kunstfall“ für Ausnahmekönner ist,
  • was eine sehr komplexe Aufgabe mit Risiken und
  • was ein alltäglicher Standardfall ist, der in Zeit- und Kostengröße sehr gut prognos­tizierbar ist sowie dessen Risiken gering und vernachlässigbar sind.

Diesen Reifegrad der Industrialisierung hat das Gebiet der Softwaretechnik heute nur in kleinen oder speziellen Teilbereichen erreicht. Große Teile der heute real gefertigten Software sind gutes Kunsthandwerk, ohne dass dies den Beteiligten in diesem Sinne bewusst ist. Gar nicht so wenige Softwareprojekte bezeichnen sich selbst mit dem Ordnungsbegriff der „Entwicklung“, obwohl sie ontologisch wohl präziser unter „Forschung und Entwick­lung“ anzusiedeln wären. Heute besteht nach wie vor zu Beginn von vielen Projek­ten keine Klarheit darüber,

  • ob die reale Machbarkeit des Projektzieles überhaupt gewährleistet ist,
  • was am Entwicklungsende als Funktionalität vorliegen soll und was nicht,
  • ob der vorliegende Ressourcenrahmen für das angedachte Projekt reicht.

Eine „reife“ Disziplin hat für 80% der Aufgaben Standardlösungen und Produkte, für weitere 18% gesicherte Verfahren oder geeignete Fachleute und Spezialisten und für 2% der Aufgabenstellung ist echte Innovation, Erfindung, Forschung erforderlich. In der Software­branche sind diese Größen noch umgekehrt gelagert. Je nach Teilgebiet der Softwaretechnik dürfte das Verhältnis bei größeren Aufgabenstellungen etwa so liegen, dass 10% Standard­lösungen sind, 35% mit gesicherten Verfahren und verfügbaren Spezialisten etablier­bar sind und 55% der Aufgabenstellungen relevante Elemente an Innovation und Experiment bein­halten.

Dabei darf man den Begriff der Innovation in Bezug auf Softwaresysteme nicht nur streng technisch sehen: Auch die kluge Neuordnung von Abläufen in einem Betrieb ist aus der Sicht der Softwaretechnik eine „Erfindung“, die oft „von unten“ durch neue Möglich­keiten der Softwareentwicklung vorangetrieben wird.

Natürlich wurde dieses Problem einer ganzen Disziplin beim Aufsetzen des Projektes TISS beachtet, eine umfassende Prüfung betreffend Make/Buy durchgeführt und letztlich entschieden, dass die aufwändige, schließlich unausweichlich gewordene Migration aller Alt­systeme (heute binden oft kleine Änderungen im Dienstrecht einen erfahrenen Mann für 6 Monate, weil die Änderungen über Programme, Systeme, Scripts und situative Work­arounds verteilt etabliert vorliegen) der beste Hebel ist, um Innovationen zu geringen Grenzkosten zu etablieren: Aufräumen ist die Pflicht, Innovieren die relativ günstige Kür. TISS wird frei­gehalten von Experimenten, beinhaltet jedoch zu mehr als 50% innovative Anteile. Damit ist es ein sehr typisches modernes Softwareprojekt!

Historisch etablierte Abläufe werden hinterfragt und, wo immer es sinnvoll und zweckmäßig ist, neu geordnet und durch elektronische Workflows unterstützt oder abgelöst. Mit der Einführung des Student Self Service ist dies für einen kleinen, aber sehr zentralen Bereich erfolgt. Damit konnte eine erhebliche Serviceverbesserung bei gleichzeitiger Entlastung der Mitarbeiter erzielt werden. Im weiteren Projektverlauf wird TISS in allen Bereichen an der einen oder anderen Stelle innovative Neuerungen technischer und organisatorischer Natur etablieren.

Trotz der „Jugend“ der Disziplin Softwaretechnik gibt es natürlich solide, methodische, industriell dem Problem entsprechende Vorgehensweisen, die im Fall von TISS anzuwenden sind. Abbildung 2 zeigt die pragmatische Landkarte eines Projekts nach heutigem Stand der Technik.

Projektmanagement und Qualitätssicherung fungieren als Querschnittsinstanzen und Bindemechanismen über die fünf Phasen Analyse, Design, Codierung, Test und Wartung. Je nach Anforderung und Systemart können einzelne oder mehrere Phasen bestimmte softwaretechnische Vertiefungen erfordern. Als Qualitätsvertiefungen sind im Fall von TISS die Aspekte Usability und Web-Engineering anzusehen, in spezifischen Be­reichen das Thema Security. Echtzeitfragen treten im Kern des Systems nicht auf, die garantierbaren Reaktionszeiten eines Schließsystems sind zwar Teil der Aufgabenstellung von TISS, aufwändige Echtzeittechnologie erfordert das aber nicht.

Das Projekt­management eines großen Softwareprojektes wie TISS fungiert innerhalb eines übergeordneten Kontex­tes, der besondere Maßnahmen erfordern kann. TISS verfügt über ein relevantes Risiko­management und führt seine Ergebnisse in eine innerbetriebliche IT-Strategie über bzw. holt sich seine Vorgaben von dort ab.

Aufgrund der durchaus hohen Gesamtkomplexität in einigen Bereichen und der vielfältigen Teilsysteme von TISS ist es von enormer Bedeutung, dass diese Projekt-struktur auch von allen Beteiligten mitgelebt wird!  Die in früheren Innovationsversuchen angemessenen, kleineren Strukturen (zumeist ver­einzel­te Teil­systeme ausgeführt von 3 - 5 Personen) waren dem Gesamtproblem einfach nicht entsprechend.

Die Altsysteme der TU Wien befinden sich aus dem Blickwinkel des industriellen Real­zustandes in „guter Gesellschaft“. Mehr als 65% der real im Einsatz befindlichen Software ist aus der Sicht des qualifizierten Ingenieurs heute in einem „erbärmlichen“ Zustand. Das betrifft die Altbestände in Banken, Versicherungen, Verkehrsbetrieben, Öl-Unternehmen, vielen Kranken­häusern etc. Diese Software ist schwer zu ändern. Sie ist technisch schlecht dokumentiert. Die Entwicklungsdokumente – sofern noch vorhanden – sind nicht konsistent oder unvollständig. Die Abhängigkeit der Funktion der Software von den Personen, die die Entwicklung durchgeführt haben, ist groß. Diese 65% sind aus heutiger technischer Sicht verschrobene Bastelei, es sind mehr oder weniger „geniale“ Lösungen mit schicksalsartigem Lebenszyklus. Diesen Real-zustand schrittweise und angemessen zu verändern ist Gegenstand und Tätigkeit des aktuellen industriellen IT-Umfeldes. An der TU Wien ist es unsere gemeinsame große Aufgabe. 40 Jahre TU- und Gesetzes-Geschichte haben die Systeme ausgeprägt, Dokumentation ist kaum mehr vorhanden. Klare Rollen- und Projektstrukturen bei der Umsetzung wie in Abbildung 2 dargestellt, gab es nicht. Statt­dessen sprachen Nutzer oft mit den Entwicklern im Altsystem auf der Basis der „Methode Zuruf“. Der Entwickler implementierte den Wunsch. Kurzfristig in Ordnung, langfristig der schleichende Softwaretod: Über ein Jahr kam es beispielsweise zu 25 bis 30 Änderungswünschen von drei Anwendern an einen Entwickler. Vier weitere Entwickler taten es ähnlich. Außer dem Code gibt es – abgesehen von manchmal rekonstruierbaren E-Mails – keine Aufzeichnungen über den Vorgang. Beim Bau von TISS stehen wir nun häufig vor der Aufgabe zu entscheiden, ob diese undokumentierten Implementierungsarbeiten (bei Annahme von 3 Tagen Durchschnitt pro Task sind das 150 mal 3 Tagesaufwände an Arbeiten) essenziell sind oder nicht. Nach industriellen Maßen bewertet und extern zugekauft würde allein die qualifizierte Rekonstruktion dieser „Zurufsänderungen“ 200.000 bis 400.000 €  kosten...

Inzwischen werden natürlich im Haus Ticketing-Systeme für solche Abläufe verwendet, es bleiben derart zumindest mehr Spuren aus solchen gewachsenen Strukturen übrig. Überdies wird am Ende der TISS-Entwicklung ein Fachkonzept vorliegen, das (hoffentlich) laufend gepflegt wird.

Angemessenheit von Methoden der Softwaretechnik

Welche Methoden sind angemessen für TISS, um die Missstände der Vergangenheit zu beseitigen und die gleichen Fehler nicht erneut zu machen? Lange Jahre (1980 bis Ende des Jahrhunderts) hat sich die wissenschaftliche Gemeinschaft der Informatik damit begnügt, der industriellen Softwaretechnik ein hohes Maß an Methodenlosigkeit zu attestieren. Dies sei die Ursache für den mangelhaften Zustand der Software in der industriellen Praxis. Mittlerweile sind diese Stimmen fast verstummt. Die Wissenschaft beginnt zu verstehen, dass das, was im Kleinen funktioniert, nicht automatisch im Großen tragend ist und dass das, was im Großen notwendig und angemessen ist, im Kleinen oft nicht wirtschaftlich ist. Keine Methode, kein Verfahren ist überall gut und angemessen. Im Laufe der ersten Projekt­monate von TISS etablierten sich Verfahren, die das Projekt auf eine solide Basis gestellt haben und auch langfristig Qualität garantieren. Je nach Projektphase werden Schwerpunkte verlagert und die Methodik leicht angepasst. Das richtige Maß – nicht zuviel, denn das wäre teure Projektbürokratie, nicht zu wenig, denn das wäre langfristig teuer und riskant – wurde für TISS gefunden.

Wie bereits in einem vorigen ZIDline-Artikel berichtet, waren in der ersten, sehr intensiven Phase der Anforderungsanalyse vor allem Workshops und Einzelinterviews mit einer möglichst breiten Zahl von Endnutzern im Fokus. Anschauungsmaterial, wie beispielsweise Mock-ups (Vorführmodelle), waren und sind dabei ein bedeutendes Instrument um das Verständnis zu unterstützen und dienen zudem als Diskussionsgrundlage. Aufgrund der hohen Dezentralität und Autonomie der strukturellen Teile des Hauses war die Einbeziehung der Mitarbeiter und der stark iterative Entscheidungs- und Entwicklungsprozess zur Umsetzung spezifischer Funktionalitäten ein ganz wesentlicher Akt, zuerst im Rahmen der Anforderungsanalyse, später auch zur Validierung der Funktionen als Teil des Testprozesses. Denn nur durch Domänen-Experten (üb- licherweise ein Intensivbenutzer des Software­systems) kann geprüft werden, ob ein Softwaresystem letztendlich reif für das geplante Einsatzszenario ist.

Die ausführliche und vor allem strukturierte Dokumentation von Work­shops, Meetings, Anfragen, Ideen, Wünschen, Ergebnissen und Entscheidungen auf allen Ebenen, aber natürlich auch des Programmcodes und der Datenbank sind maßgeblich für die langfristige Qualitätssicherung. Darüberhinaus spielte die (Re-)Dokumentation des Altdatenbestandes in TISS eine zentrale Rolle, denn nur so war es möglich, wesentliche Teile der Altsysteme und deren Entwicklung über die vergangenen Jahre nachzuvollziehen und so zu Anforderungen zusammenzufassen. In der 20. Ausgabe der ZIDline wurde ausführlich über den eigens dafür entwickelten Prozess berichtet.

Methodisches Vorgehen wird naturgemäß über die Anforderungsanalyse hinaus gelebt. Sei es in Form von agiler Softwareentwicklung, der Definition und Einhaltung von Programmier­richtlinien, eines wohldefinierten Test- und Rolloutprozesses oder auch in Form der laufenden Maßnahmen in Betrieb und Wartung. In allen fünf Phasen, Analyse, Design, Codierung, Test und Wartung wirken das Projektmanagement und die Qualitäts­sicherung als Bindeglieder und garantieren ein zuverlässiges, flexibles, ausbau­fähiges und wartbares Gesamtsystem für die TU Wien. TISS wird ein langlebiges, gut wartbares System.

Projektziele für das Jahr 2010

Das Projekt TISS strebt im Jahr 2010 bedeutende Meilensteine an. Abbildung 3 fasst die wesentlichen Bereiche und Einzelkomponenten von TISS zusammen, die aktuell durch den Zentralen Informatikdienst (ZID), mit Unterstützung der TU-internen Forschungsgruppe für Industrielle Softwaretechnik (INSO), umgesetzt werden. Der erfahrene Leser wird es schon erraten haben: Nicht all diese Systeme werden gleichzeitig und im Jahre 2010 fertiggestellt oder in Betrieb gesetzt werden. Das erlaubt weder die Teamstärke, noch wäre ein derart großer Big Bang weise und gesund. Das TISS-Team hat einen klaren Projektplan, passt sich jedoch den Reaktionen des Organismus TU, seinen Mitarbeitern, seinen Studierenden und externen Partnern an.

Während zu Beginn des Projekts 2008 vornehmlich die Ablöse der Altsysteme als Projektziel und -inhalt im Vordergrund standen, zeigte sich im Laufe der zahlreichen Workshops und Interviews mit Mitarbeitern und Studierenden deutlich, dass es an der TU Wien neben der Etablierung neuer Workflows und deren elektronischen Unterstützung auch sehr viel Potential für erweiterte Servicefunktionen gibt. Jeder der großen Bereiche Forschung, Lehre und Organisation hat hier eigene dynamische Potentiale. Summiert man alle bisher aggregierten Vorgaben durch die Altsysteme, Wünsche von Mitarbeitern und Studierenden sowie konzeptionellen Erweiterungen aus den TISS-Reihen, so hat sich die Zahl der Anforderungen an TISS seit Projektbeginn mehr als verdoppelt!

Nach dem IT-Erfahrungsmuster „Mit dem Essen kommt der Appetit“ ist davon auszugehen, dass in den kommenden 1 - 2 Jahren weitere Ideen und Wünsche an das TISS-Team herangetragen werden und im Sinne eines Gesamtkonzepts auch Berück­sichtigung finden.

Für das Jahr 2010 sind folgende Ziele am Projekt- Radar:

Lehre: Die Anforderungen an ein System zur Verwaltung und Abwicklung von Lehr­veranstaltungen wurden bisher von TUWIS++ und TUWEL weitgehend recht gut abgedeckt. Dennoch gibt es auch in diesem Bereich Verbesserungspotential. Insbesondere die Termin- und Hörsaalverwaltung bedarf einer Neukonzeption, die auch organisatorischen Problemen und den scheinbar mangelnden Raumressourcen zu Leibe rücken wird. Natürlich lassen sich nicht alle Missstände durch Software lösen, aber es sollten zumindest spürbare Verbes­serungen durch flexible und intelligente Mechanismen erzielt werden. Weiters wird es im Prüfungsmanagement, dem Handling von Dokumenten oder dem Monitoring durch Studiendekane neue System-Angebote geben. Anhand von Pilotsystemen wird TISS im Laufe des kommenden Jahres mehrere Testphasen unter Einbeziehung von Key-Usern durchlaufen, um so die Ablöse von TUWIS++ und die Anbindung von TUWEL an TISS schrittweise voranzu­treiben.

Forschung:  Im Mittelpunkt des Bereichs Forschung steht die Konzeption eines modernen, gut benutzbaren Forschungsinformationssystems der TU Wien, mit dem sämtliche Informationen zu Forschungs­aktivitäten und -ergebnissen verwaltet und genutzt werden können. Das neue System wird Stütze und nicht Last sein. Das ist ein „heiliges Versprechen“ des Teams. Dieses Informationssystem wird Projektverwaltung, Berichtswesen und Publikationen bereitstellen, aber auch als Analysewerkzeug der akademischen Leistungen des Hauses TU dienen. Es soll als ganzheitliches System die Mitarbeiter unterstützen und in der Darstellung nach außen die TU Wien als Forschungsinstitution repräsentieren. 2010 werden schon erste Teile davon als prototypische Umsetzungen sichtbar und die Akzeptanz von Seiten der Benutzer geprüft werden.

Organisation: Im Bereich Organisation wird sich TISS im Jahr 2010 im Zuge der TUphone-Anbindung als flexibler Systemintegrator beweisen können. Fachliche Funktionen und Prozesse werden von TISS für verschiedene Fachabteilungen entstehen, wie beispielsweise in Form von Dokumentenmanagementsystemen. Aber auch übergreifende Funktionen, wie ein News- und Kommunikationssystem, einfache Workflows und Elektronische Akte (ELAKs) für alle Mitarbeiter der TU Wien, werden Schritt für Schritt in Angriff genommen.

Über einen erweiterten Online-Informationsbereich, eingebettet in die TISS Applikationsumgebung, werden wir im kommenden Jahr alle interessierten Leser über den Projekt­fortschritt auf dem Laufenden halten und gemeinsam mit der ZIDline weiter­hin von Meilensteinen und Projektergebnissen berichten. In einer kommenden Ausgabe der ZIDline wird das Thema „TISS Epistemologie II“ vertieft aufgegriffen.

Literatur

Grechenig et al., 2009, Softwaretechnik: Mit Fallbeispielen aus realen Entwicklungsprojekten, Pearson Studium, München, Deutschland.