Sonntag, 29. Dezember 2013

Software durch Menschenhand schaffen – ein Wunsch am Jahresende.

These: Menschen die sich wohl fühlen, Menschen die geachtet werden schaffen beachtliche Software.

Könnte man kleine Teams bilden, bestehend aus 3 bis 4 Entwicklern und Entwicklerinnen? Könnten sich diese kleinen Teams zu größeren Teams zusammensetzen? Zuerst zu Doppelteams, dann zu immer größeren Einheiten? Könnte sich eine Organisation von unten nach oben etablieren, je nach den Erfordernissen der Wirklichkeit?

Dienstag, 24. Dezember 2013

Der Kunde ist für die systematische Erarbeitung der Kundenanforderungen zuständig

Gute Software benötigt gute fachliche Anforderungen.

Bevor ich meinen Artikel starte, möchte ich Ihnen ein frohes und besinnliches Weihnachtsfest im Kreis Ihrer Liebsten wünschen. Vielleicht kann man einige Wünsche an das menschliche Miteinander, die man in das Weihnachtsfest projiziert, lieber auf das ganze Jahr verteilen, um so diese wenigen Tage nicht zu überlasten. Unsere Branche wurde dadurch nicht ärmer werden. Doch jetzt zu meinem Weihnachtswunsch.

Donnerstag, 19. Dezember 2013

Ein hierarchisches System von Kontextobjekten

Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil Der Ideenraum.
3. Teil Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil Ein hierarchisches System von Kontextobjekten.
6. Teil Die Geschichten der Benutzer - User Stories erstellen.
7. Teil Die Analyse des Problemraums führt zum Zielmodell.
8. Teil Wie User Stories Use Cases gebären.
9. Teil Szenarien setzen sich zu Use Cases zusammen.
10. Teil Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil Die Vielfalt der Szenarien.
13. Teil Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil Ohne Abnahmekriterien läuft nichts.
15. Teil Startschuss zur testgetriebenen Entwicklung.


Im letzten Artikel habe ich beschrieben, warum für Themenobjekte eine Systemkontextuntersuchung durchgeführt werden muss. Eigentlich wollte ich in diesem Post das Erstellen von User Stories beschreiben. Damit müssen wir jedoch noch einen Post warten, weil ich beim Reflektieren des Verhältnisses zwischen Kontextobjekt und inhärenten Unterobjekten Abhängigkeiten gefunden habe, die noch nicht beschrieben sind. Im Artikel Ordnung für Dokumente habe ich den Unterschied zwischen Quelldokumenten und Dokumenten, die gewonnene Informationen enthalten, beschrieben. Diese Formen der Dokumente stehen in einem engen Zusammenhang. Die gewonnene Information wird aus dem Quelldokument ermittelt.

Samstag, 14. Dezember 2013

Softwareentwurf ist ein organisierter Kreislauf

Prozessübersicht Softwareentwicklung

Artikelübersicht
1. Teil Missing Links im Modell.
2. Teil Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung?
3. Teil Entwurf und Bauen von Software – eine falsche Vorstellung.
4. Teil Softwareentwurf ist ein organisierter Kreislauf.
5. Teil In Softwareprojekten gibt es viel zu entdecken!
6. Teil Die Interaktion mit dem Kontext ist ein wesentlicher Grund für den Erfolg eines Softwareprojektes.
7. Teil Das unentdeckte Land oder wo noch nie ein Mensch gewesen.
8. Teil Mit schlanken Methoden zu gewollter Software.
9. Teil Die Flexibilität des Vorgehens schenkt laufende Verbesserungen.
10. Teil Vom Problem seiner Rolle gerecht zu werden.
11. Teil Wir gründen eine virtuelle Firma.
12. Teil Warum ist unsere virtuelle Firma nur ein Torso?
13. Teil Eine Arbeitsvorlage, ein strategisches Team und ein tolles Geschäft.
14. Teil Ein fortgesetztes tolles Geschäft.


In einem Kommentar zum letzte Post wurde ich darauf hingewiesen, dass es nicht nur den Rücksprung zum Requirements Engineering geben darf. Wir können natürlich in jede Phase zurückspringen, in das Requirements Engineering genauso wie in die Softwarearchitektur oder die Implementierung. Nur ein sich ewiges Wiederholen des Bauens würde sich mir nicht erschließen. Auch können die Phasen verschieden lange dauern. Des weiteren kann es durchaus sein, dass verschiedene Teile des Teams oder Einzelleistungen in den Phasen gefragt sind. Eines muss jedoch klar sein: In welcher Phase befinde ich mich gerade? Die Vermischung der Phasen führt zu einer Vermischung des WAS mit dem WIE oder auch dem WIE im Großen (die Softwarearchitektur) mit dem WIE im Kleinen (das Softwaredesign, die Implementierung). Da kann es schon mal vorkommen, dass aus einem User Interface (einer Lösung, also ein WIE) Anforderungen abgeleitet werden (also das WAS). Das kann in ein und demselben Augenblick passieren.

Montag, 9. Dezember 2013

Data Transfer Objects – ein Antipattern?

Praktisches Beipiel 2.2.3

Artikelübersicht
1. Teil Das Data Transfer Object – Be or not to be.
2. Teil Java Beans und Use Cases.
3. Teil Data Transfer Objects – ein Antipattern?


In einer Anwendung treffen wir oft eine Trennung zwischen der Geschäftslogik und der Präsentation an. Die Präsentation greift auf die Geschäftslogik über definierte Schnittstellen zu. Diese definierte Schnittstelle können wir als Fassade implementieren. In der Fassade stellt die Businessschicht Zugriffsmethoden auf die Geschäftslogik bereit.

Mittwoch, 4. Dezember 2013

Wer kennt die Wahrheit der Entwickelung optimaler Software?

Allgemeines

Ich habe es mir zur Tradition gemacht den ersten Post des Monats für das Nachdenken über mein Tun zu nutzen und über Dinge, die mir bei meinem Tun begegnet sind. Kommentatoren zum Artikel Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung hatten mir empfohlen, mich mit dem Buch "Software entwickeln mit Verstand" [DIER11] zu beschäftigen. Nachdem ich es gelesen habe, kann ich es zum Lesen und Reflektieren nur empfehlen. Es wird auf alle Fälle Einfluss haben auf nachfolgend erscheinende Artikel. Einer schwebt mir ganz fest im Kopf vor. Die Autoren stellen die Erstellung von Software als Wissensarbeit dar, bei der es eine dialektische Barriere zu überwinden gilt. "Eine dialektische Barriere liegt dann vor, wenn sowohl der Ausgangszustand, der Zielzustand als auch die Lösungsschritte ganz oder zumindest teilweise unbekannt sind." [S.30 DIER11] Was heißt es für den Einzelnen, für das Team und für die Interaktion mit der Umgebung, diese Barriere zu überwinden? Dazu finden sich eine Fülle von Ansätzen in diesem Buch.

Freitag, 29. November 2013

