Technologische Besonderheiten in langlebigen...
Transcript of Technologische Besonderheiten in langlebigen...
Technologische Besonderheiten in langlebigen Softwareprojekten
Fakultät Informatik, Ringvorlesung im Studium generale„Softwareentwicklung in der industriellen Praxis“Dresden, 2.6.2008, Dr. Jörg Hutschenreiter
Summary:Software, die im Kerngeschäft eines Unternehmens unmittelbar zum Einsatz kommt, ist niemals "fertig". Sie muss und soll so, wie sich das Unternehmen selbst am Markt und in seinen Geschäftsprozessen weiterentwickelt, dieser Entwicklung folgen bzw. diese sogar mit befördern. Im Dresdner Kompetenzzentrum Logistik der CSC Deutschland Solutions GmbH werden seit 15 Jahren erfolgreich Software-Projekte im Bereich der schienengebundenen Transportlogistik realisiert, betreut und weiterentwickelt. Dies umfasst den gesamten Software-Lebenszyklus von den Projekt-Ideen bis hin zur 7x24h-Betreuung der Produktivsysteme. Dabei verändern sich auch die für den Hersteller der Software wesentlichen Randbedingungen (Hardware, Betriebssysteme, Programiersprachen, Werkzeuge, Infrastrukturen), so dass die Frage entsteht, was denn dann die Fixpunkte einer Software-Architektur sein können, um über geradezu historische Zeiträume ein Software-Projekt am Leben zu halten, ohne dies mit teuren Redesign-Prozessen oder fortlaufend instabiler Software bezahlen zu müssen.Dabei sind ständig auch nicht einfache Entscheidungen für oder gegen eine Technologie, für oder gegen den Einsatz eines Werkzeuges zu treffen. Auch das "Wie" einer Integration einer neuen Technologie-Komponente ist genau abzuwägen. Dabei gibt es, wie zu vermuten, kein Universalrezept, wohl aber durchaus objektivierbare Kriterien. Im Vortrag werden solche Kriterien vorgeschlagen und mit den praktischen Erfahrungen des Autors motiviert.
Technologische Besonderheiten in langlebigen Softwareprojekten
● Vorstellung, Charakterisierung der Projekte
● Die Herausforderung - das Problem des (über-)lebensfähigen Designs
● Die Randbedingungen
● Chancen zur Nachhaltigkeit von Design und Tool-Einsatz
● Momentaufnahmen aus der eigenen Praxis
● Resümee
Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
● 1975-1980 Mathematikstudium TU Dresden (WB MKR)
● 1980-1993 Wiss. Assistent,
– Forschungsgruppe „Programmierungssprachen und höhere Programmierungstechnik“,
– Fachsprachensystem DEPOT,
– Promotion bei N.J.Lehmann („Zur Pragmatik von Fachsprachen“),
● seit 1994 bei CSC Deutschland, heute in der Rolle „Solution Architect“,
● Dr. Jörg Hutschenreiter, CSC Deutschland Solutions GmbH, Bergstraße 2, 01069 Dresden, [email protected]
Vita
Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
CSC in Deutschland(http://de.country.csc.com/de)
Die Branche Transportation ... (http://de.country.csc.com/de -> Branchen -> Transportation – Link „Transportation Management CP BIS)
... das Kompetenzzentrum Logistik der CSC Deutschland Solutions GmbH in Dresden
● 1991 gegründet mit wenigen Mitarbeitern der damaligen Hochschule für Verkehrswesen
● heute ca. 30 Mitarbeiter (Consulting und Software-Entwicklung)
● spezialisiert auf Leitstellensoftware für den schienengebundenen Verkehr (private Eisenbahnen, Werksverkehr, mehr und mehr auch Eisenbahnverkehr einschl. SPNV, einige Projekte im ÖPNV)
● Bergstraße 2, 01069 Dresden, Tel. 0351.477710
● Mit einem durchgängigen Leistungsportfolio:
Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
Plan Run
Geschäfts- vision
und-strategie
Geschäfts-prozesse
IT- Strategie
und-Architektur
Anwen-dungs-
planung
System-entwick-
lung
System-manage-
ment
Build
Referenzkunden für Leitsysteme
VOEST ALPINE Chemiepark Linz
Ludwigshafen Antwerpen Schwarzheide
Ingolstadt Neckarsulm Győr
Wolfsburg Mosel Bratislava Braunschweig Hannover Emden Kassel Salzgitter
Dresden Augsburg
Osnabrück
Schwedt
Peine Salzgitter Ilsenburg
Dortmund Bochum Dillenburg Benrath
Dortmunder Eisenbahn
Neuss-Düsseldorfer Häfen
Neuss
Gütersloh Eisenhüttenstadt
Marl Bern
Linz
Ballungsraum Oberes Elbtal
Dresden
Bremen
Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
Einordnung der Software-Projekte● je nach Projektphase 2 – 8 Mitarbeiter
● ca. 0,5 – 5 Mio LoC, Datenbankenvolumen 1-20 GB, 5-30 Arbeitsplätze,
● große Zahl von Fachmoduln mit kundenspezifischen Anpassungen
● mit vielen Schnittstellen zu Umsystemen (in Summe >150)
● ausgefeilte graphische Nutzeroberflächen
● langjährige Zusammenarbeit mit dem Kunden
● in unterschiedlichen Hard- und Software-Umgebungen lauffähig
● Plan-Build-Run bis 7x24h-Rufbereitschaft ist abzudecken
● Individual-Entwicklung mit ganz spezifischen Anforderungen
● Es handelt sich um Fachapplikationsentwicklung (in gewisser Abgrenzung von der Entwicklung z.B. von System-, Unterhaltungs- oder Standard-Software)
Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
Kennzeichen für Fachapplikationsentwicklung
● Der Fokus liegt auf der Lösung fachlicher Probleme und Aufgaben einer bestimmten Branche.
● Es ist ein tiefes Verständnis der Geschäftsprozesse des Kunden, der Verwaltung seiner Daten, erforderlich.
● Software ist in zentrale Geschäftsprozesse des Kunden einzubinden. Es ist Individualsoftware aufgrund der Individualität der Geschäftsprozesse des Kunden.
● Es gibt weder einfache noch abgeschlossene vollständige Modelle.
● Es gibt eine große Zahl von Schnittstellen zu Umsystemen.
● Software ist in eine gewachsene IT-Landschaft zu integrieren.
● Software unterliegt ständiger Weiterentwicklung, Design muss zukunftssicher sein.
● Solche Software ist relativ teuer, muss aber auch im Wettbewerb bestehen.
Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
Fachliche Vielfalt 1 - RBL DVB – Funktionsmodule Leitstellensoftware
Fahrplanung und GIS
Funk und Fahrzeuge
Betriebshofdisposition
Taxi-Leitsystem
zu anderen Leitsystemen nach VDV-Standard 453 und 454
Dynamische Haltestellenanzeiger
Anzeige von Fahrten anderer VU und mehrere Haltestellenbereiche
Datenbereitstellung nach VDV 454 für SMS-Verbindungsauskunft
Datenverwaltung Fahrzeugüberwachung Schnittstellen
24-Stunden-Hotline inkl. Monitoring/Anwenderberatung
DV-Betriebsführung (Server, DBMS, Datenmodell)
Wartung/Pflege/Anpassungen
Ereignisbearbeitung Daten-/Sprechfunk Routeneditor Maßnahmenkatalog Umleiten / L/K-Mutationen
Stammdatenverwaltung
Fahrplandaten
Fahrzeugdaten
Betriebsdaten
Standortverfolgung Fahrplan Soll-/Ist-Vergleich Netzdarstellung / Bildfahrplan Linienband / Fahrzeugtabelle Verfrühungsüberwachung
Fahrplanübersichten
Betriebstagebuch
Statistikanwendung zur Auswer- tung verkehrlicher Kenngrößen
RBL-Leitstelle
Disposition / Störungsbearb.Übersichten und Statistiken
Anschlussmanagement Steuerung Fahrgastinformation Service-Organisation
interne Anschlusssicherung VU-übergreifende
Anschlusssicherung Kommunikationsschnittstelle
nach VDV 453
Fachliche Vielfalt 2 - Module für Leitsysteme in der schienen-gebundenen Logistik
Stammdaten-verwaltung
Schnittstellen-management
AuswertungenStatistik
Auftrags-management
Kondi-tionen-
verwaltung
Kunden-daten-
verwaltung
Rahmen-verträge
TPABahn-
Logistik
TPAEVU Offerten
Ressourcen-planung
undÜber-
wachung
Trassen-mana-
gement
Leistungsauf-träge Werks-rangierdienste
Rangier-fahrten
Ladestellen-bedienung
Eingangs-/Ausgangs-
Zugbehandlung
Leistungsauf-trägeEVU-Verkehre
Zugbildung/-auflösung
Zug-fahrten
Neben-leistungen
AbrechnungLeistungs-aufträgebewerten
Verkaufs-leistungenabrechnen
Einkaufs-leistungenabrechnen
Vorkontierungdurchführen
Rechnungerstellen
Die Herausforderung für den Software-Architekten
● Alle wichtigen Designentscheidungen müssen nachhaltig sein, d.h. so, dass eine kontinuierliche Weiterentwicklung der Software ohne teure Redesign-Phasen jederzeit gewährleistet werden kann.
● Die eingesetzten software-technischen Mittel müssen „einfach“ handhabbar, robust und ausfallsicher sein, software-technische Finessen sind grundsätzlich sekundär.
● Das Design muss aber trotzdem offen sein für künftige Weiterentwicklungen.
Der Faktor Zeit birgt latent die Gefahr der „technologischen Sackgasse“.
Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
Randbedingungen dieser ProjekteMitte der 90-er Jahre
● Ein typischer PC: Windows 3.11, Pentium 200 MHz, Grafik 800x600, 80MB Festplatte
● kommerzielle Unixe (HP UX, AIX, Digital Unix, ...) als teure Server-BS
● Linux war etwas für Insider, SCO Unix verfügbar
● Schon 64-Bit-Unix-Workstation (DEC 3000)
● Kaum Alternativen zu C/C++, aber C++-Compiler z.T. noch mit schwerwiegenden Bugs (Mehrfachvererbung, Templates)
● Java wird erst geboren
● Kaum entwickelte Frameworks: X11, OSF-Motif, ESQL; für Unix keine preiswerte IDE
Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
Randbedingungen dieser Projekteab 2000
● von der Leistungsfähigkeit her gesehen stehen die ehemaligen Server nun als PC unter dem Schreibtisch
● Linux beginnt, praxisreif zu werden
● Unix-Workstations werden zu teuer, im PC-Bereich dominiert Intel-Architektur,
● Java etabliert sich
● C++ stagniert
● Windows wird ein Betriebssystem, auch auf dem Server
● komplexe Frameworks und Werkzeuge entstehen, vor allem im Java-und C#-Umfeld
Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
Entwicklungsumgebung, der Arbeitsplatz des Entwicklers – eigenes Erleben
● Anforderung: Entwicklung für verschiedene Plattformen muss möglich sein, optimal aber Plattformunabhängigkeit der IDE selbst (z.B. für Debugging)
● SNiFF+ (1995 (Fa. TakeFive) - ca. 2001, heute leider tot), kommerzielle, werkzeug-offene IDE mit klar modellierten Grundbegriffen des Entwickler-Alltags:
– Projekt (einschl. Projekt-Hierarchien),
– Plattform,
– Workspace, Working Environment,
– File Type;
– Komfortable Quellcode-Verwaltung auf Basis RCS
● Eclipse (Java: top, C/C++: flop), Subversion
● Alternativen, Entwicklungen?Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
Die rasante Entwicklung der Technik befördert einen enormen Ausstoß an neuen Ideen, Ansätzen, Technologien für die schon lang bekannten Probleme der Software-Technologie.
Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
OODMDA
Web-Services
SOA
CASE
XP
SA
UML
DSM
J2EE
SaaS
ASP
AOP
SOAPCorba
OOPOO DB
komplex schnelllebig
durch verschiedenste Interessen vorangetrieben
Das Universum der Software-Technologie
DSM
So viele Lösungen, wo ist denn da noch das Problem?
Persönlicher Eindruck
● Es sind oft Tendenzen der Vereinnahmung des gesamten Software-Entwicklungsprozess zu beobachten, verbunden mit der mangelnden Integrationsfähigkeit der Werkzeuge und Laufzeitumgebungen.
● Die unterschiedlichen kommerzielle Interessen der Werkzeughersteller und der Werkzeuganwender bieten ein dauerhaftes Spannungsfeld. Manch vielversprechendes Produkt/manche Ansätze und Ideen bleiben aus kommerziellen Gründen auf der Strecke.
● Plumpe PR (Versprechen wie „Softwareentwicklung ohne Kenntnis einer Programmiersprache“) verbirgt manchmal den wahren Kern und potienziellen Nutzen.
● Die Überstrapazierung diverser Ansätze birgt die Gefahr, in technologische Sackgassen zu geraten.
● Der Regenschirm wird ziemlich oft wiedererfunden und dabei nicht unbedingt immer besser - manchmal aber doch.
Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
Eine gesunde Skepsis ist manchmal angebracht.
Sei misstrauisch,
● wenn Dir die eierlegende Wollmilchsau versprochen wird;
● wenn Dir versprochen wird, Du musst nicht programmieren können;
● wenn Dir versprochen wird, dass Du mit dem Tool keine Fehler mehr machen kannst;
● wenn früher ganz einfache Dinge auf einmal furchtbar kompliziert werden.
Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
Zwischenresümee
● Die Entwicklung des IT-Umfeldes ist so rasant, dass die Hoffnung auf eine immer nur kontinuierliche Entwicklung ohne größere Brüche illusionär bleibt.
● Eine Orientierung in der kaum überschaubaren Vielfalt der Entwicklung bietet im Grunde genommen nur das eigene Grundlagenwissen, die Frage nach dem „Ding an sich“.
● Aber: IT ist keine Zauberkunst, es wird immer nur mit Wasser gekocht. Alles Geniale ist einfach!
Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
Was hat sich als „einigermaßen“ nachhaltige Grundlage erwiesen?
● die etablierten, auf allen Plattformen verfügbaren, universellen Programmiersprachen (C/C++, Java) einschließlich verfügbarer APIs
● relationale Datenbank-Management-Systeme (die einzigen dauerhaft beherrschbaren Persistenz-Backends)
● wenige ziemlich abstrakte Design-Prinzipien
– objektbasierte/-orientierte Modellierung und Programmierung
– modulare Programmierung (zu unrecht fast in Vergessenheit geraten oder mit Verweis auf Klassen abgetan)
● das Wissen des Software-Ingenieurs, die Grundlagen seines Fachgebiets
Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
Bemerkung zur Objektorientierung● persönliche Einschätzung: heute eines der am meist
missverstandenen Paradigmen
● OO-Sprachmittel werden oft auf Hilfsmittel zur Realisierung Software-technischer Lösungen reduziert, vergessen wird der Grundgedanke, dass es sich bei OO um eine Denkweise handelt, um das Abbilden eines Abstraktionsprozesses im Rechner. Die Bildung der richtigen Abstraktionen ist die Chance, spätere Widersprüche im Design zu vermeiden.
● Beispiel: Eclipse – eine „Fachapplikation“ für das Anwendungsgebiet Software-Entwicklung:
– Alles ist ein Plugin. Programm-technisch hochentwickeltes Framework, saubere und zweckmäßige Anwendung diverser Pattern. Plugin-APIs und RCP-Framework zu empfehlen für das Studium der Anwendung von OO-Techniken.
– ABER: keine adäquat entwickelten, programmiersprach-übergreifenden Modellbildungen für die Realität, der in der IDE abgebildet wird („Projekt“, „Workspace“, „Plattform“).
– Folge: Probleme bei mehrsprachlichen Projekten.Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
Bemerkung zu modularer Programmierung – veraltet oder alte Weisheit?
● Vorweggenommen: Die Ideen der modularen Programmierung stellen wie vor ein modernes, universelles Strukturierungsprinzip für Software da.
● Java und C++ bieten die Möglichkeiten, modular zu programmieren, ohne aber unmittelbare Sprachmittel zur Verfügung zu stellen. Klassen sind keine Moduln.
● Modularisierung und Objektorientierung beinhalten teilweise gegensätzliche Tendenzen! (Kapselung versus Vererbung)
● Das Prinzip der Modularisierung ist verallgemeinerbar auf verschiedene Ebenen anwendbar
– starke Kopplung auf der Ebene des Kodes in einer Programmiersprache, in der Praxis oft zu eng
– schwächere Formen der Kopplung (Services)
● „Die Zerlegung eines Problems ist die Lösung des Problems.“
Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
Design-Prinzipien 1
● Fachlich orientierte OO-Modellierung.
● Hoher Eigenanteil an POJOs/POCOs.
● Einfachstmögliche Schnittstellen zur Lösung technischer Probleme nutzen; Klarheit und Robustheit haben das Primat.
● Sollbruchstellen schaffen für preiswerten Ersatz und/oder ggf. notwendigen Eingriffe zur Behebung technischer Probleme (Performance, Bugs, Releasewechsel), die (Murphy!) immer und überall auftreten können.
Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
Design-Prinzipien 2
● KISS-Prinzip („keep it small and simple“)
● Strukturen schaffen auf jeder Ebene („Teile und herrsche“), Auswirkungen von Kode-Änderungen begrenzen („Lokalitätseigenschaft“ für Quelltexte)
● Integration von Fremdsoftware immer über eine Schnittstelle
● Fehler werden passieren, daher
– testfähigen Kode schreiben
– so zeitig wie möglich im Entwicklungsprozess testen
– Teststrategie planen, insbesondere auch Komplextests
– die Entwicklungsetappen so planen, das immer mehr lauffähige, aufeinander aufbauende Moduln entstehen.
● Prinzip des defensiven Programmierens, Vermeiden von „sophisticated techniques“ .
Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
Kriterien für den Einsatz einer (toolbasierten) Technologie
● Besteht sie eine Aufwand-Nutzen-Analyse (Beschaffungs- und laufende Kosten, z.B. auch für Qualifikation) versus absehbare Rationalisierungseffekte
● Muss ich mich mit dem Tool verheiraten? Was passiert, wenn das Tool ausfällt?
● Ist sie allgemein im Team verwendbar oder brauche ich einen Guru?
● Wie passt sie in die vorhandene Landschaft – besteht Integrationsfähigkeit?
Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
Anforderungen an brauchbare Tools
● Der interessierende technologische Ansatz muss in einem Tool auch handwerklich praktikabel umgesetzt sein.
● Das Tool muss eine konkretes Problem lösen, dies sichert seinen dauerhaften Einsatz. Es darf darüber hinaus auch noch mehr bieten.
● Es muss die Sicherheit bestehen, dass auftretende Probleme mit dem Tool (trotz vielleicht auftretender Bugs und funktionaler Einschränkungen) auch gelöst werden können.
Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
Praxis 1 – zurück zu 19941994: Client-Server-
Architektur, Unix, X11, OSF/Motif,
Entwicklung vollständig in C, C++-Kenntnisse noch nicht so weit verbreitet
in X11 elementar aus-programmierte Grafik,
ausreichende Usability nur mit einigen Tricks erreicht
Datenbankzugriff über natives Protokoll, ESQL
Basis für weitere Projekte
Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
Praxis 2 – Auswertung der ersten Erfahrungen
Ab 1997 neues Projekt mit erheblich größeren Anforderungen an die GUI-Performance
Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
Einsatz von C++ und einer kommerziellen Grafik-Bibliothek (Ilog Views)
ausgefeilte oo-Präsen-tationslogik
Einführung abstrakter Schnittstellen zu Daten-bank und GUI
Komponenten-basiertes Systemdesign
einheitlicher Kommunikations-mechanismus zwischen den Funtkionsmoduln
Praxis 3 – neue Anforderungengleichzeitiges Projekt mit der Anforderung, zum „Rich Client“ noch ein
Browser-GUI zu liefern – neues Problem: Wohin mit der Fach-Logik?
Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
Einsatz von WebObjects (Apple),
Entscheidung, Stored Procedures zu verwenden (PL/SQL)
kommerziell erfolgreiches Projekt
software-technologisch strategisch proble-matisches Design (DBMS-Abhängigkeit, Programmieren unmittelbar auf relationalen Daten)
Praxis 4 – ein neues globales Design● im Jahr 2001: Ansatz für eine Drei-Schichten-Architektur mit einer in
Java geschriebenen Logikebene, zwei Aufgaben:
– Framework für Logikebene finden,
– Kommunikation Rich Client – Logikebene klären.
● bewusste Entscheidung gegen J2EE, aber Notwendigkeit einer Standard-Laufzeit-Umgebung (Application-Server)
● Ergebnis: Mittelschicht als WebService mit genau einer Funktion: byte[] call(byte[]),
– SOAP als Träger eines eigenen Request-Response-Protokolls auf der Basis einer selbst entwickelten Serialisierung einfacher Datencontainer,
– eigenes DB-Zugriffs-Framework für Mittelschicht (auf der Basis JDBC, weitestgehend DBMS-unabhängig),
– die 3,5-te Schicht kann nunmehr konfliktfrei bei Bedarf ergänzt werden.
● Applikation als Standard-WebService unter beliebigen WAS deployfähig Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
Praxis 5 - ToDoaktuelle Aufgaben
● Weiterentwicklung der Mittelschicht in Hinblick auf projektspezifische Anforderungen
● Verbesserung der Performance bei Datenbank-lastigen Teilaufgaben (große Datenmengen)
● Erhöhung der Flexibilität bei CPU-lastigen Teilaufgaben durch Einführung entsprechender Pattern
● Gefahr eines prinzipiell notwendigen Architektur-Bruchs nicht in Sicht, in vielen Projekten bereits bewährt
Daueraufgabe
● Pflege dieser Architektur
Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
Praxis 6 – offene FragenTechnisch:
● Wann erreichen die Java-Laufzeitumgebungen (JVM + Application-Server) die gleiche Robustheit die die der C/C++-Software (das Betriebssystem)?
● Wann wird Java reif für den Client? Wie sieht ein technisch befriedigendes Web-GUI-Toolkit aus?
ungelöste technologische Aufgaben
● Suche nach Tools, die die Kluft zum Fachdienst schließen und die in der Anforderungsanalyse und/oder Pflichtenheft-Erarbeitung entstehenden Ergebnisse unmittelbar in den Software-Entwicklungsprozess integrieren können.
● Alle Versuche sind bisher gescheitert wegen der ungenügenden Rückkoppelfähigkeit bei in späteren Projektphasen entstehenden Änderungen.
● Persönliche Hoffnung: Domain Specific Modelling
Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008
Resümee auf den Weg● Software-Entwicklung in der Praxis ist ein vielschichtiger,
von den verschiedensten äußeren Einflüssen getriebener, alles andere als glatt verlaufender Prozess - das ahnst Du vielleicht schon.
● Software-Entwicklung ist trotzdem eine spannende Sache.
● Software-Entwicklung ist keine Zauberkunst.
● Stell alles in Frage, solange Du es nicht verstanden hast. Wenn etwas unklar erscheint, muss es nicht an Dir liegen. Glauben ersetzt kein Wissen.
● Erfahrung heißt, genügend Fehler selbst gemacht und verstanden zu haben, nimm Dir die Zeit!
● Nutze alle Chancen, Neues und Dich auszuprobieren.
Viel Erfolg!Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008