Diskussion:Agile Modeling

Der Artikel enthält meines Erachtens nach zu wenig Text. Kann mal jemand, der sich sehr gut mit Agile Modelling auskennt, etwas Text um die Stichpunktlisten herum schreiben? --ChristianHujer 01:08, 5. Apr 2005 (CEST)

Naja, ich hab bewusst versucht, mich sehr kurz zu fassen weil wikipedia ja ein Lexikon ist und im Web genug Material verfügbar ist. aber vielleicht sollte in der Literaturliste was geschehen und einige Querverweise ergänzt werden? Ein Buch über AM in Wikibooks wäre denkbar, aber eben auch sehr aufwendig. Wir sollten uns also über die Zielsetzung eines Wikipediartikels über AM klar werden um daraus den sinnvoll zu betreibenden Aufwand bzw. Umfang des Artikels definieren. Die Diskussion kann hier stattfinden oder wir machen das gleich per mail/chat -s. Benutzerseite für Kontaktdaten --HJG 12:34, 5. Apr 2005 (CEST)

Ich habe es schon bei einigen anderen Artikeln gesehen, reine Stichpunktlistenartikel sind nicht die Zielsetzung der Wikipedia, da gibt's extra eine Änderungskategorie dafür. Etwas Text darüber, was Agile Modelling ist, würde wirklich nicht schaden und sicher mehr aussagen als nur die Stichpunktlisten. Insbesondere jemand, der von dem Thema zum ersten Mal hört, kann mit den Stichpunktlisten praktisch nichts anfangen. Für Profis sind die natürlich Klasse. Um die den Stichpunktlisten zu eigene positive Übersichtlichkeit nicht zu verlieren, kann man die Begriffe ja kursiv hervorheben. Ein Text hätte allerdings den Vorteil, mittels Verben wesentlich mehr Zusammenhang zwischen den Begriffen und zu anderen Themen herzustellen. Rückverweise zu Extreme Programming, Agile Methoden, Agile Prozesse, Softwaretechnik etc. ließen sich dann auch sehr gut in den Text einbauen. Ich würd's ja selbst machen, aber nachdem ich mich zwar sehr für Agile Modelling interessiere, mich aber kaum damit auskenne, kann ich schlecht Texte über Agile Modelling verfassen. Gerade weil die Wikipedia ein Lexikon ist, sollte es sich ja nicht um Stichpunktsammlungen sondern für ein Lexikon typische definierende und erklärende Texte handeln.--ChristianHujer 00:56, 7. Apr 2005 (CEST)

Ach nochwas: Was ist denn die Richtlinie für englische Begriffe in der Wikipedia - AE oder BE? Soviel ich weiß, BE, dann müsste dieser Artikel nach "Agile Modelling" verschoben werden (2l), aber da bin ich mir nicht sicher. Wenn's jemand weiß, bitte Kommentar hier und ggf. Artikel verschieben, Danke :) --ChristianHujer 00:59, 7. Apr 2005 (CEST)

Deine Argumentation leuchtet ein. Ich schreib ein bissel mehr sobald ich wieder etwas Zeit habe. --HJG 16:55, 7. Apr 2005 (CEST)

Fragen:

• Ist Agile Modeling ein Agiler Prozess oder ist es eine Agile Methode zur Unterstützung eines agilen Prozesses? Oder ist es vielleicht ein Konglomerat aus agiler Methoden und Prinzipien, welches eine Gesamtphilosophie zur Unterstützung eines agilen Prozesses bildet?

Aus dem Artikel würde ich die letzte dieser drei Möglichkeiten schließen, bin mir aber nicht 100% sicher. Das sollte man noch etwas herausarbeiten, wie z.B. "Agile Modeling ist eine Philosophie über die Anwendung von Prinzipien und Agilen Methoden in Agilen Prozessen".

Ich habe versucht, Deine Frage zu beantworten. Bitte hake nach wenn ich zu kurz oder unpräzise war. --HJG 17:33, 10. Apr 2005 (CEST)