Ordnung für Dokumente

These: Systemkontextanalyse öffnet die Augen für optimale Software

Artikelübersicht
1. Teil Ordnung für Dokumente.
2. Teil Im Zoo der Dokumente.


Was ist ein Dokument? In der ISO-9000-Unterstützungsanleitungen findet sich folgender Satz: "Hervorzuheben ist, dass Dokumente laut ISO 9001:2000 Abschnitt 4.2 Dokumentationsanforderungen eine beliebige Form haben beziehungsweise sich auf einem beliebigen Medium befinden können." Daraus können wir ableiten, dass wir Information auf einem Medium erfassen. Es schließt sich die Frage an: Warum erfassen wir diese Information? Ebenfalls in dem oben erwähnten Text finden sich die drei Stichpunkte "Vermittlung von Informationen", "Nachweis der Konformität" und "Wissensaustausch". Unter Konformität verstehe ich in diesem Zusammenhang die Übereinstimmung des Dokuments mit einer bestimmten Norm. Bleibt am Ende die Frage: Welches Medium eignet sich am besten um die erfasste Information abzulegen? Das kann Papier , ein Wiki, eine Textdatei in einem Filesystem oder der Inhalt einer Datenbank sein. Bleibt festzuhalten: Ein Dokument ist Information auf einem Medium.

Sonntag, 24. November 2013

Themen müssen einer Systemkontextanalyse unterzogen werden.

Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil Der Ideenraum.
3. Teil Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil Ein hierarchisches System von Kontextobjekten.
6. Teil Die Geschichten der Benutzer - User Stories erstellen.
7. Teil Die Analyse des Problemraums führt zum Zielmodell.
8. Teil Wie User Stories Use Cases gebären.
9. Teil Szenarien setzen sich zu Use Cases zusammen.
10. Teil Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil Die Vielfalt der Szenarien.
13. Teil Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil Ohne Abnahmekriterien läuft nichts.
15. Teil Startschuss zur testgetriebenen Entwicklung.


Wie im letzten Post angedeutet, wird für ein Themenobjekt, wenn es denn finalisiert und beauftragt wurde, vom Product Owner für den Requirements Engineer eine Aufgabe erzeugt (create). Diese Aufgabe beinhaltet die Untersuchung des Systemkontextes in Bezug auf das entsprechende Themenobjekt. Die Grundlagen der Systemkontextanalyse habe ich in einer kleinen Artikelreihe bereits beschrieben. Die ersten beiden Post dieser Reihe klären die Grundfragen: Was ist der Systemkontext? und Warum und wie sollte der Systemkontext erfasst werden?. Im Post Welche Arten von Kontextobjekten gibt es? werden die zu findenden Kontextobjekte aufgezählt. Außerdem habe ich zusätzlich ein Modell zur Visualisierung von Stakeholdern und deren Beziehungen vorgestellt. (Kontextaspekt Stakeholder., Nutzerrollen, Personas und extreme Charaktere., Organisationsstrukturen.) In den nächsten Monaten werde ich auch für die anderen Kontextobjektarten Modelle bzw. Dokumentationsformen vorschlagen.

Dienstag, 19. November 2013

Java Beans und Use Cases

Praktisches Beispiel 2.2.2

Artikelübersicht
1. Teil Das Data Transfer Object – Be or not to be.
2. Teil Java Beans und Use Cases.
3. Teil Data Transfer Objects - ein Antipattern?


Im letzten Teil dieser Reihe hatte ich ein Beispiel angekündigt, in dem die Businessobjekte in JavaBeans und UseCase-Objekte getrennt wurden. Dabei sind die Daten im JavaBean konzentriert und das Verhalten in sogenannten UseCases separiert. Diese Implementierung habe ich so erlebt und würde sie gerne mit Eurer Hilfe diskutieren um eine größere Klarheit über das Getane zu erlangen.

Donnerstag, 14. November 2013

Der Einzelne und das Team oder ein Borgkollektiv.

These: Menschen die sich wohl fühlen, Menschen die geachtet werden schaffen beachtliche Software.

In der modernen Welt gehen wir ein Arbeitsverhältnis ein, um unsere Lebensgrundlagen zu sichern. Wir unterschreiben einen Arbeitsvertrag. In diesem versprechen wir dem sogenannten Arbeitgeber eine Arbeitsleistung und bekommen dafür Geld. Mit dem Geld können wir einen gewissen Lebensstandard absichern. Ich hoffe, dass dieses grundsätzliche Verhältnis unstrittig ist, obwohl ich schon erstaunte Arbeitgeber gesehen haben, die diese Anschauung seltsam fanden.

Samstag, 9. November 2013

Entwurf und Bauen von Software – eine falsche Vorstellung.

Prozessübersicht Softwareentwicklung

Artikelübersicht
1. Teil Missing Links im Modell.
2. Teil Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung?
3. Teil Entwurf und Bauen von Software – eine falsche Vorstellung.
4. Teil Softwareentwurf ist ein organisierter Kreislauf.
5. Teil In Softwareprojekten gibt es viel zu entdecken!
6. Teil Die Interaktion mit dem Kontext ist ein wesentlicher Grund für den Erfolg eines Softwareprojektes.
7. Teil Das unentdeckte Land oder wo noch nie ein Mensch gewesen.
8. Teil Mit schlanken Methoden zu gewollter Software.
9. Teil Die Flexibilität des Vorgehens schenkt laufende Verbesserungen.
10. Teil Vom Problem seiner Rolle gerecht zu werden.
11. Teil Wir gründen eine virtuelle Firma.
12. Teil Warum ist unsere virtuelle Firma nur ein Torso?
13. Teil Eine Arbeitsvorlage, ein strategisches Team und ein tolles Geschäft.
14. Teil Ein fortgesetztes tolles Geschäft.


Im Post Missing Links im Modell haben wir den gesamten Lebenszyklus von Software in die beiden groben Schritte Softwareerstellung und in das Betreiben von Software eingeteilt. Das ist natürlich eine nicht sehr erhellende Unterteilung. Deshalb versuchen wir, mit einem Top-Down-Ansatz in die Tiefe zu gehen. Stück für Stück werden wir neue Schritte finden, Unklarheiten beseitigen und Schwierigkeiten aufdecken. Am Anfang konzentrieren wir uns auf die Erstellung von Software.

Montag, 4. November 2013

Kann man den eklatanten Wissensbruch in der Softwareentwicklung beheben?

Allgemeines

Der größte Themenkomplex des letzten Monats war das Requirements Engineering. Bisher hat es drei theoretische und einen praktischen Artikel gegeben. In diesem Monat wird die Reihe dadurch fortgesetzt, dass die Themenobjekte einer Systemkontextanalyse unterzogen werden. Zu diesem Thema habe ich bereits einige Artikel geschrieben, so dass man sich über die Grundlagen bereits vor Erscheinen informieren kann:

Mittwoch, 30. Oktober 2013

