Moin, Ich programmiere immer mal wieder kleinere PC-Tools(Softwareprojekte) in C++Builder, die dann plötzlich größer werden als gedacht. Es ist oft ein Krampf im Nachhinein weitere Features einzubauen, wenn die dafür nötigen Programmstrukturen nicht berücksichtigt waren. Ich frage mich ob es hierzu nicht so etwas wie freie Software-Architektur-Templates gibt, die Grundlegende Features von Haus aus berücksichtigt haben. Also nicht nur die Gui, sondern auch die dahinter nötigen Strukturen für "übliche" Features. Was ich immer wieder mal bräuchte wäre z.B. ein MDI-Editor-Template wo Funktionen wie Undo/Redo berücksichtigt sind. Die Grundstruktur sollte verschiedenste Typen berücksichtigt haben... manchmal mache ich Text/Datenbasierte Tools, manchmal viel Grafisch ähnlich einem Bildeditor, manchmal gemischt... Für Undo/Redo ist also mehr nötig, als nur verschiedene Stände eines Texts wegzuspeichern. Als Beispiel...: Mal angenommen ich mache mir irgendein kleines Tool in C++Builder um Daten zu sortieren und zuzuordnen, wie es mit Excel o.ä. nicht so gut möglich wäre. Dazu braucht es ja nicht viel - vielleicht ein paar Buttons wie "Datei Öffnen, Datei Speichern, Daten Verarbeiten, ..." und eine Anzeige-Listbox für die Daten. Sowas ist schnell zusammengeclickt, mit Intelligenz gefüllt und sehr praktisch. Dann fängt das eigentliche Problem erst an - mit der Zeit kommen immer neue Ideen, was man auch noch einbauen könnte und je mehr das Tool kann, desto wichtiger wird es auch noch so Schnickschnack wie Undo/Redo zu haben, was ja normalerweise tief in die Programm & Datenstruktur eingreift. Manchmal kommen dann noch andere exotische Wünsche dazu, das kann man nie wissen. Ich kann mir prinzipell schon so eine Software-Architektur überlegen die das kann, aber um das wirklich gut und flexibel zu machen ginge viel Zeit udn Lehrgeld ins Land. Ich bin mir sicher, dass sich da schonmal jemand mehr und vielleicht auch bessere Gedanken gemacht hat und würde da lieber drauf aufbauen. Wer kennt freie Projekte in diese Richtung? Wer weiß wo es gute Infos gibt, die auf die Interne Softwarearchitektur solcher Programme (Editoren wie Texteditoren, Grafikeditoren, CAD-Systeme, ...) ausgerichtet sind? Und bevor jemand die Idee einwirft - nein, Projektplanung im Voraus für die Tools ist leider ausgeschlossen! Es ist ja immer nur ein kleines Tool, für das nicht viel Zeit zur Verfügung steht und eh selten gebraucht wird... schönen Gruß, Alex
Eine SW-Architektur gibt es nicht von der Stange. Was es aber gibt sind PATTERN. Die sind genau dafür da, um gleiche Probleme auf die gleiche Art zu lösen. Trotzdem können die nicht fertig in Code gegossen sein, weil die immer auf die konkrete Anwendung passen müssen. Allein dein Undo/Redo Beispiel hängt doch in größtem Maße von den Daten ab. Handelt es sich um Text oder Vektorgrafik oder einen Audioeditor. Da gibts doch keine Datenstruktur die für alles passt. Was du aber siehst, auch ein "kleines Tool", welches gut wartbar und erweiterbar sein soll, benötigt eine saubere Architektur und ist im Endeffekt aufwändig. "Mal schnell" wird immer mit einbußen erkauft. Da gibt es leider keine Abkürzung. Eventuell solltest du mal von deinem C++Builder weg zu etwas modererem wie C# inkl. Visual Studio. In den Libs dort sind natürlich auch schon viele viele Standardfunktionalitäten verborgen so dass man nicht mehr alles selbst tun muss.
:
Bearbeitet durch User
Alex schrieb: > Ich programmiere immer mal wieder kleinere PC-Tools(Softwareprojekte) in > C++Builder, die dann plötzlich größer werden als gedacht. > Es ist oft ein Krampf im Nachhinein weitere Features einzubauen, wenn > die dafür nötigen Programmstrukturen nicht berücksichtigt waren. Ja, das ist in der Entwicklung ein ständiges Problem. Genannt auch "schleichender Featurismus" ( http://www.catb.org/jargon/html/C/creeping-featurism.html ). Wenn ein Feature unbedingt noch rein soll, muss man dann halt ggf. viel Code neuschreiben oder umstrukturieren. Alex schrieb: > Ich frage mich ob es hierzu nicht so etwas wie freie > Software-Architektur-Templates gibt, die Grundlegende Features von Haus > aus berücksichtigt haben. Mag schon sein - die stehen aber absehbar vor dem selben Problem, wenn dann mal etwas gebraucht wird, was kein "grundlegendes Feature" war. Und tendenziell wird es dort dann noch ein wenig aufwändiger, die Neuerung mit den 80% an "grundlegenden Features" im Framework unter einen Hut zu kriegen, die man gerade nicht gebraucht hat. Aber Vorsicht: Ich denke recht negativ, was Softwareentwicklung betrifft. Wir sind am Ars*h. Alex schrieb: > Was ich immer wieder mal bräuchte wäre z.B. ein MDI-Editor-Template wo > Funktionen wie Undo/Redo berücksichtigt sind. Die Grundstruktur sollte > verschiedenste Typen berücksichtigt haben... manchmal mache ich > Text/Datenbasierte Tools, manchmal viel Grafisch ähnlich einem > Bildeditor, manchmal gemischt... Für Undo/Redo ist also mehr nötig, als > nur verschiedene Stände eines Texts wegzuspeichern. Ohne jetzt zu wissen, worauf du anspielen willst: Event Sourcing wäre da zB ein Stichwort zum Googlen. Zu solchen Mustern kann man sich entscheiden oder auch nicht: Nachträglich ist sowas nicht mehr einzubauen. Wenn man es nicht braucht, hat man eine unnötig komplexe, schwer zu debuggende Programmarchitektur umsonst zusammen mit jeder Menge Glue-Code. Juchhe! Um Planung wirst du nicht herum kommen... Alex schrieb: > Als Beispiel...: > Mal angenommen ich mache mir irgendein kleines Tool in C++Builder um > Daten zu sortieren und zuzuordnen, wie es mit Excel o.ä. nicht so gut > möglich wäre. > Dazu braucht es ja nicht viel - vielleicht ein paar Buttons wie "Datei > Öffnen, Datei Speichern, Daten Verarbeiten, ..." und eine > Anzeige-Listbox für die Daten. Da hätte ich jetzt eher an ein Plugin für Excel o.Ä. gedacht. Wäre im Workflow um einiges angenehmer. Ist dann natürlich nur eine Lösung für die eine bestimmte Umgebung. Aber dafür eine brauchbare.
:
Bearbeitet durch User
Das Henne-Ei Problem lässt sich nicht vermeiden. Erst nachdem die Software real eingesetzt wird, lässt sich die Struktur ausarbeiten. Zu diesem Thema gibt es nur 2 brauchbare Leitfäden. Frederick Brooks, The Mythical Man-Month und Eric Raymond, The Cathedral and the Bazaar. Brooks kam zu der Erkenntnis: "plan to throw one away; you will, anyhow." Und Raymond erklärt, wie das in der Praxis funktioniert.
Alex schrieb: > kleinere PC-Tools(Softwareprojekte) in > C++Builder Der C-Builder bringt doch eigentlich etliche Komponenten für Editoren mit. Sich eine Buttonliste Basteln und diese mit den entsprechenden Funktionsaufrufen verknüpfen ist eine Arbeit von weniger als einer Minute.
1 | void Form1::Button1Click(...) |
2 | {
|
3 | RichEdit1->Undo(); |
4 | }
|
Softwarearchitektur ist was ganz anderes...
Moin, Danke schon mal für die Rückmeldungen! Cyblord -. schrieb: > Eine SW-Architektur gibt es nicht von der Stange. Was es aber gibt sind > PATTERN. Die sind genau dafür da, um gleiche Probleme auf die gleiche > Art zu lösen. > Trotzdem können die nicht fertig in Code gegossen sein, weil die immer > auf die konkrete Anwendung passen müssen. Klar gibt es nicht eine perfekt passende Vorlage für alle meine Probleme. Mein wunsch wäre eher aus einer Menge an Vorlagen die am besten passenste zu nehmen, meine Funktionen dort einzubauen und von dem Standpunkt aus dann weiter zu machen. Cyblord -. schrieb: > Allein dein Undo/Redo Beispiel hängt doch in größtem Maße von den Daten > ab. Handelt es sich um Text oder Vektorgrafik oder einen Audioeditor. > Da gibts doch keine Datenstruktur die für alles passt. Deswegen hoffe ich ja, dass sich schonmal jemand schlaueres als ich darüber Gedanken gemacht hat und eine gute Allgemein nützliche Methode gefunden hat. Die komplexesten Programme die mir so einfallen sind CAD-Editoren - die haben jetzt nicht unbedingt mehr Grund-Features für den Editor, aber die Struktur ermöglicht trotzdem alles mögliche wie Text, Grafik, Daten. Sich in die ganzen Pattern einzulesen und funktionsfähig zu implementieren, dass die auch zusammenspielen ist ja auch nicht wenig Arbeit und ich hoffe da einfach auf Wiederverwendbarkeit etwas bestehenden... Cyblord -. schrieb: > Eventuell solltest du mal von deinem C++Builder weg zu etwas modererem > wie C# inkl. Visual Studio. Habe ich mir vor ~15 Jahren zum ersten Mal angesehen, aber für meine Anwendungen überwiegen einfach die Vorteile vom C++Builder... möchte ich jetzt nicht weiter drauf eingehen. Heiko L. schrieb: > Mag schon sein - die stehen aber absehbar vor dem selben Problem, wenn > dann mal etwas gebraucht wird, was kein "grundlegendes Feature" war. Und > tendenziell wird es dort dann noch ein wenig aufwändiger, die Neuerung > mit den 80% an "grundlegenden Features" im Framework unter einen Hut zu > kriegen, die man gerade nicht gebraucht hat. Aber Vorsicht: Ich denke > recht negativ, was Softwareentwicklung betrifft. Wir sind am Ars*h. Bin da auch eher Pessimist (erfahrener Realist). Springender Punkt bei meinem Problem ist denke ich, dass es nur ein Tool bleiben darf, wo es ruhig Grenzen geben darf. Bei den Grund-Features die so ein Template mitbringen würde, würde ich dann auch bleiben. Dann hätte ich evtl. schon mehr als ich jetzt habe, denn dann würde ich wenigstens mit den Features starten und diese nicht erst nach Jahren des Jammerns mal einbauen. Heiko L. schrieb: > Event Sourcing wäre da zB ein Stichwort zum Googlen. Ja, danke - in die Richtung soll es gehen. Ich stehe jetzt halt vor der Entscheidung solche Dinge im Nachhinein einzubauen oder mein Projekt gleich auf eine Version 2.0 in irgendein Template einzubauen. Heiko L. schrieb: > Da hätte ich jetzt eher an ein Plugin für Excel o.Ä. gedacht. Wäre im > Workflow um einiges angenehmer. Ist dann natürlich nur eine Lösung für > die eine bestimmte Umgebung. Aber dafür eine brauchbare. Excel ist keine Option, da ich auch viel Grafisch (mit Bildbearbeitung o.ä.) mache... oft startet es primitiv mit Zahlen und wenn das Tool sich als brauchbar erweist wird es durch komplexere Grafiken & Anzeigen erweitert. Da ist Excel das falsche Pferd. Sisyphusarbeit schrieb: > Brooks kam zu der Erkenntnis: "plan to throw one away; you will, > anyhow." Und Raymond erklärt, wie das in der Praxis funktioniert. Brooks ist echt gut :). Hatte nur immer mal wieder die Zusammenfassung gelesen - er hat leider viel zu oft recht. Ändert leider nur nicht viel an der gängigen Praxis ;). Irgendwer schrieb: > Sich eine Buttonliste Basteln und diese mit den entsprechenden > Funktionsaufrufen verknüpfen ist eine Arbeit von weniger als einer > Minute.void Form1::Button1Click(...) > { > RichEdit1->Undo(); > } > > Softwarearchitektur ist was ganz anderes... Da sind meine Programme leider schon vielfach komplexer... Funktion ist von Gui getrennt und die Undo-Methode einzelner Vcl Komponenten bringt mir leider nichts. schönen Gruß, Alex
Alex schrieb: > Bei den Grund-Features die so ein Template > mitbringen würde, würde ich dann auch bleiben. Ja, welche wären das denn? Wenn du dir diese Frage klar beantworten kannst, dürften sich viele Probleme schon von selbst gelöst haben. Und die Wahl an potentiellen Templates hätte brauchbare Kriterien. Alex schrieb: > Excel ist keine Option, da ich auch viel Grafisch (mit Bildbearbeitung > o.ä.) mache... oft startet es primitiv mit Zahlen und wenn das Tool sich > als brauchbar erweist wird es durch komplexere Grafiken & Anzeigen > erweitert. Da ist Excel das falsche Pferd. Das war dein Beispiel. Grundsätzlich kann ich sonst nur Cyblord beipflichten: Es wird ziemlich dünn, wenn du einfach nur Undo/Redo haben willst. Du müsstest schon wissen, welche Features du brauchst - sonst nützt dir auch ein App-Template nichts. PS: Alex schrieb: > Da sind meine Programme leider schon vielfach komplexer... Funktion ist > von Gui getrennt und die Undo-Methode einzelner Vcl Komponenten bringt > mir leider nichts. Eben wegen solchen Sachen.
:
Bearbeitet durch User
> Ändert leider nur nicht viel an der gängigen Praxis ;) Tja, die modernen Softwareentwicklungsmethoden sind ein Rückschritt. Ausgerechnet die drei wichtigsten Punkte ignorieren die modernen Methoden. - Nachdem die Hälfte implementiert ist, fällt auf: Ein anderer Ansatz ergäbe nur 1/10 des Aufwandes - Nach ein paar Jahren haben sich so viele zusätzliche Anforderungen angesammelt, die ursprünglichen Designentscheidungen passen einfach nicht mehr - Die Dokumentation ist ein genau so wirres Chaos, wie der Programmcode. Wahrscheinlich braucht man da eine ganz andere Denkweise. Das wirklich wertvolle ist die Dokumentation der Erfahrungen. Historisch gewachsener Programmcode hat weniger als gar keinen Wert. Das zentrale Ziel sollte eine konsistente, übersichtliche Dokumentation sein, aus der sich jederzeit eine neue, funktionierende Architektur entwickeln lässt. > dass sich da schonmal jemand mehr Gedanken gemacht hat Na klar, James Watt, Thomas Edison, Werner Siemens… Aber die kamen zu der Lösung: Für Erfindung, Konstruktion, Begutachtung, Leitung, Produktion und Qualitätssicherung braucht es unterschiedliche Charaktere, unterschiedliche Organisation und unterschiedliche Ausbildung. In der Softwareentwicklung sammeln sich halt diejenigen, die mit dieser Lösung nicht einverstanden sind. Oder kennst du einen Kodierer, der einen Fließbandjob machen würde? Oder einen Entwickler, der sich auf die Konstruktion von Datenstrukturen beschränken will?
Heiko L. schrieb: > Alex schrieb: >> [...] >> Es ist oft ein Krampf im Nachhinein weitere Features einzubauen, wenn >> die dafür nötigen Programmstrukturen nicht berücksichtigt waren. > > Ja, das ist in der Entwicklung ein ständiges Problem. Genannt auch > "schleichender Featurismus" ( > http://www.catb.org/jargon/html/C/creeping-featurism.html ). Wenn ein > Feature unbedingt noch rein soll, muss man dann halt ggf. viel Code > neuschreiben oder umstrukturieren. > > Alex schrieb: >> Ich frage mich ob es hierzu nicht so etwas wie freie >> Software-Architektur-Templates gibt, die Grundlegende Features von Haus >> aus berücksichtigt haben. > > Mag schon sein - die stehen aber absehbar vor dem selben Problem, wenn > dann mal etwas gebraucht wird, was kein "grundlegendes Feature" war. Und > tendenziell wird es dort dann noch ein wenig aufwändiger, die Neuerung > mit den 80% an "grundlegenden Features" im Framework unter einen Hut zu > kriegen, die man gerade nicht gebraucht hat. [...] > [...] >> [...] Interessant fände ich, begründete Bewertungen von Methoden wie "Agile Softwareentwicklung" (im folgenden mit ASE abgekürzt) und ähnlichen Ansätzen im Kontrast zu den oben erwähnten Problemen. Es scheint mir insgesamt so zu sein, dass der Prozess der Anforderungsdefinition bei ASE effektiv ein Teil des Auftrags wird. Mehr nicht. Ein Old-School-Entwickler (mal ganz wertfrei gemeint) wird eine komplette Anforderungsspezifikation voraussetzen bevor er ein Angebot macht und mit der Arbeit beginnt. In den letzten Jahren (bis Jahrzehnten) aber verstärkt sich der Anteil an Auftraggebern, die mit sehr unscharfen Anforderungen Projekte anstossen wollen - da ist ASE sozusagen das Gegenmittel, gegen das Verlangen nach der kostenlosen Anforderungsanalyse und Angebotserstellung. Der Auftraggeber mag ASE hingegen so sehen, dass er vor allem schnelle Umsetzungen seiner (in welchem Maß auch immer unscharfen) Vorstellungen bekommt und in gewisser Weise eine Art Mikromanagement betreibt ohne das das ausdrücklich so benannt wird. So kann man das sehen, denke ich, oder was meint Ihr? Mag dazu jemand was sagen?
Alter Wein in neuen Schläuchen. Früher waren auch niemandem die Anforderungen klar. Früher hatten die Old-School-Entwickler auch einen Prototypen zusammen gekloppt. Ist damals genauso im Chaos versunken wie die agile Software. Das Problem an der Agilen Softwareentwicklung - sobald die Anforderungen klar sind, muss man den konfusen Prototypen wegwerfen und eine sinnvolle Architektur ausarbeiten. Das dauert halt 6 Monate. Diese Agilen Consultingfirmen sind Scharlatane. Die erzählen den Managern, sie könnten diese 6 Monate einsparen, sie bräuchten nur deren teuren agilen Schulungen buchen. PS. Selbst die blindesten BWLer haben inzwischen gemerkt - Agile Softwareentwicklung wird ein Fass ohne Boden. Und was machen diese Scharlatane? Die erzählen den BWLern, sie müssten nur teure Schulungen zum Thema Mikroservices buchen.
Alex schrieb: > Ich programmiere immer mal wieder kleinere PC-Tools(Softwareprojekte) in > C++Builder, die dann plötzlich größer werden als gedacht. Poste doch erstmal ein paar Beispiele deiner Sourcen...
Ich hatte früher auch sehr oft das Problem mit dem schleichenden Featurismus (ich glaube euch einfach mal, dass das Wort echt ist). Ich habe sehr sehr gute Erfahrungen mit strenger Modularisierung gemacht. Mein Ziel ist immer, dass ein Modul einen ganz klar abgegrenzten Aufgabenbereich hat. Ein Modul ist quasi immer ein Feature, oft auch mit Sub-Modulen. Mein Vorbild war damals der Editor Atom mit seinen Packages. Ein Package ist dort ein sehr autarkes Modul, ich habe das noch etwas mehr auf die Spitze getrieben. Oft nimmt das sogar schon API-Ähnliche Züge an. Ich habe meistens ein größeres Feature, bspw. für die Toolbar, die dann Methoden hat wie addButton(), oft hat die Toolbar-Klasse dann sogar noch ein Sub-Module, bspw. Button. Ich habe damit wirklich sehr gute Erfahrungen gemacht und kann es wirklich jedem empfehlen.
Was ich noch vergessen habe: Ich unterscheide zwischen zwei Arten von Modulen, die APIs (z.B. Toolbar) und die Module, die den Atom-Packages ähneln. Das Programm soll auch dann noch laufen, wenn so ein Modul weggenommen wird, auf dieses Modul wird nicht wirklich zugegriffen, höchstens am Anfang initiiert. So ein Package arbeitet für sich und greift nur auf API-Klassen zu, nicht aber auf andere Packages (außer Sub-Packages). Die Packages greifen auf die unverzichtbaren API-Klassen zu, die kann man natürlich nicht einfach wegnehmen.
Theor schrieb: > Es scheint mir insgesamt so zu sein, dass der Prozess der > Anforderungsdefinition bei ASE effektiv ein Teil des Auftrags wird. Mehr > nicht. > ... > Mag dazu jemand was sagen? Ja. Iterative Verfahren sind immer die Notlösung, wenn man das gewünschte Resultat nicht a-priori bestimmen kann. Dem tragen ja offenbar auch einige Prozess-Adaptionen zB beim Wasserfallmodell Rechnung: Der Unterschied besteht im Grunde nur noch darin, ob man die Iterationen vertikal oder horizontal orientiert aufmalt. Es schreit einem nur so entgegen: Du könntest versuchen irgendetwas lückenlos zu durchdenken und würdest mit absoluter Gewissheit scheitern. Die Hybris menschlichen Geistes. Die Mathematik liefert das Paradebeispiel einer jahrtausende lange Geschichte des Scheiterns an noch den simpelsten logischen Formen. Der Zahlbegriff, Kantors Mengenlehre, das Hilbert-Programm - um nur einige zu nennen. Wir stehen ideengeschichtlich nicht in der Moderne. Wir haben gelernt, dass alles, wenn überhaupt, nur "irgendwie" wahr ist. Den Ideen nur mutmaßlich, in Bezug auf einen Kontext, Realität zukommt. Softwareentwicklung ist der Versuch, einen Marathon zu laufen, obwohl klar ist, dass man sich schon nach zwei, drei Schritten auf die Schn*uze legen wird. "Agil" sagt quasi "Wir schauen dann mal weiter". Uneingeschränkt besser für den Kunden wird es dadurch nicht: "Die Freiheit von der eigenen Vergangenheit wird mit Unterordnung unter das unmittelbar Vorfindliche erkauft." Wo zur Verbesserung angesetzt wird, weiß sogar Wikipedia "ständiges Refactoring" als Merkmal agiler Entwicklung anzugeben - umsonst ist sowas nicht. Es trägt der Unfähigkeit Rechnung, sich bei einer Begriffsentwicklung nicht schon nach zwei Sätzen in Widersprüche zu verwickeln und - aus Not getrieben - die beiden Sätze restlos auszutilgen, bis vom Begriff nur noch eine leere Worthülse übrig bleibt, die im dialektischen Hin- und Her eben nur genau das besagt, was jemand meint - in feiner Abgrenzung zu dem, was er denn sagt. Verstehen ist also groß in Mode: Der Kunde ist in aller Regel unmündig, hat keine Ahnung, was er will und ist zu positiv-transzendenter Setzung einer Idee unfähig: eine Anforderungsdefinition verstünde er in ihrer Folge nicht.
> Der Kunde ist in aller Regel unmündig, hat keine Ahnung, was er will
"Wenn ich die Menschen gefragt hätte was sie wollen, hätten sie gesagt,
schnellere Pferde." – Henry Ford
Wir haben seit 100 Jahren ein iteratives Verfahren, in dem das Automobil
ständig verändert wird. Warum eigentlich? Wieso braucht Fords Lösung
seit 100 Jahren ein ständiges Refactoring?
Hat Henry Ford doch nicht verstanden, was sein Kunde will? War Ford
nicht in der Lage die Wünsche seiner Kunden umzusetzen? Hat Fords Lösung
die Wünsche seiner Kunden verändert?
Gibt es überhaupt irgend einen Bereich, in dem wir Menschen oder die
Evolution oder die Götter oder sonst wer kein ständiges Refactoring
betreiben? Wie kann sich ein Produkt der Evolution aus dem ständigen
Refactoring befreien. Und wieso wollen wir ausgerechnet in der
Softwareentwicklung das ständige Refactoring vermeiden?
Sisyphusarbeit schrieb: > Gibt es überhaupt irgend einen Bereich, in dem wir Menschen oder die > Evolution oder die Götter oder sonst wer kein ständiges Refactoring > betreiben? Wie kann sich ein Produkt der Evolution aus dem ständigen > Refactoring befreien. Und wieso wollen wir ausgerechnet in der > Softwareentwicklung das ständige Refactoring vermeiden? Eine interessante Idee wäre ein Tool, welches einfach jeden Tag 1-2 Dateien, Module oder gar Projekte - zufällig ausgewählt - aus dem GIT löscht. Artificial Evolution: Was gut war, wird ähnlich noch einmal neu geschrieben werden. Fortschritt kennt nur ein Gesetz, welches das der Negation ist. Leider ist die Mutationsrate bei angewandten genetischen Algorithmen nicht infinit.
Theor schrieb: > Interessant fände ich, begründete Bewertungen von > Methoden wie "Agile Softwareentwicklung" (im > folgenden mit ASE abgekürzt) und ähnlichen Ansätzen > im Kontrast zu den oben erwähnten Problemen. Agile Methoden sind in kundigen Händen eine gute Sache; allerdings haben sie auch eigene Gefahren. > Es scheint mir insgesamt so zu sein, dass der Prozess > der Anforderungsdefinition bei ASE effektiv ein Teil > des Auftrags wird. Mehr nicht. Herrlich. "Der Beweis von Andrew Wiles ist lediglich die Arbeit eines Mathematikprofessors, in der der Fermatsche Satz bewiesen wird. Mehr nicht." :) > Ein Old-School-Entwickler (mal ganz wertfrei gemeint) > wird eine komplette Anforderungsspezifikation > voraussetzen bevor er ein Angebot macht und mit der > Arbeit beginnt. Ja. > In den letzten Jahren (bis Jahrzehnten) aber verstärkt > sich der Anteil an Auftraggebern, die mit sehr unscharfen > Anforderungen Projekte anstossen wollen - da ist ASE > sozusagen das Gegenmittel, gegen das Verlangen nach der > kostenlosen Anforderungsanalyse und Angebotserstellung. Kann man so sehen, ja. > Der Auftraggeber mag ASE hingegen so sehen, dass er vor > allem schnelle Umsetzungen seiner (in welchem Maß auch > immer unscharfen) Vorstellungen bekommt und in gewisser > Weise eine Art Mikromanagement betreibt ohne das das > ausdrücklich so benannt wird. > So kann man das sehen, denke ich, oder was meint Ihr? Das ist, denke ich, nicht falsch, greift aber zu kurz. Der Kernpunkt sind die "unscharfen Vorstellungen" von den Anforderungen. Software dient einem Zweck; die meiste Software ist in einen übergreifenden Arbeitsprozess eingebunden. Der Arbeitsprozess und die Software sind aufeinander abgestimmt. Neue, verbesserte Software erfordert in der Regel auch einen neuen Arbeitsprozess, der auf genau diese neue Software abgestimmt ist. Diesen Arbeitsprozess KANN der Auftraggeber aber noch gar nicht kennen, weil es ja die zugehörige Software noch gar nicht gibt! Das ist ein grundlegendes Henne-Ei-Problem. Alle Klein- geister, die die Auftraggeber grundsätzlich für dumm, faul und inkompetent halten, übersehen, dass sie Dinge vom Auftraggeber wissen wollen, die er PRINZIPBEDINGT noch nicht wissen KANN. Agile Methoden sind hier mMn kein ganz falscher Ansatz, weil sie die 1. gemeinsame 2. schrittweise Erarbeitung von Produktwissen in den Vordergrund stellen.
Sisyphusarbeit schrieb: > Wir haben seit 100 Jahren ein iteratives Verfahren, > in dem das Automobil ständig verändert wird. Warum > eigentlich? Weil Firmen, die nichts verkaufen, weil alle alten Bedürfnisse befriedigt und keine neuen geweckt wurden, Pleite gehen, und weil Staaten, in denen die Firmen reihenweise pleite gehen, keine Steuern einnehmen und auch Pleite gehen. Echte Notwendigkeiten spielen nur indirekt eine Rolle.
Egon D. schrieb: > Agile Methoden sind hier mMn kein ganz falscher Ansatz, > weil sie die > 1. gemeinsame > 2. schrittweise > Erarbeitung von Produktwissen in den Vordergrund stellen. "Produktwissen" - ich musste es nachschlagen
1 | |
2 | Produktwissen |
3 | ist die Menge der im Gedächtnis gespeicherten Informationen (interner „Informationsstock“), die eine Produktgruppe betreffen (Informationsverhalten). Dazu gehören Kenntnisse über die relevanten Marken (Evoked Set), die Eigenschaften dieser Marken und die Bedeutung von Produkteigenschaften. Produktwissen wird durch die Informationsbeschaffung und -Verarbeitung sowie durch direkte Erfahrungen mit Produkten erworben. Die Wirkungen des Produktwissens auf das Informationsverhalten von Konsumenten sind uneinheitlich. Einerseits kann ein eher niedriger Informationsstand zu relativ starker Informationsnachfrage bei bestimmten Kaufentscheidungen führen, andererseits führt die Vertrautheit mit einer Produktgruppe zu besseren Fähigkeiten, größere diesbezügliche Informationsmengen verarbeiten zu können. |
http://www.wirtschaftslexikon24.com/e/produktwissen/produktwissen.htm
Moin, Gab hier über Nacht ja einige philosopische Ergüsse - bringt aber keinen weiter. Tomas T. schrieb: > Poste doch erstmal ein paar Beispiele deiner Sourcen... Das geht nicht weil es Firmeneigentum ist. USB H. schrieb: > Ich habe sehr sehr gute Erfahrungen mit strenger Modularisierung gemacht. > Mein Ziel ist immer, dass ein Modul einen ganz klar abgegrenzten > Aufgabenbereich hat. Ein Modul ist quasi immer ein Feature, oft auch mit > Sub-Modulen. Meinen Code versuche ich natürlich auch modular zu halten aber so wirklich streng bin ich da nicht. Ist sicher eines der Probleme ;). Ich kenne den Atom Editor jetzt nicht genauer. Kannst du das evtl. mal als kleines Pseudocode-Beispiel zeigen wie die Klassen dann zusammenhängen oder so? schönen Gruß, Alex
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.