• Wenn Crystal Family ein "Vertreter" des Agile Modeling ist, warum dann nicht auch Extreme Programming?

Weil Crystal reine Prozessbeschreibungen sind, die sowohl für die Programmierung, als auch für den Entwurf genutzt werden können. --HJG 17:33, 10. Apr 2005 (CEST)

Wenn ja, wo ist die Abgrenzung zwischen Agile Modelling und Agilen Methoden / Agilen Prozessen?

A Modelling ist agiler Softwareentwurf, die A Methoden sind arbeitsorganisatorische oder technologische Beschreibungen von Handlungsweisen, die sowohl den Entwurf, aber auch die Prorammierung, das Testen, das Projektmanagement bis hin zum Projektcontrolling und der Project Review umfassen. Sie sind also quasi die Handlungsanweisungen innerhalb des Modellierens (AM) oder des Programmierens (XP). --HJG 17:33, 10. Apr 2005 (CEST)

Wenn nein, warum ist Crystal Family ein Vertreter des Agile Modeling, aber nicht Extreme Programming?

Es ist eine Möglichkeit für beides. Man müsste das also im XP anmerken. --HJG 17:33, 10. Apr 2005 (CEST)

--ChristianHujer 15:51, 10. Apr 2005 (CEST)

<<< du stellst gute fragen, das bringt den artikel voran. lass uns das weiterführen! --HJG 17:33, 10. Apr 2005 (CEST)

Den Exkurs finde ich ein kleinwenig zu ausschweifend.

Das ist nicht ganz verkehrt. Ich bin für straffende Umstellungen offen. Es ist schwerer als gedacht, eine 6-stunden vorlesung (die eh schon viel zu straff war) in ein paar zeilen zu pressen. also nur zu - bau mit dran rum, der absatz muss besser werden, ich hab im moment aber zu wenig distanz dazu. --HJG 23:30, 10. Apr 2005 (CEST)

Er lässt den Schluss zu, dass zwischen phasenorientierten Softwareentwicklungsprozessen und begrenzter Speicherkapazität bei den früher (lies: _sehr_ viel früher ;) verwendeten Datenträgern ein Zusammenhang bestünde. Das halte ich aus mehreren Gründen für falsch:

Es wäre nur halb richtig. der zusammenhang besteht weil man aus rein technischen und kostengründen in sich geschlossene phasen brauchte, was zudem auch was mit deren dauer und organisatorischen dingen zu tun hat. --HJG 23:30, 10. Apr 2005 (CEST)

Ich meine, allein organisatorische Gründe sind ausschlaggebend für Phasenmodelle. Sie sind in anderen Ingenieurswissenschaften ebenso zu finden wie in der Informatik. Die früher begrenzte Speicherkapazität hat meines Erachtens nach nichts mit Phasenmodellen zu tun, und auch nicht solche erfordert oder dazu geführt. Siehe: Idee, Pflichten-/Lastenheft, Implementierung, Test, Auslieferung. Phasenmodell, aber 0 Zusammenhang zu Datenträgerkapazität. Oder klassisch OOM: OOA -> OOD -> OOI - wieder kein Zusammenhang zur Datenträgerkapazität.--ChristianHujer 02:01, 11. Apr 2005 (CEST)

• Bei einigen industriellen Projekten wird nachwievor auf das klassische Phasenmodell zurückgegriffen, den Wasserfall. Dieser wird vor allem dort eingesetzt, wo ganze Unternehmenskonsortien langfristig zu entwickelnde Software in Auftrag geben und zusätzlich klar ist, dass sich die Anforderungen wohl kaum ändern werden.

das ist richtig. ich mag das wasserfallmodell auch. und ja, er wird verwendet wenn die anforderungen relativ stabil und das projekt nicht zu lang ist. große projekte werden letztendlich zwar manchmal mit wasserfall gemacht, was aber auch heftig in die hose geht. besser ist da das spiralmodell, was a (böse verkürzt) auch nur ne folge von wasserfällen ist. also muss in dem exkurs irgendwie rauskommen, dass phasenmodelle (so wie andere modelle auch) auch im am durchaus angewendet werden, nur eben anders. --HJG 23:30, 10. Apr 2005 (CEST)

