Donnerstag, April 05, 2007

Von Beruf Software Engineer

Na, was glauben Sie, wie Ihr Beruf als Software Engineer in 10, 20 Jahren aussehen wird? Zu Beginn des Wintersemesters 2006 habe ich meine Studierenden im Hauptstudium befragt, wie sie die Zukunft des Software Engineering in 10 Jahren sehen. Folgende Liste kam dabei heraus:

  • mehr Konzeption von Software: Anforderungen, Modellierung

  • Software aus Komponenten “zusammenstecken”, Code-Generierung

  • mehr Planung und Organisation von Software-Projekten

  • viel Planung und Kommunikation mit Kunden

  • Hohe Qualitätssicherung bei Outsourcing der Programmierung

  • Teamarbeit: internationale, verteilte Arbeit und Kommunikation

  • Pflege, Weiterentwicklung, Optimierung von Altsystemen

  • sicherer Arbeitsplatz: es entsteht immer mehr Software => Wartung

  • neue Technologien, da HW immer leistungsfähiger wird

  • Entwicklung mit leistungsfähigen CASE-Werkzeugen und IDEs

  • Fortschritte in HMI, Webtechnologie, KI, Virtual Reality, …

  • Notwendigkeit ständiger Weiterbildung

  • es wird eine neue Programmiersprache geben => weniger Fehler

  • Agile Softwareentwicklung als Standard


Eine interessante Liste, nicht wahr? Andere interessante Gedanken hat sich Hans Beck in Telepolis gemacht. Er geht davon aus, dass Software-Entwickler es lernen müssen, sich in abstrakten (Denk-)Welten zu bewegen ("Von der Notwendigkeit, sich in abstrakten Welten bewegen zu können", 28. März 2007). Ein, wie ich glaube, lesenswerter Artikel.


--
P.S.: Da nicht jeder mit den Abkürzungen oben vertraut ist: HW (Hardware), CASE (Computer Aided Software Engineering), IDE (Integrated Development Environment), HMI (Human Machine Interface), KI (Künstliche Intelligenz)

Kommentare:

moscht hat gesagt…

Software aus Komponenten “zusammenstecken”, Code-Generierung
wünschenswert, bedeutet mehr Aufwand, schwer durchzusetzen (mehr Aufwand -> höhere Kosten die auf Kunden abgewälzt werden müssen)

mehr Planung und Organisation von Software-Projekten
Mehr Planung? Mehr Organisation? Es wird doch meist so viel wie nötig und so wenig wie möglich geplant. Das kostet Zeit und Geld und das Geld wird erst mit einem Wartungsvertrag verdient. Davor, also während der Umsetzung zahlen zumindest mittelständische Unternehmen drauf. Noch während der Durchführung eines SW-Projekts wird meiner bisherigen Erfahrung nach einiges "nachträglich" geplant und organisiert, was auch gut ist (dass das auch funktioniert). Von vornherein alles Mögliche zu beachten ist meiner Meinung nach unrealistisch.

Hohe Qualitätssicherung bei Outsourcing der Programmierung
Dies würde bedeuten, dass fachliche Projektleitung und technische Projektleitung geographisch getrennt sein könnten. Solange externe Mitarbeiter oder Freiberufler beschäftigt werden, mag dies funktionieren. Das bekannte Indien-Beispiel mag zwar auf den ersten Blick gut und günstig sein, face-to-face-Kommunikation sowohl während der Planungs- als auch während der Umsetzungsphase ist, so denke ich, unersetzbar und sehr wichtig. Und ob die Qualität durch Outsourcing "gesichert" wird hängt auch von deren Niveau ab ;-)

Teamarbeit: internationale, verteilte Arbeit und Kommunikation
lohnt meiner Meinung nach nur bei großen Projekten (mehr als 1 Jahr Entwicklung bei mindestens 10 Entwicklern bzw. mehr als 1 Mio. Zeilen Code effektiv). Brauchbare Kommunikationskanäle vorausgesetzt.

Pflege, Weiterentwicklung, Optimierung von Altsystemen
Dies wird wohl in der Tat einen großen Anteil des Software-Engineerings der Zukunft ausmachen. Eine neues System ist teurer als ein wartbares Altsystem. Und solange das Altsystem funktioniert, braucht man kein Neues. Also: Altsystem warten und pflegen. Hier und da funktional erweitern mit Technologien, die vor 15 Jahren modern waren. Das bringt natürlich auch viel Arbeit, macht aber weniger Spaß: wer arbeitet sich schon gerne in 15 Jahre alten Code ein? ;-)


Eine gute "Architektur" eines Software-Systems ist selbstverständlich wünschenswert, erfordert aber viel Zeit, wenn diese sauber definiert werden soll. Deren Umsetzung wird schwer, wenn sie schlecht definiert wurde und zu wenig Zeit und Mühe hierfür investiert wurde. Vieles, was mir während des Software-Engineering-Studiums erzählt wurde, würde ich nun sehr gerne umsetzen, aber den Kunden interessiert die Architektur nur am Rande. Es interessiert nur eine möglichst schnelle Umsetzung des Projekts, möglichst billig, möglichst ohne Verzögerungen. Die Vorteile einer guten Architektur sind manchen Kunden nur schwer zu vermitteln, besonders wenn diese kaum oder gar nichts mit Softwareentwicklung am Hut haben. Für sie ist einfach kein Platz und kein Geld für das, was man z. B. in "Modellierung von Software-Architektur" bei Ihnen, Herr Herzberg, gerne gelernt hat. Dann schätzt man Kunden, die ihrerseits die langfristigen Vorteile "guter" Software erkennen.

Man müsste im Lotto gewinnen und dann richtig gute Software planen. Ohne Sorgen und ohne Kompromisse. ;-)

Das Geschriebene bildete sich aus meinen bisherigen Erfahrungen, die nicht besonders weitreichend sind, aber -- so denke ich -- doch ausreichend, um zumindest ansatzweise ein Meinung bilden zu können ;)

Viele Grüße,
moscht

tbender hat gesagt…

Die Vorteile einer guten Architektur sind manchen Kunden nur schwer zu vermitteln, besonders wenn diese kaum oder gar nichts mit Softwareentwicklung am Hut haben. Für sie ist einfach kein Platz und kein Geld für das, was man z. B. in "Modellierung von Software-Architektur" bei Ihnen, Herr Herzberg, gerne gelernt hat. Dann schätzt man Kunden, die ihrerseits die langfristigen Vorteile "guter" Software erkennen.

Ganz genau! Das ist ja das Problem. So wie ich das verstehe ist eine SWA eine interne Maßnahme zur strukturierung der
Software. Diese Maßnahme kann zweifelsohne einiges an Zusatzaufwand kosten, den ich dem Kunden dann gut verkaufen muss.

Im Endeffekt profitieren aber beide (Ich & Kunde) davon. Nur er weiß es eben nicht ;-)