Benutzer-Werkzeuge
se:nofrills
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
|
se:nofrills [2008-12-30 20:44] stefan |
se:nofrills [2014-04-05 11:42] |
||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| - | ====== No-Frills-Software-Engineering ====== | ||
| - | * nach {[quellen:Gruhn2008]} | ||
| - | * "Software-Engineering ohne Schnickschnack" | ||
| - | * soll eine schlanke und wertorientierte Alternative zu herkömmlichen Vorgehensweisen zur Entwicklung von Informationssystemen bieten | ||
| - | * ein Fokus liegt auf Umgang mit Unsicherheiten (z.B. Unsicherheiten der Entwickler bzgl. Anforderungen, Unsicherheiten der Anwender bzgl. Funktion der Software etc.) | ||
| - | * vergleichbar mit dem Konzept von Billig-Airlines -> nur die wichtigsten Elemente der Dienstleistung werden benötigt (bei trotzdem guter Qualität) | ||
| - | |||
| - | ===== Prinzipien ===== | ||
| - | |||
| - | ==== Problemverständnis ==== | ||
| - | * Verstehe das ganze Problem in voller Breite | ||
| - | * Entwicklern fehlt häufig das Domänenwissen -> Fehler aufgrund mangelnden Domänenwissens sind teuer (da sie meist spät erkannt werden) | ||
| - | * nur der Blick fürs Ganze erlaubt die sinnvolle Auswahl und korrekte Formulierung der Anforderungen | ||
| - | * Identifiziere das Schlüsseldokument | ||
| - | * üblicherweise entstehen im Entwicklungsprozess viele verschiedenartige Dokumente, die nicht unbedingt "wertvoll" sind -> hier den Überblick zu wahren ist sehr schwierig und zeitaufwendig | ||
| - | * für jeden Dokumententyp sollte ein (!) Einstiegsdokument festgelegt werden, das ggfs. auf weitere Dokumente verweist | ||
| - | * des Weiteren sollte es einige wenige Kerndokumente geben, die als Einstieg in die Dokumentation dienen und das absolut notwendige Wissen enthalten müssen | ||
| - | * Design for Change | ||
| - | * Software wird allgemein als leicht änderbar empfunden, da sie (im Gegensatz zu materiellen Gütern) nicht greifbar ist | ||
| - | * Zwei (schlechte) Prinzipien zum Umgang mit Änderbarkeit | ||
| - | * Änderungen werden durch langwierige Anforderungsdefinitionen quasi ausgeschlossen | ||
| - | * man erstellt generische Software, die "alles" kann | ||
| - | * Änderbarkeit, Modularisierung, Abstraktion wird vornehmlich dort angewendet, wo sie in Zukunft voraussichtlich benötigt wird | ||
| - | * die restlichen Bereiche werden "normal" entwickelt und liefern "nur" die Funktionalität laut den Anforderungen | ||
| - | * Wähle das richtige Abstraktionsniveau | ||
| - | * zu Beginn der Entwicklung sind Detailfragen (z.B. Datentyp und Länge der Kundenadresse) nicht wichtig, es geht darum, beim Entwickler das Verständnis für die Domäne zu schaffen (z.B. Unterschied Antrag, Vertrag, Angebot einer Versicherung) | ||
| - | * während der Entwicklung sind natürlich Detailfragen elementar | ||
| - | * alle Dokumente (z.B. Klassendiagramme) müssen im Hinblick auf den Empfänger (z.B. den Fachbereich) erstellt werden und das entsprechende Abstraktionsniveau einhalten | ||
| - | * Trenne Anforderungen und Design | ||
| - | * die Entwickler sollen nicht einfach die Lösungen der Fachbereiche implementieren, sondern vielmehr die Probleme verstehen und Lösungen anbieten | ||
| - | * die Hinterfragung der Aspekte hinsichtlich Lösung (Design) oder Problem (Anforderung) führt zu einem tieferen Verständnisses des Problems und somit zu einer besseren Abwägung der verschiedenen möglichen Lösungen | ||
| - | |||
| - | ==== Wertorientierung ==== | ||
| - | * Teste, validiere und überprüfe das Wesentliche | ||
| - | * nach Möglichkeit sollten nur die Programmteile erneut qualitätsgesichert werden, die geändert wurden | ||
| - | * kritische Programmteile (die der Anwender zu Gesicht bekommt) sollten intensiver getestet werden -> subjektiv höhere Qualität der Software | ||
| - | * Fordere schlanke Lösungen | ||
| - | * zu jedem Zeitpunkt der Entwicklung sollte versucht werden, weniger Software zu erstellen | ||
| - | * Pareto-Prinzip: wenn mit 20% Entwicklungsaufwand 80% des Tagesgeschäfts behandelt werden kann, müssen die verbleibenden 20% die Weiterentwicklung rechtfertigen | ||
| - | * Möglichkeiten zur Automatisierung sollten ausgeschöpft werden | ||
| - | * kann die Anforderung auf eine andere Art erfüllt werden? | ||
| - | * was passiert, wenn wir die Anforderung weglassen? -> häufig nichts | ||
| - | * Produktivität = Nutzen / Aufwand | ||
| - | * die Produktivität ist besonders hoch, wenn mit wenig Aufwand schlanke Lösungen gefunden werden, die viele Anforderungen abdecken | ||
| - | |||
| - | ==== Technik ==== | ||
| - | * Design von außen nach innen | ||
| - | * Informationssysteme müssen meistens in eine bestehende Systemlandschaft integriert werden (keine "grüne Wiese") | ||
| - | * Integration-Engineering dominiert -> nicht erst das neue System planen und dann über die Integration zum Altsystem nachdenken | ||
| - | * Prüfe Sourcing-Möglichkeiten | ||
| - | * meist werden Aufgaben im Team anhand von Interessen oder aktueller Auslastung der Mitarbeiter verteilt -> unglückliche Aufgabenverteilung (z.B. Implementierung unternehmenskritischer Anforderungen durch externe Partner) | ||
| - | * die Frage der Aufgabenverteilung sollte strategisch entschieden werden | ||
| - | * Vermeide technologische Debatten | ||
| - | * Technologiediskussionen verlieren sich schnell im Detail und arten in Glaubenskriege aus | ||
| - | |||
| - | ==== Team und Qualität ==== | ||
| - | * Professionelle und fokussierte Kommunikation | ||
| - | * Stakeholder müssen immer auf dem Laufenden sein -> die Informationen sind jedoch meist überfrachtet und nicht priorisiert, sodass das wichtige unter den Tisch fällt | ||
| - | * die richtigen Informationen müssen zur richtigen Zeit in der richtigen Form vermittelt werden | ||
| - | * Beispiel Anwender: sie dürfen keine überzogenen Vorstellungen an das System haben, sondern die Fähigkeiten realistisch einschätzen können | ||
| - | * Wähle die passenden Sprachen und Werkzeuge für die Stakeholder | ||
| - | * Fließtext des Fachbereichs hilft den Entwicklern nicht (zu schwierig), UML der Entwickler hilft dem Fachbereich nicht -> Lösung: vereinfachte Form der UML oder nur intuitiv verstehbare Modelltypen verwenden | ||
| - | * Überprüfe auf No-Frills-Prinzipien | ||
| - | * viele Unternehmen kennen ihre eigenen Entwicklungsprozesse nicht oder sie werde mit der Zeit immer fetter | ||
| - | * regelmäßige Retrospektiven sind erforderlich um den Prozess zu optimieren | ||
| - | |||
| - | ===== Hauptaktivitäten ===== | ||
se/nofrills.txt · Zuletzt geändert: 2014-04-05 11:42 (Externe Bearbeitung)
Seiten-Werkzeuge
Falls nicht anders bezeichnet, ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht: CC Attribution-Noncommercial-Share Alike 4.0 International