Sinn / Unsinn von Wasserfall oder Wasserfall vs. Spiralmodell brauchen wir nicht diskutieren. Den Wasserfall habe ich als Beispiel gebracht, um zu zeigen, dass der Zusammenhang zwischen Phasenmodellen und Organisation wesentlich ausschlaggebender für die Entwicklung von Phasenmodellen war als Datenträgerkapazitäten.--ChristianHujer 02:01, 11. Apr 2005 (CEST)

• Auch modernere Softwareentwicklungsprozesse wie RUP oder XP kennen Phasen, auch wenn sie dort zyklisch wiederholt werden und gegenüber der strikten Abgrenzung im Wasserfall fließend ineinandergreifen.

genau dieses ineinandergreifen ist ja der punkt - ebenso wie die zyklische geschichte. das ganze ging auf barry boehm mit seinem spiralmodell (1986?) irgendwie zurück. ich möchte vermitteln, dass die bekannten phasenmodelle ergänzt werden durch eine philosophie, die eben das dogma starrer ("schwergewichtiger") prozesse gegen das prinzip der zweckmäßigkeit (oder besser: zweckmäßigen verkürzung, "leichtgewichtiger prozesse") --HJG 23:30, 10. Apr 2005 (CEST)

Stimmt schon. Nur sollte nicht vergessen werden, dass Agile Modelling (habe inzwischen einiges darüber gelesen) eine auf Analyse und Entwurf, also Modellierung ausgerichtete Sammlung abstrakter Methoden zur Prozessergänzung und -verbesserung ist. Agile Modelling beruht auf ähnlichen Extremspiralmodellerfahrungen wie Extreme Programming und besitzt damit wie RUP oder XP eine starke Affinität zum Spiralmodell, die es sicher wert ist, im Artikel zu erwähnen. Allerdings lassen sich die meisten Prinzipien des Agile Modelling auch bei einem Wasserfall anwenden, selbst wenn ein Wasserfall eigentlich definitionsgemäß kaum ein agiler Prozess ist.

Dass Oop nicht mit C#, Java oder C++ erfunden wurde, sondern SmallTalk und Eiffel wesentlich ältere objektorientierter Programmiersprachen sind, braucht meines Erachtens nicht nicht bei Agile Modelling erwähnt werden, ich sehe keinen direkten Zusammenhang, zumal, ich stelle diese Behauptung einfach mal

das ist richtig. da bin ich ein wenig ins plaudern gekommen. however - die entwicklung der vorgehensmdelle hat übrigens sehr mit der entwicklung der programmiersprachen, der hardware und der entwurfstechniken zu tun. irgendwie sollte das mit rein in den artikel, aber wenn nicht, auch ok. --HJG 23:30, 10. Apr 2005 (CEST)

Diese These lehne ich vehement ab. Es lässt sich unter Anwendung von Oop, UML und Extreme Programming in Assembler programmieren. Es gibt auch zahlreiche Programmierer, die, als sie das erste Mal von RUP, XP etc. gehört haben, immer nur sagten "Na toll - und was daran ist bitteschön neu?", aus gutem Grund, weil sie es bereits vorher so gemacht haben. Der einzige Zusammenhang, den ich sehe, ist die konstante Fortentwicklung auf beiden Seiten - Hardware / Programmiersprachen / Entwurfstechniken und Vorgehensmodelle. Oder nehmen wir das V-Modell. Auch da kann ich absolut keinen Zusammenhang zur Entwicklung von Programmiersprachen, Hardware und Entwurfstechniken. Wie gesagt, ich behaupte, zwischen der Entwicklung z.B. modernerer Prozessoren und der Vorgeschichte / Entstehung von Agile Modelling keinen Zusammenhang.--ChristianHujer 02:01, 11. Apr 2005 (CEST)

