---

Geschrieben von jama am 16.09.2006 um 16:07:

  Softwaretechnik

Vielleicht stellen wir hier schon einmal ein paar der Themenbereiche vor?

Softwaretechnik ist z.B. sehr interessant und von den Prinzipien her wichtig für viele (alle?) Programmiersprachen. Peter hat es mir damals gut erklärt. Machst Du das hier noch einmal? Könnte das gar nicht mehr so detailgetreu wiedergeben

Liebe Grüße,

Jama

---

Geschrieben von Mazze am 18.09.2006 um 09:42:

 

Softwaretechnik abstrahiert eigentlich von den Programmiersprachen. Es ist nicht wichtig welche man benutzt, sondern man lernt die Planung und den Entwurf größerer Systeme. Man lernt eine sogenannte Methode, wobei wir letztes Semester nach Fusion vorgegangen sind, in den Firmen dürfte aber normal eine eigene Methode benutzt werden. Man programmiert in der Veranstaltung garnicht, wir haben ausschließlich Diagramme gemalt, aber das war am ende so gut das man es hätte 1:1 umsetzen können.
Das ist auch die Idee der Softwaretechnik, die Implementation vom Entwickeln loszubinden. Das Programm wird auf dem Papier fertig konzipiert so das man sich bei der Implementierung dann auf das programmieren und nicht auf das "wie" konzentrieren kann.
So wurde uns Softwaretechnik vermittelt und ich hab ähnliche Ansätze in anderen UNI's gesehn.

---

Geschrieben von Steve am 18.09.2006 um 10:38:

 

find ich gut
Zumal somit das Grundverständnis des Programmierens auch verbessert werden kann. Viele stellen sich unter Programmieren ja bloss Code tippen vor, auf gut Glück mal irgendwo anzufangen.
Das Diagramme zeichnen etc wär da bestimmt für viele nützlich, auch für Anfänger.

---

Geschrieben von mercany am 18.09.2006 um 20:38:

 

Man möge es nicht glauben, aber selbst so nen Laie wie ich findet an dieser Planung gefallen.
Bei den Programmen, die ich in Informatik an der Schule programmiere war dies - man muss schon sagen "leider" - bis jetzt jedoch nie von Nöten.

---

Geschrieben von Steve am 18.09.2006 um 21:09:

 

wobei ich auch nicht glaube, dass du in der Schule "grosse" Projekte gecodet hast

aber wenn es mal darum geht, wie man ne lineare einfach verkette Liste invertiert, ist so ein Diagramm und eine Skizze schon hilfreich. Ich glaube aber nicht, dass es dir darum geht in der Planung, wie du sie angesprochen hast. Fand ich aber grad ein schönes Beispiel

---

Geschrieben von Crotaphytus am 19.09.2006 um 11:39:

 

Allerdings würd ich jetzt einfach mal behaupten, dass diese Skizze dann nix mit irgendwelchen Entwurfsdiagrammen zu tun hat, das ist mehr ne Hilfe, sich das besser vorzustellen.


Gerade das Thema UML ist relativ spannend. Leider kanns beim falschen Prof auch unglaublich trocken werden...
Das Problem, warum das oft jedoch nicht so viel Spaß macht, ist folgendes: Bei allem, was man so zum Üben macht, zeichnet man die Diagramme genau aus diesem Grund, ums zu lernen. Sprich man wird mit Diagrammen zugeballert, von denen 90% sinnlos und überflüssig sind (um ne Loginfunktion zu realisieren brauch ich kein Sequenzdiagramm, nein, wirklich nicht...). Der Sinn dieses Konzepts sollte es ja eher sein, dass man sich die Sachen aus der sehr großen Auswahl rauspickt, die man für nützlich erachtet, sich jedoch im Großen an die Norm hält, damit es verständlich ist. Aber auf Teufel komm raus möglichst viele verschiedene Diagramme zu pinseln ist irgendwie frustrierend...

---

Geschrieben von Mazze am 19.09.2006 um 13:10:

 

Zitat:

von denen 90% sinnlos und überflüssig sind

Das seh ich anders.