Ideen, Themenobjekte und die Roadmap im praktischen Beispiel.

Beispiel zum System der Anforderungsermittlung

Artikelübersicht
1. Teil Ideen, Themenobjekte und die Roadmap im praktischen Beispiel.
2. Teil Praktisches Beispiel zur Kontextuntersuchung.
3. Teil Praktisches Beispiel zu User Stories.
4. Teil Drei Basismodelle guter Software im praktischen Beispiel.
5. Teil Das Bauen von Use Cases mit Hilfe von User Stories im praktischen Beispiel.
6. Teil Die praktische Umsetzung verschiedener Perspektiven bei der Suche nach Anforderungen.


In diesem Post möchte ich die theoretischen Ausführungen der Artikel zum Ideenraum und zu den Themenobjekten in einem praktischen Beispiel verdeutlichen. Dazu benötigen wir eine Vision eines umzusetzenden Projektes. Ich wähle ein Programm zur Erfassung von Stakeholdern und ihren Beziehungen. Dazu habe ich bereits eine kleine Artikelreihe geschrieben, was für die Vorstellung des zu entwickelnden Programms sicherlich hilfreich ist.

Freitag, 25. Oktober 2013

Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung?

Prozessübersicht Softwareentwicklung

Artikelübersicht
1. Teil Missing Links im Modell.
2. Teil Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung?
3. Teil Entwurf und Bauen von Software – eine falsche Vorstellung.
4. Teil Softwareentwurf ist ein organisierter Kreislauf.
5. Teil In Softwareprojekten gibt es viel zu entdecken!
6. Teil Die Interaktion mit dem Kontext ist ein wesentlicher Grund für den Erfolg eines Softwareprojektes.
7. Teil Das unentdeckte Land oder wo noch nie ein Mensch gewesen.
8. Teil Mit schlanken Methoden zu gewollter Software.
9. Teil Die Flexibilität des Vorgehens schenkt laufende Verbesserungen.
10. Teil Vom Problem seiner Rolle gerecht zu werden.
11. Teil Wir gründen eine virtuelle Firma.
12. Teil Warum ist unsere virtuelle Firma nur ein Torso?
13. Teil Eine Arbeitsvorlage, ein strategisches Team und ein tolles Geschäft.
14. Teil Ein fortgesetztes tolles Geschäft.


Mein Beispiel mit dem Architekten im Post Missing Links im Modell sorgte anscheinend für einige Verwirrung. Es wurde angemerkt, dass ein Architekt das spätere Bauwerk nicht benutzen muss und daher Bauwerke entstehen, die nicht besonders nutzerfreundlich sind. Die Schlussfolgerung daraus war, in der Softwareentwicklung treten keine schlimmeren Wissensbrüche auf als in anderen Produktionsbereichen. Kurz gesagt zwischen dem Nutzer des Hauses und dem Architekten besteht derselbe Wissensbruch, wie zwischen dem Bankfachmann und dem Requirements Engineer.

Sonntag, 20. Oktober 2013

Themenobjekte ordnen Ideen in eine Roadmap

Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil Der Ideenraum.
3. Teil Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil Ein hierarchisches System von Kontextobjekten.
6. Teil Die Geschichten der Benutzer - User Stories erstellen.
7. Teil Die Analyse des Problemraums führt zum Zielmodell.
8. Teil Wie User Stories Use Cases gebären.
9. Teil Szenarien setzen sich zu Use Cases zusammen.
10. Teil Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil Die Vielfalt der Szenarien.
13. Teil Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil Ohne Abnahmekriterien läuft nichts.
15. Teil Startschuss zur testgetriebenen Entwicklung.


Im zweiten Teil der Requirements-Engineering-Reihe wurde eine Möglichkeit aufgezeigt, noch unstrukturierte Ideen abzugreifen und ggf. schon eine gewisse Struktur und Priorität zu ermitteln. Diese Ideen im Ideenraum warten nun auf eine sinnvolle Weiterverarbeitung. Im Ideenraum können sich mit der Zeit eine Unmenge von Ideen ansammeln. Wir benötigen eine Methode, um unseren Blick auf die wichtigen Ideen zu lenken. Dabei vertrauen wir auf die Mitarbeit der Erzeuger und Priorisierer der Ideen. Mit Hilfe des Priorisierungssystems ziehen wir einen Betrachtungshorizont in das System ein. Alle Ideen, die eine Mindestpriorität erreichen, werden in den nachfolgenden Prozessen betrachtet. Ideen, die diese Priorität nicht besitzen, werden (noch) nicht in die Weiterverarbeitung mit einbezogen.

Dienstag, 15. Oktober 2013

Reengineering – Am Ende gab es nur noch eine Schnittstelle.

Praktisches Beispiel 1.6

Artikelübersicht
1. Teil Reengineering - Die Analyse des Altcodes.
2. Teil Requirements Engineering – erst einmal die Anforderungen definieren.
3. Teil Systemanalyse – vielleicht doch erst mal eine Architektur.
4. Teil Reengineering - Neu, strukturiert und auf lange Sicht schneller.
5. Teil Schon Vorhandenes nutzen wäre schneller gewesen. Beispielcode
6. Teil Reengineering – Am Ende gab es nur noch eine Schnittstelle.


Zum Abschluss meiner Reengineering-Reihe möchte ich eine Frage versuchen zu beantworten, die mir in einem Xing-Forum gestellt wurde. Was, wenn nur noch die Schnittstelle übrig ist? Ich könnte es mir einfach machen und das folgende antworten: Ein Reengineering ist die Umgestaltung, die Restrukturierung und Neugestaltung eines Softwaresystems. Dazu gehört auch die genaue Analyse des Altsystems. In den fünf ersten Posts dieser Reihe ist das herausgearbeitet worden. Wenn von diesem Gesamtsystem jedoch nur noch Teile übrig sind, dann kann man auch nur noch aus diesen Teilen Informationen gewinnen und muss den Rest neu aufbauen.

Donnerstag, 10. Oktober 2013

Der Ideenraum

Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil Der Ideenraum.
3. Teil Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil Ein hierarchisches System von Kontextobjekten.
6. Teil Die Geschichten der Benutzer - User Stories erstellen.
7. Teil Die Analyse des Problemraums führt zum Zielmodell.
8. Teil Wie User Stories Use Cases gebären.
9. Teil Szenarien setzen sich zu Use Cases zusammen.
10. Teil Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil Die Vielfalt der Szenarien.
13. Teil Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil Ohne Abnahmekriterien läuft nichts.
15. Teil Startschuss zur testgetriebenen Entwicklung.


