Buchtip allgemeines Software engineering

ZSchneidi

Hi Leute,

mir fällt in letzter Zeit immer wieder auf, das ich eigentlich so gar keinen richtigen Plan bzw. entsprechendes Wissen über die einzelnen Aspekte der Programmierung habe. Ich bin zwar noch nicht lang dabei und lerne ständig neues,
aber irgendwie habe ich beim lesen Mancher Blogs oder anderer Literatur immer wieder den Effekt, das ich was lese, wovon ich noch nie gehört hab.

Da Frag ich mich manchmal wie viele Themen es bei der Programmierung überhaupt noch zu beachten gibt.

Beispiel "Agile Softwareentwicklung" hab ich vor kurzem das erste mal gelesen und es gibt immer wieder Begriffe oder Paradigmen die mir von der Idee her gänzlich unbekannt sind, auch wenn man vielleicht schon mal davon gelesen hat.

Ich wollte euch nun fragen, ob ihr vielleicht Buchtipps habt, die einen auf den aktuellen Stand der Softwareentwicklung bringt. In dem Technicken und zusammenhänge erläutert werden.

Bücher die sich auf 1300 Seiten über ein Thema auskotzen, bis einem die Augen bluten hab ich

Es wäre aber vielleicht mal nützlich ein Buch zu haben, das meinen Wissenstand mal auf einen Schlag auf den heutigen Stand bringt.

Oder meint ihr ich komm da um den langen Lernprozess nicht umher ?

Danke für Tipps hierzu

UPDATE:
Sowas wie dieses hier vielleicht
http://www.amazon.de/Softwareentwicklung-Einstieg-Anspruchsvolle-Werner-Sch%C3%A4fer/dp/3827328519
Vielleicht hats ja schon jemand gelesen, oder vergleichbares zumindest.

Die Literaturliste aus unserer Vorlesung sieht so aus:

Software Engineering | ISBN: 3827372577
Software Engineering | ISBN: 0072496681
Using Uml: Software Engineering With Objects and Components | ISBN: 0201648601
Designing Object-oriented Software | ISBN: 0136298257
Analyse und Design mit UML 2.3 | ISBN: 3486588559

Ob die was taugt kann ich natürlich nicht bewerten. Aber das Schlechteste vom Schlechtesten ist hoffentlich nicht dabei. Zumindest ist da keines von Galileo Computing oder JW auf der Liste
Ich gehe davon aus, dass das alles für SE-Einsteiger geeignet ist, die Vorlesung richtet sich immerhin an ebensolche. Ich hoffe, es ist was dabei.
Auf einen langen Lernprozess darfst du dich aber vermutlich so und so einstellen.

Warum kriegt er nur so wenig Antworten? Es scheint so als wenn sich hier niemand mit Software Engineering beschäftigt! Wie kann das sein?

Oo schrieb:

Warum kriegt er nur so wenig Antworten? Es scheint so als wenn sich hier niemand mit Software Engineering beschäftigt! Wie kann das sein?

C++ ist halt inzwischen in erster Linie eine Hobbysprache, statt etwas was man im Beruf einsetzt, daher beschäftigen sich hier wohl vergleichsweise eher wenige Leute mit sowas

Oo schrieb:

Warum kriegt er nur so wenig Antworten? Es scheint so als wenn sich hier niemand mit Software Engineering beschäftigt! Wie kann das sein?

SE ist keine Wissenschaft sondern ein durchhyptes und langweiliges Gebiet voller Trends und Moden.
Nichts, womit man Zeit verschwenden müsste.

lolalter schrieb:

Oo schrieb:

Warum kriegt er nur so wenig Antworten? Es scheint so als wenn sich hier niemand mit Software Engineering beschäftigt! Wie kann das sein?

SE ist keine Wissenschaft sondern ein durchhyptes und langweiliges Gebiet voller Trends und Moden.
Nichts, womit man Zeit verschwenden müsste.

Klar, dass das zutrifft, wenn man mit C++ arbeitet, der Englischen Küche unter den Programmiersprachen.

expertentyp schrieb:

lolalter schrieb:

Oo schrieb:

Warum kriegt er nur so wenig Antworten? Es scheint so als wenn sich hier niemand mit Software Engineering beschäftigt! Wie kann das sein?

SE ist keine Wissenschaft sondern ein durchhyptes und langweiliges Gebiet voller Trends und Moden.
Nichts, womit man Zeit verschwenden müsste.

