downforze schrieb:
Entwicklung umfasst die ganzen Schritte der Planung wie Anwendungsfallbeschreibung, Anwendungsfalldiagramm, Sequenzdiagramm
Ja, wenn man schön formal nach UML mit allen seinen barocken Strukturen vorgeht ist das vielleicht so. Heute arbeiten die meisten Projekte mit agilen Methoden, da gibt es keine formale Trennung zwischen Entwurfs- und Implementierungsphasen mehr.
Nicht umsonst schreibt das Agile Manifesto
https://agilemanifesto.org/
"Individuals and interactions over processes and tools
Working software over comprehensive documentation"
Agile ist nun natürlich auch nicht der heilige Gral und hat zu neuen Problemen geführt, und gerade beim Thema "Processes and Tools" haben Methoden wie Scrum ihre eigenen barocken Strukturen übernommen.
Aber sie haben die Denkweise beim Entwickeln von Software schon deutlich geändert.
Eine schöne Anekdote von 2012, als ich eine leicht in der Krise steckenden Entwicklungsabteilung übernommen habe: Damals gab es ein Projekt, da hatte die Abteilung Monate an einer Spezifikation gearbeitet und hatte dabei schon weit über 50% des Gesamtbudgets für das Projekt gebraucht und noch nicht eine Zeile Code geschrieben. Als ich die Entwickler fragte, wo sie denn gefühlt im Projekt stehen, sagten sie "ja wir sind zu 50% fertig, denn wir haben 50% des Budgets verbraucht und sind planmäßig mit der Spezifikation fertig".
In Wirklichkeit war die Spezifikation unbrauchbar, da die Entwickler leider einen erheblichen Teil der fachlichen Anforderungen nicht verstanden hatten. Der reale Projektfortschritt lag so in der Nähe von 0%.
Mittlerweile ist es bei uns so, dass wir nur "Working Software" als Maß für den Projektfortschritt nehmen. Das Ziel ist in jedem Sprint eine "funktionsfähiges" Stück Software abzuliefern. Am Anfang hat die Software dann natürlich nur wenige Features, aber das Featuresset ist in sich funktionsfähig. Non-Software Artefakte (wie z.B. User Stories ) stellen für sich keinen Wert dar.
downforze schrieb:
In meinem Studium wurde auch explizit zwischen Software engineering und Programmierung unterschieden.
Das ist auch absolut ok, genauso wie alle anderen Disziplinen/Phasen innerhalb der Softwareentwicklung, wie etwas UX/UI Design, Deployment, Testing, usw. ). Nur gibt es niemanden der, genau wie Du in Deinem Studium, nicht alle diese Disziplinen lernt und in der Regel auch grundlegend beherrscht. In einem Team kann man sich spezialisieren, und je größer das Team, um so mehr Spezialisierung.
Aber ich kenne keinen Programmierer der nur Code schreiben kann und nicht auch die anderen Disziplinen beherrscht. Genauso kann ein Architekt seine Aufgabe nicht sinnvoll ausführen, wenn er nichts von Coding versteht.
Der Auslöser für mein Post war, das jemand "Entwickler" und "Programmierer" als formal unterschiedliche Begriffe sehen wollte. Und das halte ich für Quatsch. Beide Begriffe sind unscharf definierte Alltagsbegriffe. Früher (bis ca. in die 80er) war Programmierer weiter verbreitet, heute sagt man mehr Entwickler. 1986, als ich an der Uni anfing, hießen die Anfänger Vorlesungen noch "Programmierung 1" und "2". Bei meiner Tochter, die 2018 angefangen hat, hießen sie "Softwareentwicklung 1" und "2". Damals war es Pascal, heute Java, aber inhaltlich hat sich nicht so viel geändert.