Die Methodik ist für kleinere Anwendungen (wie etwa uni aufgaben) sicherlich ungeeignet. Da ist es einfach zuviel Aufwand. Aber wir haben mal über ein Jahr lang eine Verwaltungssoftware für eine Kampfsportschule geschrieben (incl. Datenbankserver,Webauftritt und Terminalsoftware) und wir haben selbst gemerkt wie sinnvoll eine durchdachte Planung vorher war.
Unser Prof, der neben der Lehre Leiter seiner eigenen Softwareschmiede an einem Frauenhoferinstitut ist meinte sogar das in der Industrie ca. 1/4 bis 1/3 der Entwicklungszeit der Software mit der Planung verbracht wird.
Eine solide Grundlage erleichtert vor allem das Programmieren und jeder der größere Programme schon geschrieben hat weiß das es an x-beliebigen Stellen immer zu irgendwas kommt wo man dann den ganzen Code teilweise umwerfen muss. Und so was frisst Zeit die sich die Industrie nicht leisten kann. Ergo wird sorgfältig vorher geplant. Softwareentwicklung ist mitlerweile ein Zeitspiel. Sie muss funktionieren und schneller fertig sein als die von der Konkurenzfirma.

---

Geschrieben von Crotaphytus am 19.09.2006 um 13:34:

 

Ich wollte damit nicht sagen, dass 90% von UML sinnlos sind. Es ging mir mehr darum, dass 90% von dem, das wir zu diesem Thema erstellen durften, sinnlos war, weil einfach mit Spatzen auf Kanonen geschossen wurde. Aber man muss es ja mal üben...

---

Geschrieben von Mazze am 19.09.2006 um 19:35:

 

Ja stimmt, wer Softwaretechnik an der Uni lernt wird sich oft fragen wozu das alles, aber das ist das Problem an Universitätsaufgaben

---

Geschrieben von ed209 am 20.09.2006 um 16:49:

 

Ok, ich versuch mal der bitte nachzukommen und Softwaretechnik (mein angehendes Spezialgebiet) nochmal etwas zu umreissen.

Softwaretechnik beschreibt eigentlich den ganzen Prozess der "ingieneursmässigen" Softwareentwicklung.

Ingineursmässig heisst dabei, daß man die Software nicht nur kostengünstig und schnell fertigkriegt, sondern auch gewisse Qualitätsstandards einhalten kann.
Software die in der Luft- und Raumfahrt eingesetzt wird, sollte zum Beispiel nicht so oft abstürzen wie man es von gängiger Windows-Software gewohnt ist.

Grosse Projekte bestehen ja nicht nur aus der Programmierung, sondern auch daraus festzustellen was wir (oder der Kunde) überhaupt wollen, der Analyse, dem Entwurf, zuvor.
Nach und während der Implementierung muss getestet und dokumentiert werden, sowie das fertige Softwareprodukt installiert und gewartet werden.

Werkzeuge der Softwaretechnik sind Beschreibungssprachen für die einzelnen Schritte (besonders UML) und Tools die mit diesen Beschreibungssprachen arbeiten und dabei helfen die Software zu entwickeln.

Wenn man ein kleines Programm schreibt, sieht man vielleicht noch nicht ein warum man so einen grossen Überbau braucht.
Aber sobald man anfängt zu mehreren an einem Projekt zu arbeiten oder versucht Software die man vor einem Jahr geschrieben hat, wiederzuverwenden oder weiterzuentwickeln merkt man oft schon, daß es hilft gewissen Spezifikationen zu klären, den Code zu kommentieren usw.
Wenn man sich jetzt vorstellt, daß Softwareprojekte oft mehrere hundert Beteiligte haben, dann kann man glauben daß nicht jeder drauf los programmieren kann um dann zu hoffen daß es schon läuft.

Das war jetzt mehr ein kleiner Überblick, was Softwaretechnik überhaupt sein soll. Genaueres findet sich im Wikipedia-Artikel: http://de.wikipedia.org/wiki/Softwaretechnik

Gruss,
Peter

---

Geschrieben von ed209 am 20.09.2006 um 16:57:

 

Zitat:

Original von Crotaphytus Aber man muss es ja mal üben...

Genau so seh ich das:

Ein guter Entwurf erleichter nicht nur die Implementierung, sondern macht das Programm auch übersichtlicher und wiederverwendbarer. Zusätzlich können in einer gut durchgeführten Entwurfsphase Fallstricke frühzeitig erkannt werden, so daß man eventuell vermeidet Code wegzuwerfen, weil man an bestimmte Dinge gar nicht gedacht hatte.