auf, Agile Modelling absolut nichts mit Oop zu tun hat, sondern das Paradigma austauschbar ist.

das ist ebenfalls richtig. AM ist unabhängig vom entwurfsparadigma. wenn das rüberkommt, unbedingt umbauen. wo hab ichs nur *suchsuch* --HJG 23:30, 10. Apr 2005 (CEST)

Zudem bezweifle ich mittlerweile, dass Crystal Family ein "Vertreter" des Agile Modelling ist, da es sich bei Crystal Family entweder um im Sinne Agiler Prozesse vollständige Prozesse oder zumindest um wesentlich vollständigere Prozesse als Agile Modelling handelt, während das Agile Modelling so wie ich das von http://www.agilemodeling.com/ verstehe nur Richtlinien für das Modelling, also eine Modelling-Philosophie darstellt.

hm. das ist nicht ganz so einfach. ich fürchte, dass das nicht komplett klar ist. ich denke, dass die prozesse in die philosophie eingebettet sind. so gesehen ist crystal ein prozess des Am wie auch des XP usw. --HJG 23:30, 10. Apr 2005 (CEST)

Außerdem plädiere ich dafür, den Abstraktionsgrad des Agile Modelling mehr hervorzuheben. Agile Modelling beschreibt organisatorisch-methodische Grundlagen für Software-Modelling, nicht konkrete Methoden.

da geh ich prinzipiell mit, wobei das bei einigen methoden eng wird, aber da ich die begrifflich etrennung auch grad nicht definieren kann, sollten wir das erstmal so abgrenzen --HJG 23:30, 10. Apr 2005 (CEST)

Ich habe den Artikel Agile Methode um eine Trennung zwischen Methode und Prinzip erweitert. Wir sollten uns überlegen, ob wir für agiles Prinzip einen eigenen Artikel anlegen und den entsprechenden Text aus agile Methode dorthin verschieben. Die Logik spricht absolut dafür. Der Begriff "Agiles Prinzip" ist zwar nicht sehr häufig in Gebrauch, was aber meines Erachtens vor allem daran liegt, dass die Mehrzahl der Leute das ganze nur durch Hörensagen kennt. Dabei ist die Abgrenzung Agiler Prozess vs. Agile Methode vs. Agiles Prinzip eigentlich sehr einfach. Immerhin liefert Google "Agile Principle" 150, "Agile Principles" 683 Treffer. Weitere Diskussion zum Thema Methode vs. Prinzip sollte am besten auf Diskussion:Agile Methode stattfinden.--ChristianHujer 02:01, 11. Apr 2005 (CEST)

Konkrete Methoden wären Story-Cards, Analyse, Entwurf, CRC-Karten etc..

vermutlich müssen wir die entsprechenden beiträge in wikipedia erst noch anlegen :( --HJG 23:30, 10. Apr 2005 (CEST)

Ein Teil der Artikel existiert schon.--ChristianHujer 02:01, 11. Apr 2005 (CEST)

Im Augenblick muss man sich den Abstraktionsgrad selbst herleiten. Für jemanden, der von Modelling keine Ahnung hat, erscheint das im Vergleich zu OOA/D oder den Modelling-Vorschlägen von XP sonst etwas seltsam.

ja. klar. --HJG 23:30, 10. Apr 2005 (CEST)

--ChristianHujer 21:58, 10. Apr 2005 (CEST)

Nochmal zusammenfassend: Der klassische objektorientierte Prozess (OO Analyse -> OO Entwurf -> OO Implementierung), das V-Modell, oder die klassische Wasserfallvorgehensweise (Pflichtenheft/Lastenheft -> Implementierung -> Test -> Auslieferung) sind für mich Argumente, dass a) kein Zusammenhang zwischen Datenträgerkapazität und Entwicklungsprozess und b) kein bzw. kaum ein Zusammenhang zwischen Fortschritten bei Programmierparadigmen, Programmiersprachen sowie Mikroprozessoren und dem Entwicklungsprozess besteht. Du musst schon konkrete Argumente bringen, um mich vom Gegenteil zu überzeugen. --ChristianHujer 02:01, 11. Apr 2005 (CEST)

