Buchtip allgemeines Software engineering
-
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.
-
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.
-
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.
-
volkard schrieb:
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.
Siehste, hätte es das als abstrahiertes Modell gegeben, wäre das nicht passiert.
-
Steffo schrieb:
volkard schrieb:
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.
Siehste, hätte es das als abstrahiertes Modell gegeben, wäre das nicht passiert.
Ist um.
Nach http://www.c-plusplus.net/forum/294754 nehme ich Dich nicht mehr ernst. Du hast noch nie von SE andeutungsweise gelebt.Hochschulblabla.
-
Jo, Petrinetze waren auch mal Hochschulblabla...
Aber von C++ habe ich wirklich (fast) keine Ahnung.
-
in der theorie sind die SE modelle ja ganz toll, aber in der praxis? letztendlich ist jedes modell, das sich nicht automatisch aus code generiert, schon in dem moment veraltet und somit obsolet, sobald du mit der programmierung anfängst. denn idR ändern sich die anforderungen eh ständig. und nun? sitzt dann da ein toller systemarchitektur und passt pausenlos die systemmodelle an die neue wirklichkeit an? plottert ihr euch täglich neue quadratmetergroße kassendiagramme an die wand, um den überblick zu behalten?
es gibt nur eine sinnvolle dokumentation von software: den code! alle weiteren dokumentationen, die manuell erstellt werden müssen, sind letztendlich überflüssiger overhead.
-
Steffo schrieb:
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.Hast du das nur gelernt oder schon in einigen Projekten mit Kunden angewendet?