Eine Software entsteht aus einer Vision oder aus einer Notwendigkeit heraus. Sie kann auch schon jahrelang betrieben worden sein und nach Veränderung schreien. Ob wir nun ein neues Produkt bauen, ein altes Produkt umgestalten oder erweitern, es sind immer Ideen notwendig, dies zu tun. Eine Idee ist zuerst einmal ein unstrukturierter Einfall in Bezug auf das zu schaffende System. In der Kette der Prozesse befinden wir uns zwischen Vision und Systemkontextanalyse. Es macht keinen Sinn, Ideen abzublocken, nur weil sie unstrukturiert, beziehungslos und oft ungenau formuliert sind. Das Sammeln von Ideen ist die Vorordnung der Analyse. Alle einfach dahin gesagten Ideen sind von jedermann willkommen, der Stakeholder des zukünftigen Systems ist.

Samstag, 5. Oktober 2013

Praktiziertes Requirements Engineering

Allgemeines

Die Sammlung von Ideensplittern zum Requirements Engineering ist inzwischen auf weit über 100 Einträge angewachsen. Für mich war und ist es der Versuch, Twitter für eine, meines Erachtens, sinnvolle Kommunikation einzusetzen. Es gab einige Rückmeldungen, für die ich mich ganz herzlich bedanken möchte. Mit Spannung verfolge ich dabei das Experiment des Bloggens von Anforderungen.

Montag, 30. September 2013

Das Data Transfer Object – Be or not to be.

Praktisches Beispiel 2.2.1

Artikelübersicht
1. Teil Das Data Transfer Object – Be or not to be.
2. Teil Java Beans und Use Cases.
3. Teil Data Transfer Objects - ein Antipattern?


In dieser kleinen Reihe möchte ich den Einsatz des Data Transfer Objects diskutieren. Einer meiner Absichten ist es, mit Hilfe der Community, einige Unklarheiten in meinem eigenen Kopf zu beseitigen. Nachdem ich mein eigenes Wissen über dieses Entwurfsmuster aufbereitet habe, möchte ich auf einige Einsatzbeispiele kommen und anhand dieser diskutieren, ob man dieses Entwurfsmuster so anwendet oder nicht.

Mittwoch, 25. September 2013

Fehlerkreisläufe – Dein Freund, der Fehler.

These: Menschen die sich wohl fühlen, Menschen die geachtet werden, schaffen beachtliche Software.

Innerhalb eines Arbeitsprozesses werden Fehler gemacht. Wer nichts macht, macht auch keine Fehler. Über denen, die etwas machen sollten, sitzen die, die Anweisungen geben. Diese sind jedoch oft ungenau und beinhalten eine gewisse Zieltoleranz, um den Ausführenden in jedem Fall für seine Fehler zu bestrafen. Innerhalb unserer Kultur scheint es eine tiefe Bestrafungsphantasie für Fehler zu geben. Die eigenen Fehler werden auf Andere projiziert und mit dem Anderen ausgemerzt. Eine tiefe Befriedigung geht durch die, die sich über andere erheben. Doch leider hält diese Zufriedenheit nicht lange an. Diesem extrovertierten Fehlertyp steht der introvertierte Fehlertyp gegenüber. Er vergräbt sich in den Tiefen seiner Fehler, kann nicht schlafen und zittert schon vor dem nächsten.

Freitag, 20. September 2013

Von der logischen Komponente zur technischen Komponente.

These: Gut kommunizierte Software ist ein Segen für die Zukunft.

Artikelübersicht
1. Teil Ordnung für Use Cases und User Stories durch Funktionsgruppen.
2. Teil Von den Funktionsgruppen zu logischen Komponenten.
3. Teil Von der logischen Komponente zur technischen Komponente.


Im letzten Post dieser Reihe haben wir die gefundenen funktional motivierten Komponenten durch die Konzepte von Tier, Layer und Softwarekategorie weiter in logisch motivierte Komponenten unterteilt. Dabei wurde eine strenge Kommunikationsrichtung, immer von der oberen Komponente auf die untere Komponente, und ein strenger Zugriffsort, immer über die Fassade, vorgegeben.

Sonntag, 15. September 2013

Missing Links im Modell

Prozessübersicht Softwareentwicklung

Artikelübersicht
1. Teil Missing Links im Modell.
2. Teil Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung?
3. Teil Entwurf und Bauen von Software – eine falsche Vorstellung.
4. Teil Softwareentwurf ist ein organisierter Kreislauf.
5. Teil In Softwareprojekten gibt es viel zu entdecken!
6. Teil Die Interaktion mit dem Kontext ist ein wesentlicher Grund für den Erfolg eines Softwareprojektes.
7. Teil Das unentdeckte Land oder wo noch nie ein Mensch gewesen.
8. Teil Mit schlanken Methoden zu gewollter Software.
9. Teil Die Flexibilität des Vorgehens schenkt laufende Verbesserungen.
10. Teil Vom Problem seiner Rolle gerecht zu werden.
11. Teil Wir gründen eine virtuelle Firma.
12. Teil Warum ist unsere virtuelle Firma nur ein Torso?
13. Teil Eine Arbeitsvorlage, ein strategisches Team und ein tolles Geschäft.
14. Teil Ein fortgesetztes tolles Geschäft.


Das Buch [WEIL10] bot die Gelegenheit, eine Idee zu formulieren, die mir schon lange im Kopf ist. Die gesamte Softwareentwicklung und das Betreiben dieser Software setzt sich aus so vielen Einzelschritten zusammen, dass sie oft nicht zusammen gedacht werden. Das Zerreißen in kleine Schritte ist notwendig, um die Komplexität zu beherrschen. Das Zusammenfügen der kleinen Schritte jedoch auch, um das Ganze nicht aus den Augen zu verlieren. Softwareentwicklung ist nicht nur codieren. Softwareentwicklung besteht aus einer Vielzahl von Artefaktentwicklungen, die alle miteinander verwoben sind und Abhängigkeiten zueinander aufweisen. Das Suchen nach allen Schritten und den Zusammenhängen zwischen ihnen und deren Notwendigkeiten ist die Vision der Posts unter dem Thema "Prozessübersicht Softwareentwicklung".

Dienstag, 10. September 2013

Ein Objekt-Aufgaben-Modell für das Requirements Engineering

These: Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil Der Ideenraum.
3. Teil Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil Ein hierarchisches System von Kontextobjekten.
6. Teil Die Geschichten der Benutzer - User Stories erstellen.
7. Teil Die Analyse des Problemraums führt zum Zielmodell.
8. Teil Wie User Stories Use Cases gebären.
9. Teil Szenarien setzen sich zu Use Cases zusammen.
10. Teil Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil Die Vielfalt der Szenarien.
13. Teil Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil Ohne Abnahmekriterien läuft nichts.
15. Teil Startschuss zur testgetriebenen Entwicklung.


Im Requirements Engineering gibt es Ideen, Ziele, User Stories, Use Cases, Szenarien, Anforderungen, und wenn es der Dokumentationshunger verlangt, einiges mehr. All diese Dinge können wir als Objekte auffassen. Sie existieren in realen Spezifikationen, in geordneten Wikis oder auch im großen Durcheinander des Projektalltags. Ein Ding ist also ein reales Objekt, welches wir auch als Artefakt bezeichnen können. Diese Artefakte werden erstellt, geändert oder gelöscht. Diese Handlungen weisen darauf hin, dass sich das einzelne Objekt in verschiedenen Status befindet.

