Samstag, 2. Juni 2007
Thema: Use-Cases
Vor einiger Zeit hatte ich eine interessante Diskussion mit einem Senior-Entwickler.
Muss ein Use-Case "Login" auf Anwenderzielebene aufgeführt werden?
Ich hatte in etwa folgende Use-Cases aufgestellt:
Der Kollege argumentierte, ein für ihn relevanter, weil den Aufwand stark beeinflussener Use-Case fehlt: Login
Auf der einen Seite verbietet es die "reine" Lehre, z. B. nach Alistair Cockburn (z. B. in diesem Artikel) oder gemäß dem Kaffeepausen-Test, Use-Cases auf Systemebene mit denen der Anwenderebene zu mischen.
Mein Entwickler will auf der anderen Seite die wichtigen Kostentreiber auf einen Blick erkennen können.
Heute schreibe ich pragmatisch einen Use-Case "Login", mische die Ebenen und behelfe mir mit der Ausreden, dass ich es bewusst tue.
Bessere Ideen?
Muss ein Use-Case "Login" auf Anwenderzielebene aufgeführt werden?
Ich hatte in etwa folgende Use-Cases aufgestellt:
Der Kollege argumentierte, ein für ihn relevanter, weil den Aufwand stark beeinflussener Use-Case fehlt: Login
Auf der einen Seite verbietet es die "reine" Lehre, z. B. nach Alistair Cockburn (z. B. in diesem Artikel) oder gemäß dem Kaffeepausen-Test, Use-Cases auf Systemebene mit denen der Anwenderebene zu mischen.
Mein Entwickler will auf der anderen Seite die wichtigen Kostentreiber auf einen Blick erkennen können.
Heute schreibe ich pragmatisch einen Use-Case "Login", mische die Ebenen und behelfe mir mit der Ausreden, dass ich es bewusst tue.
Bessere Ideen?
... kommentieren
rolf goetz,
Donnerstag, 7. Juni 2007, 10:15
Lehre vs. Verantwortung
Sieht für mich so aus, als würdest Du damit einen Teil der Verantwortung des Kollegen übernehmen. Hätte nicht er die Aufgabe, aus den fachlichen Anforderungen abzuleiten, was es bedeutet sie zu erfüllen?
Ich vermute mal, in dem genannten Projekt gibt es keine Feedback-Schleife a la Lastenheft/Pflichtenheft. Ich habe das auch schon mehrfach erlebt: wenn es in diesem Sinn nur 1 Autor von Anforderungen gibt (den Stakeholder), dann versucht der Entwickler seiner Sehnsucht nach konkreteren Vorgaben nachzugehen, indem er detailliertere Anforderungen fordert. Würde ich auch machen. Vielleicht hilft es, ihm eine Möglichkeit zu geben, seine Bedenken ("Kostentreiber") so leicht wie möglich zu benennen und zu beziffern.
Zweiter Aspekt: ein gelungener Login bringt dem Anwender doch nichts, es ist Mittel zum Zweck. Dahinter steht irgendwo eine Sicherheits-Anforderung, die Authorisierung oder Authentifzierung will. "Ebenen mischen" riecht. Nach vorweggenommener Lösung. :-)
Ich vermute mal, in dem genannten Projekt gibt es keine Feedback-Schleife a la Lastenheft/Pflichtenheft. Ich habe das auch schon mehrfach erlebt: wenn es in diesem Sinn nur 1 Autor von Anforderungen gibt (den Stakeholder), dann versucht der Entwickler seiner Sehnsucht nach konkreteren Vorgaben nachzugehen, indem er detailliertere Anforderungen fordert. Würde ich auch machen. Vielleicht hilft es, ihm eine Möglichkeit zu geben, seine Bedenken ("Kostentreiber") so leicht wie möglich zu benennen und zu beziffern.
Zweiter Aspekt: ein gelungener Login bringt dem Anwender doch nichts, es ist Mittel zum Zweck. Dahinter steht irgendwo eine Sicherheits-Anforderung, die Authorisierung oder Authentifzierung will. "Ebenen mischen" riecht. Nach vorweggenommener Lösung. :-)
... link
andreas lechner,
Mittwoch, 13. Juni 2007, 01:10
Anforderungen vs. Konzept
Ich bin nicht sicher, ob ich Deinen Kommentar in meinem Kontext anwenden kann.
Das Login sehe ich als Teil des Konzepts, das ich als Lösung für die Anforderungen des Kunden erstelle.
Deshalb nehme ich einen Teil der Lösung vorweg... Aus Anforderungen zur Sicherheit leite ich ab, dass es einen Login geben muss.
Meine Aufgabe ist es, mit dem Entwickler gemeinsam ein möglichst gutes Bild zu entwickeln, was später umgesetzt werden soll. Ziel ist ein Festpreisprojekt, d. h. wir müssen die Kostentreiber möglichst genau kennen.
Die Herausforderung ist bei uns, während der Erstellung eines Angebots genau so viel Analyse und Konzeption zu machen, dass die Kalkulation genau wird. An einigen Stellen müssen wir häufig die Lösung vordenken, bevor der Rest der Systembeschreibung dieselbe Detailebene erreicht.
Vielleicht gibt es dennoch bessere Darstellungsmethoden für die Kostentreiber als das Mischen von Use-Cases verschiedener Ebenen als ein Use-Case-Diagramm? Ich lese jedenfalls in Deinem Kommentar ein Plädoyer für Use-Cases auf einer Ebene :-).
P. S. In diesem Projekt gab es tatsächlich ein Lasten- und ein Pflichtenheft... die ich beide geschrieben habe. Allerdings gab es kein Grobkonzept auf Basis des Lastenhefts, in der bestimmte Anforderungen detailliert wurden, um die Kostentreiber zu identifizieren - dort wäre der richtige Platz für die Lösungsbeschreibung, nicht das Lastenheft, wie es der Entwickler gefordert hatte.
Das Login sehe ich als Teil des Konzepts, das ich als Lösung für die Anforderungen des Kunden erstelle.
Deshalb nehme ich einen Teil der Lösung vorweg... Aus Anforderungen zur Sicherheit leite ich ab, dass es einen Login geben muss.
Meine Aufgabe ist es, mit dem Entwickler gemeinsam ein möglichst gutes Bild zu entwickeln, was später umgesetzt werden soll. Ziel ist ein Festpreisprojekt, d. h. wir müssen die Kostentreiber möglichst genau kennen.
Die Herausforderung ist bei uns, während der Erstellung eines Angebots genau so viel Analyse und Konzeption zu machen, dass die Kalkulation genau wird. An einigen Stellen müssen wir häufig die Lösung vordenken, bevor der Rest der Systembeschreibung dieselbe Detailebene erreicht.
Vielleicht gibt es dennoch bessere Darstellungsmethoden für die Kostentreiber als das Mischen von Use-Cases verschiedener Ebenen als ein Use-Case-Diagramm? Ich lese jedenfalls in Deinem Kommentar ein Plädoyer für Use-Cases auf einer Ebene :-).
P. S. In diesem Projekt gab es tatsächlich ein Lasten- und ein Pflichtenheft... die ich beide geschrieben habe. Allerdings gab es kein Grobkonzept auf Basis des Lastenhefts, in der bestimmte Anforderungen detailliert wurden, um die Kostentreiber zu identifizieren - dort wäre der richtige Platz für die Lösungsbeschreibung, nicht das Lastenheft, wie es der Entwickler gefordert hatte.
... link
... comment
giardino,
Freitag, 8. Februar 2008, 18:07
Die Frage ist doch: Müssen sich denn alle Aufwände vom Anwender-Use-Case-Diagramm ablesen lassen? Es gibt nun mal Funktionalität (mit möglicherweise signifikanten Aufwänden), die wenig oder sogar keinerlei Bezug zum Primär-Anwender des Systems oder seinen Zielen hat, sondern wie die Authentisierung in erster Linie Stakes eines Auftraggebers sichert und/oder womöglich regulatorisch gefordert wird. Ein vom Auftraggeber gefordertes komplett automatisches Backup würde ja auch eher nicht im Diagramm auftauchen. An dieser Stelle würde ich daher wohl mit dem Kollegen noch etwas diskutieren und versuchen, ihm seine Befürchtung anderweitig zu nehmen - Aufwände lassen sich m. E. ohnehin nicht ohne konkrete Requirements sinnvoll abschätzen.
Lasten- und Pflichtenheft aus einer Hand? Oh. Ich würde ja darauf bestehen, dass Letzteres von einem Design-/Umsetzungsverantwortlichen geschrieben wird; immerhin handelt es sich um einen Vertrag, der sicherstellt, dass die Anforderungen verstanden wurden und jetzt in einer spezifizierten Weise umgesetzt werden. Wie haben Sie dieses Buy-In alternativ sichergestellt?
Lasten- und Pflichtenheft aus einer Hand? Oh. Ich würde ja darauf bestehen, dass Letzteres von einem Design-/Umsetzungsverantwortlichen geschrieben wird; immerhin handelt es sich um einen Vertrag, der sicherstellt, dass die Anforderungen verstanden wurden und jetzt in einer spezifizierten Weise umgesetzt werden. Wie haben Sie dieses Buy-In alternativ sichergestellt?
... link
... comment
__daniel__,
Mittwoch, 12. August 2009, 12:46
Lösung?
Der technische Use Case "Login" ist die Detaillierung einer fachlichen Anforderung "Sich legitimieren". Letztere lässt sich aus einem Fachkonzept nicht wegdiskutieren.
... link
... comment