Gleichzeitig ist ein guter Entwurf nichts was man sich einfach so aus dem Ärmel schütteln kann. Es gibt zwar gewisse Richtlinien an die man sich dabei halten kann (z.B. die "Design Patterns" bei Objektorientierter Programmierung), aber es ist vor allem eine Sache von Erfahrung.
Früh zu üben wie man entwirft ist demnach nicht unwichtig.

Gruss,
Peter

---

Geschrieben von Schneemann am 14.03.2007 um 07:52:

 

Zitat:

Original von Mazze Das ist auch die Idee der Softwaretechnik, die Implementation vom Entwickeln loszubinden. Das Programm wird auf dem Papier fertig konzipiert so das man sich bei der Implementierung dann auf das programmieren und nicht auf das "wie" konzentrieren kann.

Das klingt in der Theorie wirklich gut, aber ich bezweifle dass es in der Praxis wirklich umsetzbar ist. Nach meiner Erfahrung entwickeln sich Programme immer sehr iterativ, d.h. man entwickelt eine Alpha-Version übergibt sie dem Kunden der viel drann zu bemängeln hat. Anschließend werden die Änderungen eingebaut und wieder eine Anwendungsphase gestartet usw. Am Ende dieses Prozesses steht leider zumeist ein Produkt dass nur noch wenig Ähnlichkeit mit der ersten Alphaversion aufweist. D.h. ein fertiges Konzipieren vor der Auslierferung ist praktisch überhaupt nie möglich, weil man bei der Planung am grünen Tisch einfach nie alles bedenken kann und dies dem Kunden auch nicht vollständig rüberbringen kann.

Sicher sollte man aber nie einfach drauf los programmieren, sondern sich vorher grob im Klaren sein was man möchte und wie es zu realisieren ist. Nur sollte man auch nicht der Illusion aufsitzen man könne Programme schon vor der ersten programmierten Zeile komplett durchdesignen. Sowas klappt genausowenig wie ein neues Automodell in Serienfertigung zu bauen ohne einen einzigen Prototyp zu haben und ohne Testfahrten zu machen.

Gruß,
Schneemann

---

Geschrieben von madde am 20.07.2007 um 08:56:

 

Zitat:

Das klingt in der Theorie wirklich gut, aber ich bezweifle dass es in der Praxis wirklich umsetzbar ist. Nach meiner Erfahrung entwickeln sich Programme immer sehr iterativ, d.h. man entwickelt eine Alpha-Version übergibt sie dem Kunden der viel drann zu bemängeln hat. Anschließend werden die Änderungen eingebaut und wieder eine Anwendungsphase gestartet usw. Am Ende dieses Prozesses steht leider zumeist ein Produkt dass nur noch wenig Ähnlichkeit mit der ersten Alphaversion aufweist. D.h. ein fertiges Konzipieren vor der Auslierferung ist praktisch überhaupt nie möglich, weil man bei der Planung am grünen Tisch einfach nie alles bedenken kann und dies dem Kunden auch nicht vollständig rüberbringen kann.

Genau deshalb folgt nach der Hochschule der erste Praxisschock. Das kann im schlimmsten Fall soweit gehen, dass man auf die Planung wegen Zeitmangel völlig verzichten muss und das ist nicht nur in kleinen Klitschen so.

---

Geschrieben von ed209 am 20.07.2007 um 11:08:

 

In manchen Betrieben kommt es wirklich nur drauf an, schnell irgendwas zusammenzuhauen, was nachher in der Wartung mal richtig teuer werden kann.

Es gibt aber auch Bereiche in denen nach modernen softwaretechnischen Prinzipien gearbeitet wird und die Kunden sogar verlangen, daß sich die Entwickler an den Prozess halten.

Bei meinem Praktikum mußte ich sogar für das gammeligste Hilfstool vorher eine Architekturbeschreibung schreiben.

Gruß,
ED

PS: Wenn du schlau bist, suchst du dir eine Firma die vernünftig entwickelt. Sonst setzen sie dich erstmal an einen Klumpen undokumentierten und schlecht geschriebenen Code, den du dann weiterpflegen sollst.