Donnerstag, 5. September 2013

Im September ruft die Community

Allgemeines

Am Anfang dieses Posts möchte ich mich bei allen bedanken, die meine Gedanken lesenswert finden und bei allen die mit ihren Kommentaren meine Fehler korrigieren, Wissen ergänzen und weitere Gedankenanregungen geben. Wenn ich nicht auf alles angemessen reagiere, so liegt es daran, dass die Zeit leider knapp ist und ich in erster Linie meinem Job nachkommen muss und dann erst diesem Blog frönen kann. Frönen ist übrigens etwas altertümlich und bedeutet "sich ausgiebig einer Beschäftigung hingeben, etwas gern und ausdauernd machen." (Wiktionary) In beidem liegt etwas von mir.

Mittwoch, 4. September 2013

Das Factory Pattern – Glaube und Wirklichkeit – eine konkrete Nachlese

Praktisches Beispiel 2.1.3

Artikelübersicht
1. Teil Das Factory Pattern – Glaube und Wirklichkeit – Teil 1
2. Teil Das Factory Pattern – Glaube und Wirklichkeit – Teil 2.
3. Teil Das Factory Pattern – Glaube und Wirklichkeit – eine konkrete Nachlese.


Zum zweiten Teil der Reihe Das Factory Pattern – Glaube und Wirklichkeit hat Torsten Robitzki mir geschrieben, dass ich extrem abstrakt geblieben bin. Seiner Meinung nach birgt das die Gefahr, dass vielleicht nicht alle das gleiche Verständnis entwickeln. Diese Kritik fand ich sehr berechtigt. Leider fehlte mir ein konkretes Beispiel und deshalb hatte ich Torsten gebeten ein Beispiel zu entwickeln. Dieser Bitte kam Torsten nach und ich bin ihm sehr dankbar dafür. Im nachfolgenden Text stelle ich sein Beispiel dar.

Samstag, 31. August 2013

Das Factory Pattern – Glaube und Wirklichkeit – Teil 2

Praktisches Beispiel 2.1.2

Artikelübersicht
1. Teil Das Factory Pattern – Glaube und Wirklichkeit – Teil 1
2. Teil Das Factory Pattern – Glaube und Wirklichkeit – Teil 2.
3. Teil Das Factory Pattern – Glaube und Wirklichkeit – eine konkrete Nachlese.


Im letzten Post hatte sich unser Team ein genaues Verständnis zur Static Factory Method und zum Factory Method Pattern der GoF erarbeitet. Wertvolle Informationen konnten wir auch aus den Kommentaren zum letzten Post gewinnen. Dafür möchte ich mich ausdrücklich bedanken. Damit dieses Wissen nicht verfällt, ist es gut, wenn es an einem zentralen Ort dokumentiert wird. Man könnte ein Wiki aufbauen, in dem alle Entwurfsmuster beschrieben sind, die sich das Team gemeinsam erarbeitet hat. Über die Zeit wird das eine erstaunliche Menge. Deshalb ist eine immer wiederkehrende Struktur in Form eines Katalogs anzuraten.

Freitag, 30. August 2013

Quelltext zum Praktischen Beispiel 1.5

Wie angekündigt werde ich heute eine Version vorstellen, die ein weiteres Refactoring erfahren hat. Für die Anregung dazu möchte ich Rusi danken. Sein Codereview hat mich dazu veranlasst den Code noch einmal zu überarbeiten. In seinem überarbeiteten Code hat er die Klasse StartConditions in Operation aufgehen lassen. Auch bemerkte er die schwere Testbarkeit von OrderGenerator durch den new-Operator für die Klasse StartConditions. Dadurch konnten in der execute-Methode der Klasse Operation auch die Parameter entfallen. Ein weiterer Hinweis von Rusi war, dass für den ParameterParser eine Methode, statt drei, im Interface genügt. Mich haben diese Hinweise überzeugt und deshalb habe ich den Code überarbeitet. Nachzulesen ist der alte Code im Post Reengineering - Neu, strukturiert und auf lange Sicht schneller.

Montag, 26. August 2013

Schon Vorhandenes nutzen wäre schneller gewesen

Praktisches Beispiel 1.5

Artikelübersicht
1. Teil Reengineering - Die Analyse des Altcodes.
2. Teil Requirements Engineering – erst einmal die Anforderungen definieren.
3. Teil Systemanalyse – vielleicht doch erst mal eine Architektur.
4. Teil Reengineering - Neu, strukturiert und auf lange Sicht schneller.
5. Teil Schon Vorhandenes nutzen wäre schneller gewesen. Beispielcode
6. Teil Reengineering – Am Ende gab es nur noch eine Schnittstelle.


Mehrfach haben wir schon auf Apache Commons CLI library hingewiesen. Endlich befassen wir uns mit der Verwendung von Open Source. Welche Schritte müssen wir gehen? Was müssen wir tun? Gibt es Gefahren? Diese und andere Fragen streifen unstrukturiert durch unser Hirn und bedürfen eines geordneten Weges.

Mittwoch, 21. August 2013

Organisationsstrukturen

These: Systemkontextanalyse öffnet die Augen für optimale Software

Artikelübersicht
1. Teil Kontextaspekt Stakeholder.
2. Teil Nutzerrollen, Personas und extreme Charaktere.
3. Teil Organisationsstrukturen.


Die beiden letzten Posts dieser Reihe (Teil 1 und Teil 2) beschäftigten sich mit dem Stakeholder an sich oder mit virtuellen Ausprägungen, um mit Gedankenmodellen arbeiten zu können. Im ersten Teil Kontextaspekt Stakeholder haben wir jedoch auch schon Stakeholder zu Gruppen zusammengefasst. Diese Zusammenfassungen sind in der Realität besonders in Organisationsstrukturen anzutreffen. Eine Firma ist eine Organisation. Die Firma besteht aus Abteilungen, Projektgruppen oder Teams. Ein Team kann sich aus Subteams zusammensetzen. Schlussendlich besteht ein Team oder ein Subteam genau wie eine Abteilung oder eine Projektgruppe immer aus Einzelpersonen.

Freitag, 16. August 2013

Von den Funktionsgruppen zu logischen Komponenten

These: Gut kommunizierte Software ist ein Segen für die Zukunft.

Artikelübersicht
1. Teil Ordnung für Use Cases und User Stories durch Funktionsgruppen.
2. Teil Von den Funktionsgruppen zu logischen Komponenten.
3. Teil Von der logischen Komponente zur technischen Komponente.


Im letzten Post dieser Reihe ist eine Möglichkeit beschrieben worden, Funktionalität in weitere Funktionsgruppen zu bündeln. Des Weiteren konnten wir Funktionsgruppen mit Hilfe von Funktionsgruppen in einer Hierarchie ordnen. Funktionsgruppen einer bestimmten Ebene können wir dabei als funktionale Komponenten auffassen. Stellen wir uns eine Software vor, in der man bestimmte Testuntersuchungen ausführen möchte. Die gesamte Funktionalität des Erstellens dieser Tests wird in einer Funktionsgruppe konzentriert, Testausführung und Testauswertung sind weitere Funktionsgruppen.