Klar, dass das zutrifft, wenn man mit C++ arbeitet, der Englischen Küche unter den Programmiersprachen.

Ich bin zur französischen Küche gewechselt.

lolalter schrieb:

SE ist keine Wissenschaft sondern ein durchhyptes und langweiliges Gebiet voller Trends und Moden.
Nichts, womit man Zeit verschwenden müsste.

wegen leuten wie dir verdient man als software engineer so gutes geld. irgendwer muss den karren am ende ja aus dem dreck ziehen und den big pile of mud entwirren. danke dafür!

Oo schrieb:

Warum kriegt er nur so wenig Antworten? Es scheint so als wenn sich hier niemand mit Software Engineering beschäftigt! Wie kann das sein?

Meiner Meinung nach lässt sich "klassisches" Modellieren einfach relativ schlecht lehren. Das hat einfach viel mit Erfahrung zu tun. Die gängige Lehrmethode à la "Man nehme den Anforderungstext, jedes Substantiv ist eine Klasse, jedes Verb eine Methode" funktioniert meines Erachtens in der Praxis nicht besonders gut.
Der Kontext wird dabei ja völlig außer Acht gelassen - nicht immer designt man Systeme im luftleeren Raum. Oft entsteht Software ja nicht durch planen->durchführen, sondern der Quellcode und die dahinterliegende Struktur entwickeln sich. Da kann es dann hin und wieder sinnvoll sein, Teile neu zu entwerfen; und dabei muss eben stark die Umgebung berücksichtigt werden. Auch, wie "tief" man entwirft, variiert von Projekt zu Projekt und je nachdem, wieviel sich wirklich planen lässt.

Zu guter Letzt funktioniert viel Software auch ohne guten Entwurf und ist dabei noch wartbar.

mal hand hoch: wer modelliert hier bitte in UML und macht tolle design pläne, bevor er anfängt zu programmieren? das ist doch die absolute zeitverschwendung, da sich die anforderungen sowieso ständig ändern.

effektiver gehts doch so:
1. grobe systemarchitektur überlegen
2. coden
3. unittests
4. refactorings
5. goto 2

roflalter schrieb:

mal hand hoch: wer modelliert hier bitte in UML und macht tolle design pläne, bevor er anfängt zu programmieren? das ist doch die absolute zeitverschwendung, da sich die anforderungen sowieso ständig ändern.

effektiver gehts doch so:
1. grobe systemarchitektur überlegen
2. coden
3. unittests
4. refactorings
5. goto 2

Mal ne dumme Frage: Wie haltet ihr technische oder Kundenanforderungen fest? Etwa in Wortschrift?!

volkard

Steffo schrieb:

Mal ne dumme Frage: Wie haltet ihr technische oder Kundenanforderungen fest? Etwa in Wortschrift?!

Manchmal auch in Schriftschrift oder Wortzeichnungen oder Bilderwörtern. Je nachdem, was gerade sinnvoller ist.

edit: Nee, meistens in Wortwörtern. Es geht nicht um den konkreten Auftrag, auf einen Auftrag kann man immer kacken, es geht um die folgenden. Das Schreibselbleibsel ist nur Schnippelgehippel. Geht natürlich nur, wenn man kleinfein ist und die Verkäuferläufer nicht balkenbiegend lügentrügen.

volkard schrieb:

Steffo schrieb:

Mal ne dumme Frage: Wie haltet ihr technische oder Kundenanforderungen fest? Etwa in Wortschrift?!

Manchmal auch in Schriftschrift oder Wortzeichnungen oder Bilderwörtern. Je nachdem, was gerade sinnvoller ist.

:p
Es gibt nichts schlimmeres als Anforderungen in Aufsätzen festzuhalten. Sie sind oft mehrdeutig, unpräzise, es gibt evtl. sprachliche Barrieren in internationalen Teams, sind aufgebläht etc.
SE-Modelle machen schon Sinn. Wenn man alles vorher sauber dokumentiert, kann man evtl. auch Abweichungen festellen: Was macht der Code und was hätte es machen sollen. Die Einarbeitungszeit für andere/neue Mitarbeiter verkürzt sich ebenfalls.
Zustandsdiagramme, Petrinetze etc., das sind alles sehr sehr präzise Modelle, da hat sich jeder schnell eingearbeitet. Oder stell dir mal vor Software soll von Programmiersprache A nach Programmiersprache B portiert werden. Da ist eine vernünftige Dokumentation die beste Basis, weil sofort ersichtlich ist, was die Software genau tun soll!
XP halte ich für ein weiteres gutes Modell. Der Kunde kann die Software während des Entwicklungsprozesses sehen und evtl. eingreifen, wenn das Projekt in die falsche Richtung geht. Das ist nämlich teuer und kann Aufträge kosten.