vielleicht sollte man den exkurs dafür erstmal in einen diskussiosbereich kopieren oder gleich rausnehmen und per mail diskutieren. ber ein paar gedanken auf die schnelle: beginnend bei der hollerith von 1910 ist es so, dass programme nicht für probleme sondern maschinen geschrieben wurden, die ihrerseits für ein problem gebaut wurden (wie die hollerith für volkszählung). damit war das grundlegende vorgehen zwangsweise phasenorientiert, weil man z.b. nicht parallel entwickeln konnte, testen erst nach abschluss anderer phasen mögliuch war und man einfach noch nicht die möglichkeiten hatte, z.b. debugger zu nutzen weil es keine gab. des weiteren ist die arbeit mit lochkarten und lochbändern rein von der betriebsorganisation her schon schwierig - man muss phasen planen weil z.b. stanzen erst nach coden kommen konnte. heute ist das speichern und verfügbar machen von daten parallel zumprogramm möglich.

strukturierter entwurf geht von der trennung von daten und methoden aus. entsprechend werden datenfluss und kontrollfluss auch getrennt modelliert im Datenflussdiagramm bzw im Kontrollflussdiagramm. Das macht sinn in zeiten, wo man rein technisch gar keine andere möglichkeit hatte jund die synchronisierung von datenverfügbarkeit und programmanforderung noch separat bedacht werden musste. dieser zustand wurd erst durch nichtserielle speicher (hierzu gehören eben auch magnetbänder, lochbänder, lochkarten aber auch die beliebten datasetten der 80er und frühen 90er jahre) geändert. jetzt konnte man genug daten halten, um die daten aus dem ram zu holen statt vom langsamen festspeicher und man hattte die daten an jeder stelle des programmlaufs verfügbar. jetzt konnte man anders entwickeln, schnelle prototypenerstellun, code&fix, parallele und zyklische vorgehensmodelle wurden erst mit einführung der diskette denkbar, mit der festlatte realistisch. durch die einführung der maschinenneutralen sprachen konnte man prolemorientiert programmieren weil die hardware nicht mehr problemorientiert war sondern generalisiert. die darauf laufende software schuf den bezug zum problem. damit wurden funktionsorientierte entwurftechniken sowie die damit verbundenen strukturierten entwurfs- und vorehensweisen möglich. es wurden auch rückkoplungen möglich, durch die verbesserte nutzbarkeit allgemeiner rechenmaschinen konnte man jetzt z.b. verbesserungsmodelle erfinden nd nutzen, das prototypische arbeiten wurde bezahlbar, die menge an vorgehensmodellen wurde größer. natürlich gibt es auch heute noch die meisten dieser modelle, das streitet niemand ab. es geht ja nur darum zu zeigen, welche zusammenhänge es zwischen technischer innovation und projektorganisation gibt. weiterhin sei darauf verwiesen, welche enorme entwicklung die anwendungsbreite der it und die komplexität von programmen genommen haben. auch das beeinflusste die entwicklung der vogehensmodelle. by the way - dass immernoch an die 70% aller it projekte grandios scheitern bevor sie in die betaphase kommen liegt zu mindestens der hälfte an falschen entscheidungen über vorgehensmodelle. und 65% fehler in fertiger software deren ursachen in den requirements liegen sprechen auch bände, was sehr erheblich durch modelle wie den wasserfall begünstigt wird. agile projekte oder zyklische prozesse haben das problem weitaus seltener. zurück zur entwicklung. dassdie agilen techniken kamen liegt daran, dass die althergebrachten vorgehensmodele so weit überentwickelt und überreguliert standardisiert wurden, dass sie unhandlich, träge und viel zu teuer, nicht sehr zielführen, fehleranfällig und kaum korrigierbar wurden. daher auch "schwergewichtige" prozesse weil der aufwand für die verwaltung unproportional groß war. als die rechentechnik weniger entwicelt war, musste man diese verwaltung erfoinden - namentlich in den 60er und 70er jahren weil man auf grund der dauer der entwicklung und der maße an mühsamer handarbeit sehr detailliert standardisierte prozesse definieren musste um überhaupt was zu schaffen. das lag sehr an der hardware aber auch den sprachen und den entwurfsmethoden. heute reden wir über MDA, komponentenbasierten entwurf, über serviceorientierten entwurf und vernetzung (apropos - vernetzung war eine grundvoraussetzung für agility - ohne netz nix agile), dokuentationen werden zur hälfte automatisch generiert, ebenso programme und testszenarien, wir können automatisch testen und virtuelle testbetten simulieren, wir integrieren beim kunden während viele teile des systems noch mitten im entwurf stecken, wir pflegen online im hintergrund und admisitrieren per handy... das erzwingt durch das neue technische umfeld den einsatz von agilen methoden weil die marktentwicklung keine rein schwergewichtigen prozesse mehr duldet. man muss die time to market sehr kurz halten bei steigendem aspruch an das produkt, also verschlankung der prozesse - also agility. --HJG 11:04, 11. Apr 2005 (CEST)