Sonntag, 11. August 2013

Das Factory Pattern – Glaube und Wirklichkeit – Teil 1

Praktisches Beispiel 2.1.1

Artikelübersicht
1. Teil Das Factory Pattern – Glaube und Wirklichkeit – Teil 1
2. Teil Das Factory Pattern – Glaube und Wirklichkeit – Teil 2.
3. Teil Das Factory Pattern – Glaube und Wirklichkeit – eine konkrete Nachlese.


Ein Entwicklungsteam, welches auf der Höhe der Zeit ist, verwendet Entwurfsmuster (Design Pattern). Programmierer stehen oft vor wiederkehrenden Problemen, für die schon lange exzellente Lösungen gefunden wurden. Diese Lösungen wurden in Lösungsschablonen niedergeschrieben und allen Programmierern zum Abschreiben freigegeben. Man muss das Rad also nicht zweimal erfinden. Trotz der durchklingenden, unbestrittenen Vorteile, kann der Gebrauch von Entwurfsmustern sehr problematisch sein. Weil man Entwurfsmuster anwenden soll, wendet man sie überall an, auch da, wo sie nicht hingehören. Weil man sie nicht richtig verstanden hat, wendet man sie falsch an. Einige haben sie verstanden und andere nicht. Die Anderen nimmt man auf dem Weg zum guten Code nicht mit und stellt sie in einer dunklen Ecke ab. Am Ende führt dieses teamfeindliche Verhalten zum Stillstand und reißt die Produktivität und die Laune in den Keller.

Dienstag, 6. August 2013

Reengineering - Neu, strukturiert und auf lange Sicht schneller

Praktisches Beispiel 1.4

Artikelübersicht
1. Teil Reengineering - Die Analyse des Altcodes.
2. Teil Requirements Engineering – erst einmal die Anforderungen definieren.
3. Teil Systemanalyse – vielleicht doch erst mal eine Architektur.
4. Teil Reengineering - Neu, strukturiert und auf lange Sicht schneller.
5. Teil Schon Vorhandenes nutzen wäre schneller gewesen
6. Teil Reengineering – Am Ende gab es nur noch eine Schnittstelle.


Ignorieren wir einfach die Apache Commons CLI library und gehen wir davon aus, es gibt keine Implementierung für unser Vorhaben. Dann müssten wir uns hinsetzen und anhand der Anforderungen und des Architekturentwurfs codieren. An diesem Punkt kehren wir in der Diskussion an unseren Ausgangspunkt zurück. Die Mehrheit ist vielleicht meiner Meinung, dass wir jetzt in der Lage sind, einen qualitativ hochwertigeren Code zu schreiben. Doch das Schreiben von Software außerhalb universitärer Strukturen ist auch ein ökonomischer Prozess. Und genau diese Ökonomie steht in Frage. Haben wir nicht viel mehr Zeit verbraucht?

Donnerstag, 1. August 2013

Am 12. August sind es 100 Tage

Allgemeines

Am 12. August sind es 100 Tage, in denen ich Posts in meinem Blog publiziere. Ich habe mich verpflichtet, alle 5 Tage einen Post einzustellen. Inzwischen weiß ich, Ok, ich schaffe es, aber es ist viel Arbeit. Da stellt sich die Frage, warum tue ich das?

Es ist an der Zeit, die Gründe offen zu legen, soweit das noch nicht geschehen ist. Die Thesen, die Inhalte der Posts verfolgen natürlich eine erkennbare Absicht. Ich möchte in Teams, in denen man motiviert an eine Aufgabe gehen kann, systematisch Software entwickeln. Dieser offensichtlichen Tatsache möchte ich weitere, vielleicht verdeckte Gründe, hinzufügen, so dass ein vervollständigtes Bild entsteht.

Samstag, 27. Juli 2013

Demokratische Teamstrukturen

These: Menschen, die sich wohl fühlen, Menschen, die geachtet werden, schaffen beachtliche Software.

Der Satz, "eine Unternehmen ist keine Demokratie", habe ich schon von mehreren Seiten zu Gehör bekommen. Besonders leitende Persönlichkeiten scheinen demokratische Strukturen als Bedrohung zu empfinden. Dabei wird die ganze Kiste der Ressentiments gegen die Demokratie aufgefahren. Denkt man darüber nach, beschleicht einen die Empfindung, dass diktatorische, zentralistische Systeme als effektiver empfunden werden. Meine Geschichtswahrnehmung hat jedoch Anderes gesehen. Mit der Freisetzung von Demokratie kam es zur Explosion von Kreativität und Produktivität. Die Explosionen autokratischer Denkmuster sind zumeist menschenverachtender, wenn nicht gar noch schlimmerer Art. Deswegen denke ich, es ist an der Zeit Demokratie im Team zu wagen.

Montag, 22. Juli 2013

Ordnung für Use Cases und User Stories durch Funktionsgruppen

These: Gut kommunizierte Software ist ein Segen für die Zukunft.

Artikelübersicht
1. Teil Ordnung für Use Cases und User Stories durch Funktionsgruppen.
2. Teil Von den Funktionsgruppen zu logischen Komponenten.
3. Teil Von der logischen Komponente zur technischen Komponente.


Das Ergebnis des Requirements Engineering ist eine systematische Dokumentation der Anforderungen eines zu erstellenden Softwaresystems. Je nachdem, wie die Anforderungen erhoben und mit welchen Mitteln sie dokumentiert wurden, liegen eine Menge von User Stories oder Use Cases vor. Im weiteren Verlauf werden User Stories oder Use Cases für den Entwurf einer Architektur verwendet.

Am Anfang bilden wir Bereiche gleicher oder ähnlicher Funktionalitäten und ordnen die passenden User Stories oder Use Cases in diese Bereiche ein. "Die Funktionsbereiche können sich gegenseitig verwenden, zwischen ihnen fließen Daten, und sie können sich hierarchisch enthalten." [S.347, REUS09]

Mittwoch, 17. Juli 2013

Nutzerrollen, Personas und extreme Charaktere

These: Systemkontextanalyse öffnet die Augen für optimale Software

Artikelübersicht
1. Teil Kontextaspekt Stakeholder.
2. Teil Nutzerrollen, Personas und extreme Charaktere.
3. Teil Organisationsstrukturen.


Im Post Kontextaspekt Stakeholder habe ich ein Modell zur Erfassung von Stakeholdern beschrieben. Dieses Modell möchte ich für die Aspekte der agilen Softwareentwicklung erweitern. Dort werden durch User User Stories formuliert. Ein mögliches Template für eine User Story ist

"Ich als (Rolle) möchte (Funktion), damit (Geschäftswert)." [S.100, COHN10]

