001
19.05.2005, 21:45 Uhr
virtual
Sexiest Bit alive
(Operator)
|
Die traditionelle Einteilung ist etwa folgende:
1. Systementwicklung:
1.1 Analyse
1.2 Design
1.3 Implementierung
1.4 Test und Installation
2. Systemnutzung
Wartung und Erweiterung
Unter 1.1 formuliert man im wesentlichen noch in der Kundensprache (Stichworte: Lastenheft, Pflichtenheft)
Unter 1.2 wird eine eher technische Sicht eingenommen, (Stichworte: fachliches Design, technisches Design). Solange nicht bereits schon durch die Analyse vorgegeben, sollte im technischen Design auch stehen, welche Kriterien dazu geführt haben, sich auf eine bestimmte Architektur festzulegen. Sollte die Wahl nicht trivial sein, so würde ich in einem guten Design auch die Aufzählung der Alternativen erwarten und vor allem eine Begründung, warum sie nicht in betracht kamen.
1.2 und 1.4 sollten klar sein.
Aber:
es gibt neben diesem traditionellen modellen auch alternativen, manche haben Namen, manche nicht, manche basieren auf den Eigenheiten der Verantwortlichen, andere eben nicht.
z.B: gehe ich ganz gerne hin und schreibe einen gewissen Prozentsatz der Testfälle bereits zur Designphase. Dh zB bei Java gehe ich hin und schreibe die JUnit Tests bereits während des Designs, so daß ich zum einen sicher gehe, daß ich testbare Software designer, andererseits die Implementierer schobn mal leichter was ad hoc testen können.
Denn man darf bei dem ganzen kram nicht vergessen: je weiter ein projekt fortschreitet, desto teurer werden die Fehler.
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21) |
)