Also nochmal zum exkurs. ich kann damit leben, wenn der erstmal rausgeht aus dem artikel und im interesse der klarheit überarbeitet wird und in der folge überlegen wir erneut, ob es sinn macht, das reinzusetzen oder nicht. damit würde die diskussion ebenso wie derartikel sicher gewinnen weil so wichtig ist mir der exkurs denn doch nicht. --HJG 18:28, 11. Apr 2005 (CEST)

Zusammenlegung von Agile Modeling + Agile Methode + Agiler Prozess?

Siehe Diskussion:Agiler Prozess --ChristianHujer 02:54, 11. Apr 2005 (CEST)

nicht zusammenlegen, aber aufeinander verweisen. ein lexikon muss begriffliche entwicklung zulassen und die einzelen führung der begriffe ist suchfeundlicher. --HJG 11:04, 11. Apr 2005 (CEST) Bitte darüber bei Diskussion:Agiler Prozess diskutieren - die Zusammenlegung betrifft alle Agile-Artikel, nicht nur diesen, es wäre unsinn, die Diskussion bei jedem Artikel einzeln zu führen.--ChristianHujer 11:40, 11. Apr 2005 (CEST)

Siehe Diskussion:Agile Softwareentwicklung--ChristianHujer 21:53, 22. Apr 2005 (CEST)

Löschen?

Ich bin aus folgenden Gründen für eine Löschung des Artikels:

• Der Artikel weist sehr viel Redundanz mit Agile Softwareentwicklung auf.
• Der Exkurs ist eine unnötige Ausschweifung.
• Der Artikel stellt Agile Modeling als einen konkreten Softwareentwicklungsprozess dar, zumindest in Bezug auf die Modellierung. Hier wird der allgemeine Oberbegriff Agile Modeling für Agile Modellierung im Allgemeinen mit einer konkreten namenlosen Agilen Modellierung gleichgesetzt.

Sollte niemand widersprechen, werde ich demnächst den Artikel löschen und einen Redirect daraus machen.

Weil ich mich nicht zwischen "Löschantrag" und "Doppeleintrag" entscheiden konnte - es ist von beidem etwas und doch keines so richtig - habe ich stattdessen Überarbeiten gewählt. --ChristianHujer 22:07, 22. Apr 2005 (CEST)

meinetwegen Exkurs raus, ist nicht wirklich wichtig (wie oben bereits angemerkt), den Rest in die agile sw-entwicklung übernehmen, den begrif des AM aber nicht löschen sondern redirect setzen. --HJG 19:42, 26. Jun 2005 (CEST)

zu viele stichpunkte und zu unneutral formuliert. das löschen des artikel sollte weiter in betracht bleiben. --Archiv 12:10, 9. Okt 2005 (CEST)