Buchtip allgemeines Software engineering
-
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?