L. G.
Steffo

volkard

WIR sind die Schlauberger, die aus den Anforderungen Modelle zaubern. Die Kunden sind Idioten (bezüglich SE).
Wenn mein Kunde erst jemanden einstellen muß, der meinen UML-Entwurf versteht, kann er's auch selber machen.
Dann wäre ich nur aus steuerlichen und kündigungsrechlichen Gründen ausgelagerter Codemonkey.

Es gibt Use-Case-Diagramme die jedes Kind versteht und für XP braucht der Kunde gar kein Modell zu verstehen, sondern einfach nur das Produkt mal zu testen.
Die klassische Methode: Kunde gibt Auftrag und nach einigen Monaten wird das fertige Produkt geliefert und entweder es gefällt dem Kunden oder es gefällt ihm nicht, ist von vorvorgestern.
SE-Modelle verwendet man zugegebenermaßen vor allem intern, aber sie sollten eben verwendet werden.

volkard

Steffo schrieb:

Es gibt Use-Case-Diagramme die jedes Kind versteht

Die sind gut. Als Aufsatz aber auch möglich.

Steffo schrieb:

und für XP braucht der Kunde gar kein Modell zu verstehen, sondern einfach nur das Produkt mal zu testen.

Naja, da kann auch was offen bleiben.

Steffo schrieb:

Die klassische Methode: Kunde gibt Auftrag und nach einigen Monaten wird das fertige Produkt geliefert und entweder es gefällt dem Kunden oder es gefällt ihm nicht, ist von vorvorgestern.

Naja, damit hat das Maut-Konsortium Milliarden gepunktet. Hätte vielleicht nicht sein müssen.

Steffo schrieb:

SE-Modelle verwendet man zugegebenermaßen vor allem intern, aber sie sollten eben verwendet werden.

Je nach Projekt. Das Maut-Desatster wäre damit nicht verhindert worden. Betriebliche Anwendungen, oder auf die Spitze getrieben, Vereinsverwaltungen, die man optimalerweise im CASE-Tool in einem Tag zusammenklickt, rufen natürlich danach. Verrückte Anforderungen wie "Entwerfen Sie eine gescheite OSI-Schicht 4 für die Telekom nd implementieren Sie einen glaubwürdigen Prototyp" (kein Witz, ist an mich herangetragen worden!) kannste damit gar nicht erfassen. Es paßt nicht. Alle mathematischen, naturwissenschaftlichen, ingenieurigen Anwendungen haben da ein dickes Problem, fürchte ich.

Ich verstehe nicht, worauf du mit deinen Einwänden hinaus willst. Modelle können natürlich unmöglich die Realität abbilden, deswegen können auch trotz guter Planung unerwartete Probleme eintreten, das bestreitet niemand. Aber so vorzugehen, wie man das noch vor einigen Jahrzehnten gemacht hat, ist das viel größere Übel.

volkard

Man kann nicht immer dem Auftraggeber aufbürden, zu modellieren, weil er viel zu blöd ist. Stell Dir nur mal eine behördliche Bedarfsfeststellungskommission vor (ja, die gibt es!).

Wie gesagt: SE-Modelle werden vor allem intern verwendet. Wenn ein paar interne Programmierer den geschriebenen Auftrag in ein Modell abstrahieren, dann hat die ganze Mannschaft etwas davon und gerade bei der Abstraktion können evtl. Doppeldeutigkeiten, unpräzise Ausdrücke etc. auffallen, die man dann klären kann. Eine direkte Abstraktion auf Code-Ebene sehe ich da ehrlich gesagt als ziemlich problematisch, weil man sich beim Coden in Details verliert und ohne technische Dokumentation kann man hinterher evtl. auch gar nicht mehr sagen welches Verhalten richtig ist und was nicht, d. h. man kann gff. nicht sagen, ob eine Funktion ein Bug oder eben gewollt ist.

volkard

Steffo schrieb:

Wie gesagt: SE-Modelle werden vor allem intern verwendet.

Achso. Ich hatte

Steffo schrieb:

Wie haltet ihr technische oder Kundenanforderungen fest?

dann falsch verstanden. Intern muß man natürlich das Modell festhalten.