Ein User tritt in einer bestimmten Rolle auf. Damit eine umfangreiche Sammlung von User Stories erstellt werden kann, müssen die User in verschiedene Nutzerrollen segmentiert werden.

Freitag, 12. Juli 2013

Systemanalyse – vielleicht doch erst mal eine Architektur

Praktisches Beispiel 1.3

Artikelübersicht
1. Teil Reengineering - Die Analyse des Altcodes.
2. Teil Requirements Engineering – erst einmal die Anforderungen definieren.
3. Teil Systemanalyse – vielleicht doch erst mal eine Architektur.
4. Teil Reengineering - Neu, strukturiert und auf lange Sicht schneller.
5. Teil Schon Vorhandenes nutzen wäre schneller gewesen
6. Teil Reengineering – Am Ende gab es nur noch eine Schnittstelle.


Ein weiteres Architekturmeeting diskutiert grundlegende Probleme der Architektur. Auch hier ist die Anwesenheit mehrerer Teammitglieder Garant für mehr Qualität. Jeder hat seine eignen Ideen, sieht Fehler und kann somit zu besserem Code beitragen.

Software wird nicht nur durch ein vergessenes Requiremens Engineering belastet, sondern auch durch einen fehlenden Architekturentwurf. Über die Jahre der "Codepflege" kann dieser aber auch im Chaos der "Verbesserungen" verschwunden sein. Es gibt keine Architektur, die den Code in kleine beherrschbare Strukturen unterteilt, die Verantwortlichkeiten benennt, so dass man schon weiß, wohin der entsprechende Code gehört.

Sonntag, 7. Juli 2013

Kontextaspekt Stakeholder

These: Systemkontextanalyse öffnet die Augen für optimale Software

Artikelübersicht
1. Teil Kontextaspekt Stakeholder.
2. Teil Nutzerrollen, Personas und extreme Charaktere.
3. Teil Organisationsstrukturen.


Im Folgenden werde ich ein Modell und eine Schablone zur Erfassung von Stakeholdern entwickeln. Im Post Welche Arten von Kontextobjekten gibt es? ist der Begriff des Stakeholders bereits definiert worden. Man kann ihn im Deutschen auch Interessenhalter nennen, also eine Person, die ein direktes oder indirektes Interesse an dem betrachteten Projekt besitzt.

Dienstag, 2. Juli 2013

Gedanken zu Reaktionen

Allgemeines

Es ist ein weiterer Monat ins Land gegangen. Trotzdem stehe ich noch ganz am Anfang. Die Frage, die mich umtreibt, ist, wie kann ich eine Diskussion entfachen, in der ich ganz viel lernen kann. Gespannt bin ich vor allem auf Ideen und Reflektionen, wie man sie eigentlich in der Breite nur im Internet erfahren kann. Viele verschiedene Menschen ganz unterschiedlicher Begabungen, ganz unterschiedlichen Könnens haben die Möglichkeit, sich in freier Diskussion auszutauschen. Man kann dabei Menschen entdecken, mit denen man gerne Kontakt aufnehmen möchte und wo eine einfache Kritik zu einem Austausch von Gedanken führt.

Donnerstag, 27. Juni 2013

Demokratie und Softwareentwicklung – menschliches Arbeiten in einem Softwareteam

Ich habe im Blog Initiative Wirtschaftsdemokratie einen Post veröffentlichen dürfen. Auf diesen Artikel möchte ich hier hinweisen. Er fügt sich in den dargestellten Kontext meines Blogs ein.

Ich gehe davon aus, das gebildete Menschen als mündige Bürger innerhalb demokratischer Strukturen arbeiten sollten. Lest dazu den Beitrag unter dem Titel Demokratie und Softwareentwicklung – menschliches Arbeiten in einem Softwareteam.

Requirements Engineering – erst einmal die Anforderungen definieren

Praktisches Beispiel 1.2

Artikelübersicht
1. Teil Reengineering - Die Analyse des Altcodes.
2. Teil Requirements Engineering – erst einmal die Anforderungen definieren.
3. Teil Systemanalyse – vielleicht doch erst mal eine Architektur.
4. Teil Reengineering - Neu, strukturiert und auf lange Sicht schneller.
5. Teil Schon Vorhandenes nutzen wäre schneller gewesen
6. Teil Reengineering – Am Ende gab es nur noch eine Schnittstelle.


Die gefundene Liste der Annahmen über Anforderungen, die in der Altsoftware verwirklicht wurden, werden jetzt im Team zu wirklichen Anforderungen gemacht. Die Aktivität des Requirements Engineering sollte keine Einzelkämpfertätigkeit sein. In einer Teamsitzung wird der Vollständigkeitsgrad der Anforderungen direkt proportional zu den anwesenden Teammitgliedern sein. Hat das Team auch noch einen positiven Teambildungsprozess durchlaufen, wird das Ergebnis unschlagbar.

Samstag, 22. Juni 2013

Teambildung als bewusster Prozess

These: Menschen, die sich wohl fühlen, Menschen, die geachtet werden, schaffen beachtliche Software

Am Anfang waren sechs Personen. Jede Einzelne verfügte über eine entsprechende Qualifikation, mit der man sich die Aufnahme in das Team verdient hatte. Folgendes Wissen wurde abgedeckt: Requirements Engineering, Softwarearchitektur, Entwicklung, Qualitätsmanagement und Projektmanagement. Damit sollte einer fruchtbaren Arbeit nichts mehr im Wege stehen und die Anweisungen aus der Führungsebene können im Sekundentakt in die Gruppe einschlagen. Eine Betrachtung, die den Menschen als fühlendes und denkendes Wesen außen vor lässt, würde sicherlich davon ausgehen, dass das funktioniert. Macht es sogar. Viele Menschen quälen sich in solchen Verhältnissen durch ihren Arbeitsalltag und sehnen sich nach dem Urlaub und der Rente. In all diesen Wesen schlummert Kreativität, Fantasie und Lebensmut. Der sollte auch am Arbeitsplatz einen Ort finden.

Montag, 17. Juni 2013

Reengineering - Die Analyse des Altcodes

Praktisches Beispiel 1.1

Artikelübersicht
1. Teil Reengineering - Die Analyse des Altcodes.
2. Teil Requirements Engineering – erst einmal die Anforderungen definieren.
3. Teil Systemanalyse – vielleicht doch erst mal eine Architektur.
4. Teil Reengineering - Neu, strukturiert und auf lange Sicht schneller.
5. Teil Schon Vorhandenes nutzen wäre schneller gewesen
6. Teil Reengineering – Am Ende gab es nur noch eine Schnittstelle.


Während eines Reengineering ist mir folgender Code, in ähnlicher Form, wirklich begegnet. Natürlich habe ich ihn abgeändert, denn es ist nicht meine Absicht, jemanden an den Pranger zu stellen. Meiner Meinung nach kommt es auch nicht aus Unfähigkeit zu solchem Code. Meist ist es die fehlende Zusammenarbeit im Team. Deshalb plädiere ich für eine andere Form der Zusammenarbeit. Im einzelnen sehe ich folgende Gründe:

