Benutzer-Werkzeuge
se:nofrills
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
|
se:nofrills [2008-12-30 20:22] stefan |
se:nofrills [2008-12-30 21:02] stefan |
||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| ====== No-Frills-Software-Engineering ====== | ====== No-Frills-Software-Engineering ====== | ||
| - | * nach {[quellen:Gruhn2008]} | + | **nach {[quellen:Gruhn2008]}** |
| * "Software-Engineering ohne Schnickschnack" | * "Software-Engineering ohne Schnickschnack" | ||
| * soll eine schlanke und wertorientierte Alternative zu herkömmlichen Vorgehensweisen zur Entwicklung von Informationssystemen bieten | * soll eine schlanke und wertorientierte Alternative zu herkömmlichen Vorgehensweisen zur Entwicklung von Informationssystemen bieten | ||
| Zeile 9: | Zeile 10: | ||
| ==== Problemverständnis ==== | ==== Problemverständnis ==== | ||
| - | |||
| * Verstehe das ganze Problem in voller Breite | * 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) | * Entwicklern fehlt häufig das Domänenwissen -> Fehler aufgrund mangelnden Domänenwissens sind teuer (da sie meist spät erkannt werden) | ||
| Zeile 31: | Zeile 31: | ||
| * die Entwickler sollen nicht einfach die Lösungen der Fachbereiche implementieren, sondern vielmehr die Probleme verstehen und Lösungen anbieten | * 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 | * 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 ===== | ||
| + | * Entwickle eine Vision | ||
| + | * Warum wird die Software erstellt? -> strategische, wirtschaftliche Ziele | ||
| + | * Für wen wird die Software erstellt? -> Stakeholder | ||
| + | * Was soll die Anwendung grob tun und was nicht? -> Funktionalität | ||
| + | * die Erfassung der Vision erfolgt methodengestützt (Results Chain Analysis, Benefits Realization Analysis) | ||
| + | * Fokussierung auf Wesentliches und angemessene Abstraktion | ||
| + | * die Vision muss allen Stakeholdern klar sein und von allen akzeptiert werden | ||
| + | * Sammeln von Anforderungen | ||
| + | * strukturierte Erfassung von Anforderungen, deren Herkunft und Priorität | ||
| + | * Dokumentation von Unsicherheiten durch Annotationsverfahren nach Brügge | ||
| + | * bereits Berücksichtigung der Release-Planung -> Ziel ist Priorisierung der Anforderungen und zeitliche Planung ihrer Umsetzung | ||
| + | * No-frills-Entwurf | ||
| + | * Einsatz von UML-Profilen, die Ungenauigkeiten und Unschärfen darstellen können | ||
| + | * Prototyping | ||
| + | * Erwartungen der Anwender managen -> sie werden kontinuierlich eingebunden und mit Zwischenergebnissen konfrontiert -> Unsicherheiten sowohl auf Seiten der Entwickler als auch auf Seiten der Anwender werden abgebaut | ||
| + | * Wegwerf-Oberflächenprototypen zeigen die Navigation -> sinnvoll bei neuen Geschäftsprozessen | ||
| + | * Klickbare Struktur-Prototypen wachsen schrittweise zu einem Abbild der Anwendung heran, veranschaulichen das grundlegende Verhalten | ||
| + | * Testen | ||
| + | * Ableitung der Testfälle aus vorgelagerten Artefakten | ||
| + | * Teste das Wesentliche | ||
| + | |||
| + | ===== Vorteile von No-Frills ===== | ||
| + | * Aufbau eines breiten Domänenwissens bei den Entwicklern -> konsistene Artefakte | ||
| + | * der Softwareentwicklungsprozess läuft schlanker und wird an den wichtigen Stellen methodisch gezielt unterstützt | ||
| + | * explizite Behandlung des Themas Unsicherheit gerade im Bereich der Anforderungen | ||
| + | * kontinuierliche Ausrichtung auf den wirtschaftlichen Nutzen der Software | ||
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
