| Die letzten 10 Beiträge |
| ed209 |
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. |
| madde |
| 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. |
| Schneemann |
| 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 |
| ed209 |
| 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 |
| ed209 |
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 |
| Mazze |
Ja stimmt, wer Softwaretechnik an der Uni lernt wird sich oft fragen wozu das alles, aber das ist das Problem an Universitätsaufgaben 
|
| Crotaphytus |
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... |
| Mazze |
| 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. |
| Crotaphytus |
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... |
| Steve |
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
|
| Es sind weitere Beiträge zu diesem Thema vorhanden. Klicken Sie hier, um sich alle Beiträge anzusehen. |
|
|