Mittwoch, 12. Juni 2013

Wissensformen

These:Gute Software benötigt gute fachliche Anforderungen.

Dieser Post ist wieder ein Kapitel aus meiner Diplomarabeit [BAU09].

Im Interaktionsnetz der an einem Thema zusammenarbeitenden Menschen ist immer eine Ungleichverteilung des Wissens gegeben. Das Wissen des Einen muss zum Anderen transportiert werden, ohne dass es zu allzu großen Verlusten bei der Informationsübermittlung kommt.

Im Prozess der Softwareentwicklung sind drei Wissensformen maßgebend. Das fachliche, das technische und das analytische Wissen.

Freitag, 7. Juni 2013

Anforderungen werden durch Menschen erstellt.

These:Gute Software benötigt gute fachliche Anforderungen.

In den folgenden beiden Posts werden ich zur Einleitung dieses Themas zwei Kapitel meiner Diplomarbeit posten. [BAU09]

Einer der wichtigsten Aspekte der Erstellung von Anforderungen ist, dass sie in einem kommunikativen Prozess zwischen Menschen entwickelt werden. Eine Nichtbeachtung dieser kommunikativen Aktivitäten zwischen Menschen wäre eine wesentliche Auslassung bei der Erarbeitung eines Arbeitsablaufes für die Anforderungserstellung.

Sonntag, 2. Juni 2013

Neuer Monat, neue Ideen

Allgemeines

Seit einem Monat poste ich nun, und inzwischen sind mir ein paar neue Ideen gekommen. Die erste verdanke ich einer Antwort zu einem Beitrag, den ich in Xing veröffentlicht hatte. Dort wurde angemahnt, dass den Thesen die nötige Provokation fehlt. Bei näherer Betrachtung ist dem wohl auch so. Man kann sich zu schnell einverstanden fühlen und denkt, mach ich doch auch, will ich doch auch. Deshalb werde ich die Thesen durch ODER-Teile erweitern, die genau das beschreiben, was aller Orten Wirklichkeit ist. Im Gegensatz zur Realität bekommen die ursprünglichen Thesen dann vielleicht eine neue Relevanz. Auch werde ich die neuen Antithesen an den Anfang setzen. So hoffe ich mit der Provokation zu beginnen.

Dienstag, 28. Mai 2013

Modellbetrachtungen

These:Systemkontextanalyse öffnet die Augen für optimale Software

Im Folgenden übernehme ich einen Abschnitt aus meiner Diplomarbeit [BAU09]. In dem betreffenden Abschnitt habe ich einige kurze Betrachtungen zu Modellen durchgeführt. In den weiteren Posts werde ich die einzelnen Kontextaspekte erläutern. Dabei werde ich spezifische Modelle und Schablonen zur Darstellung und Erfassung verwenden. Deshalb stelle ich diese theoretischen Betrachtungen vor diesen Erläuterungen an. Der weitere Text dieses Posts ist der übernommene Text aus meiner Diplomarbeit [BAU09].

Donnerstag, 23. Mai 2013

Wer entwickelt Software?

These: Menschen, die sich wohl fühlen, Menschen, die geachtet werden, schaffen beachtliche Software

Software wird durch Menschen entwickelt. Diese Binsenwahrheit wird nur allzu oft nicht beachtet. Wir tun so, als ob Entwickler nur Werkzeuge in einem Prozess sind. Damit schaden wir dem Entwickler und auch dem Produkt, welches er schaffen soll. Beachten wir außerdem, dass der Produktionsprozess kein Selbstzweck ist, sondern eigentlich Produkte für das Leben der Menschen schaffen soll, so ist es kein weiter Weg mehr, zum Willen eine menschlich organisierten Produktion aufzubauen.

Samstag, 18. Mai 2013

Welche Arten von Kontextobjekten gibt es?


These: Systemkontextanalyse öffnet die Augen für optimale Software

Im Systemkontext befinden sich mehr oder weniger interessante Kontextobjekte. Kontextobjekte sind abzugrenzende Einheiten, bei denen es sich lohnt, sie als Ganzes zu beschreiben. Es macht Sinn, Kontextobjekte zu klassifizieren, um für gleichartige Kontextobjekte standardisierte Beschreibungswege zu finden. Diese Klassen von Kontextobjekten werden auch als Kontextaspekte bezeichnet. Pohl [S65, POHL08] findet drei Kontextaspekttypen.

Montag, 13. Mai 2013

Warum und wie sollte der Systemkontext erfasst werden?

These: Systemkontextanalyse öffnet die Augen für optimale Software

Eine Software wird, bewusst oder nicht bewusst, immer für eine Umgebung erstellt. Diese Umgebung ist der Systemkontext. Das Verstehen und Analysieren dieses Umfeldes spielt in vielen Projekten keine große Rolle und so sind viele Softwaresysteme nicht optimal in ihr späteres Wirkungsfeld eingepasst. Man verlässt sich auf Aussagen des Auftraggebers bzw. der Fachseite, ohne den Kontext zu prüfen, geschweige denn ihn zu optimieren. Dabei ist es vollkommen egal, ob man ein Altsystem modernisieren will, eine Software in ihrer Funktionalität erweitern möchte oder ein vollkommen neues System entwickelt.

Mittwoch, 8. Mai 2013

Was ist der Systemkontext ?



Alle 116 Artikel dieses Blog finden Sie nach Themengebieten geordnet auf der Seite Posts als Buch. Es gibt mehrere Reihen, in denen die Artikel aufeinander aufbauen.


These: Systemkontextanalyse öffnet die Augen für optimale Software

Wenn man eine neue Software erstellen oder eine alte Software verbessern oder erweitern möchte, spielt die Untersuchung des Umfeldes, in dem diese Software wirksam wird, oft keine Rolle. Doch um eine optimale Software zu entwickeln, ist das Verständnis genau dieses Umfeldes von entscheidender Bedeutung. Das ist natürlich nur soweit von Bedeutung, wie die zu betrachtenden Faktoren im Umfeld für die Erstellung des Systems von Betracht sind. Dieses notwendig zu betrachtende Umfeld nennt man auch den Systemkontext, und die Analyse des Systemkontextes ist die Systemkontextanalyse.

Freitag, 3. Mai 2013

Zu welchen Themen möchte ich posten?


Im Folgenden möchte ich einen kurzen thematischen Überblick über die Posts geben, die ich in den nächsten Wochen und Monaten publizieren möchte. Mein Ziel ist es, dabei in einen intensiven Austausch mit einer interessierten Community zu treten, die durch ihr Feedback die geäußerten Ideen verbessert, Denkfehler aufdeckt und neue Ideen einfließen lässt. Jede Kritik ist willkommen, Spam oder Beleidigungen jedoch nicht.