Softwaremodell



  • Hallo,

    also gibt ja bekanntlich z.b. das V Modell oder den unified process oder das Wasserfallmodell und vielleicht noch andere.

    Aber welches Modell soll man denn jetzt eigentlich verwenden ?

    also ich würds so machen.

    1.Was soll meine Software können
    2. Klassendesign
    3.Implementierung
    4.Testen
    5.Hotfix

    Wenn man beim implementieren merkt, hmm das mit meinem Design könnte besser sein dann wird man auch von stufe 3 wieder zu Stufe 2 zurückgehen.



  • was du da beschreibst, ist eine klassische idee, wie man vorgehen könnte, wenn man selber eine idee produziert und umsetzt.

    was aber, wenn du - wie in der wirklichen welt - einen kunden hast?

    wo bleibt die anforderungsanalyse bei/mit dem kunden?
    und du musst dich fragen, ob der kunde auch später mitspracherecht haben darf, also auch änderungswünsche (spontan) mit einbringen kann (agile idee).
    gibt es normen, nachdem die software laufen muss?
    und vieles mehr...

    es kommt also auf den konkreten fall an, für wen du was programmierst.
    werde konkreter, um die frage angemessen diskutieren zu können.



  • Soll das heißen wenn man für einen Kunden programmiert wendet man ein anderes Modell an ?



  • Die Modelle sind halt für Projektmanagement/Softwareentwicklungs-Management gedacht.

    Je nach Projektgröße, Zielsetzung, Teamgröße, Leistungsumfang uvm. können sich da verschiedene Modelle anbieten. Welches am Besten ist ergibt sich aus einer Informationssammlung zum Projekt und auch aus Präferenzen.

    Deinen Punkt 1 würde ich zu "Use Case-Analyse" oder "Anwendungsfall-Analyse" ändern. Schau, welche Anwender es gibt und was die machen wollen. Das ist der erste Schritt. Vorher kann man natürlich noch Marktforschung betreiben, Risikoanalysen betreiben, einen Zeitraum festlegen, irgendwelche Kostenrechnungen... Hängt jetzt auch vom Umfeld ab, in dem Du das Projekt angehen willst.

    2. Klassendesign ist so eine Sache. In größeren Projekten baut man gerne Geschäftsprozesse. Das macht auch Sinn, wenn Du noch andere Bereiche des Unternehmens mit einbeziehen willst, die auch wissen sollen, worum es geht, obwohl das keine ITler sind.

    Statt Geschäftsprozessmodellen kann man auch ein paar Ablauf/Aktivitätsdiagramme basteln, um zu sehen, wie sich die Anforderungen zu einzelnen Schritten aufschlüsseln.

    Klassendesign ist dann ganz gut. Aber ich würde nicht zu sehr bei Methoden oder Attributen ins Detail gehen. Ich denke, das machen viele, ich finde es aber sinnlos und würde es eher an den Anschluss des Programmiervorgangs setzen, da man doch wieder alles umschmeißt.

    Vor dem Klassendesign könnte man übrigens auch ein System- oder Komponentendiagramm machen. Da schreibst Du auf einer höheren Ebene hin, was für Systeme mit Softwarekomponenten es geben könnte, wie die Schnittstellen aussehen sollen... man kann auch die Netzwerkinfrastruktur bedenken oder so. Aber das braucht man natürlich nicht immer.

    Na ja, dann programmiert man vor sich hin.

    Und dann kann man entweder Ansätze wie "Test driven development" fahren oder halt nach gewissen Schritten immer Mal größere Funktions- und Integritätstests fahren und dann weiterarbeiten. Wichtig für die Durchführung eines Projekts finde ich Meilensteine (mit Zeit) und einzelne, kleinere Ziele oder Aufgabenpakete. Das ganze Zielmanagement ist enorm wichtig, weil das zur Motivation und zum Statusabgleich notwendig ist.

    Entwicklung und Testen wechseln sich dann natürlich immer so ein bisschen ab. Vor der Softwareauslieferung sollte man natürlich nochmal einen umfassenderen Test machen.

    Dann kann es auch sinnvoll sein, die Installation beim Kunden zu planen mit Zeitplänen etc., wenn es sich um umfangreichere Software handelt.

    Wo genau liegt dein Problem?



  • blurry333 schrieb:

    Soll das heißen wenn man für einen Kunden programmiert wendet man ein anderes Modell an ?

    nein, nicht unbedingt, nur ... wenn man nicht weiß, worauf es hinausläuft, diskutiert man zu abstrakt.
    das richtige modell entscheidet sich über den anwendungsfall/auftrag/die domaine...

    (für einen flugzeughersteller eine applikation zu enwickeln ist (benötigt) was anderes als im web dynamische seiten mit datenbankanbindung zu erstellen oder für eine fabrik eine maschine einzustellen oder eine medizinische maschine zu programmieren oder sich im bankenwesen rumzutummeln.)


Log in to reply