Vorgehensweise vor Start der Entwicklung einer neuen Dok-DB

[bob]

Hi,

ich will ja nicht o.t. werden, aber da in der Beschreibung "Alles was es zum Thema Entwicklung unter Lotus Notes gibt" steht, poste ich hier  

Wie geht Ihr es an, wenn eine Anforderung kommt
"wir bräuchten eine Dokumentenmanagement-Datenbank, kannst Du uns bitte sowas im Notes basteln?"

Da ich eigentlich kein Notes-Entwickler bin, aber hin- und wieder mal eine DB so nebenher mache, würde mich eine professionelle Vorgehensweise interessieren.
Geht zwar schon mehr in Richtung Projektmanagement......

Also, o.g. ist die Ausgangssituation.

Ich schildere mal, wie ich vorgehen würde:

1) zusammensetzen mit Anforderer und mal anhören was er konkret will (z.B. "ich will unser Qualitätsmanagement-System im Notes abbilden:
        * nett wäre ein Freigabeworkflow
        * mehrere Bereiche / Ansichten
        * Zugriffssteuerung (halt nach Rollen)
        * use.")
        * wann soll die DB fertig sein?
    Dabei würde ich gleich ein Tool wie Mindmanager verwenden, um alle Ideen etc. darin zu sammeln.

2) Protokoll erstellen inkl. Mindmap und entsprechend verteilen
3) grobe Aufwandsschätzung  
4) (kann entsprechend abweichen) Ressourcen klären (also ob ich überhaupt
    Zeit habe, ob der/die Chefs zustimmen etc.)
5) Erstellung Lastenheft (da Begriff oftmals unterschiedlich verwendet wird: "was der Kunde gerne hätte")
6) LH durchgehen mit Anforderer und anderer potentiellen User
7) Pflichtenheft erstellen ("was tatsächlich umgesetzt werden kann")
durchgehen PH mit allen Beteiligten
9) Protokoll mit Vermerk, dass Pflichtenheft abgesegnet (ggf. Korrektur Aufwandsschätzung)
10) Projekt aufsetzen
11) Kick off - Meeting veranstalten (lassen)


Habt Ihr andere Erfahrungen, wie man sowas angehen sollte?

Und wie geht Ihr mit Änderungsanforderungen um, also Änderungen nachdem bereits die DB zu x% fertig ist?

Würde mich über Eure Meinungen freuen!

cya,
Bob

[Axel_Janssen]

Zuerst eine Frage: Was ist eigentlich mindmapping?  

Domino ist ein RAD Tool. Ein Vorteil von RAD liegt darin, dass dem Kunden schnell ein Prototyp zur Verfügung gestellt werden kann.
Zu glauben, der Kunde weiss bei dem Pflichtenheft-Meeting was er will, ist eine Illusion. Trotzdem sollte man den Kunden ernstnehmen. Festnageln kann man ihn nicht.

Also ich bemühe mich immer ca. alle 2 Wochen Prototypen rauszuhauen und dem Kunden zukommen zu lassen. Da ist dann nicht die ganze Funktionalität, aber immerhin ein Teil. Oft fällt dem Kunden dann ein, was noch wichtig ist. Nachverhandeln ist oft schwierig, aber es geht nicht anders.

Dein Vorgehen sieht irgendwie Wasserfallmässig aus.
Dieses Verfahren wird heutzutage von (Rational) Unified Process und Extreme Programming sowie der Agile Alliance heftig kritisiert.

Wenn es dich interessiert, kann ich das 200 + x Seiten Buch von Kruchten: Der Rational Unified Process empfehlen. Ganz o.k. Das ist zwar ziemlich OO-gerichtet. Teile von diesen "moderneren" und hmm. sagen wir realistischeren Vorgehensweisen wie z.B. Use Cases lassen sich auch für nicht-OO wie Domino verwenden. Zu ernst nehmen würde ich es aber nicht. Man sollte eh nur Teile von dem ganzen Prozess implementieren.  

[bob]

Hi,

Mindmapping: ist ein Tool zur Ideensammlung, google.de hat da bestimmt viele Treffer, als Tool ist http://www.mindmanager.de führend.

^{Domino ist ein RAD Tool. Ein Vorteil von RAD liegt darin, dass dem Kunden schnell ein Prototyp zur Verfügung gestellt werden kann.}

Darin sehe ich eine große Gefahr für einen Entwickler:
Im Notes kann man schnell mal eine Oberfläche basteln, die schön aussieht. Den Code der hinter Funktionen steckt, sieht der Kunde meist eh nicht. Jetzt herzugehen, und dem Kunden vorab eine Version zu zeigen, halte ich für sehr gefährlich: er hat den Glauben die DB ist bald fertig, aber eigentlich ist nur das Look & Feel fertig, und die 90% tatsächliche Entwicklung sind es nicht....

Ist jetzt vielleicht ein worst case, aber - wie ich aus Erfahrung finde - was wahres dran.

Bob

[bob]

nachtrag: wo ich aber mit Dir einig bin ist, dass man frühzeitig Änderungswünsche herbeiführen muss, also dass diese nicht allzu spät kommen, denn das kann hohe Ressourcenverschwendung bedeuten.....

Bob

[ata]

Hallo Bob,

... zu Beginn versuche ich herauszufinden, was der Kunde will. Wichtig ist dabei auch, ob die DB auch Browserfaehig sein soll, denn das hat Auswirkungen auf die Architektur der DB. In deinem Beispiel waere noch wichtig zu erfahren, ob Attachments getrennt gehandelt werden sollen, ich habe teilweise Anwendungen, in denen ich Attachment in eine 2. DB auslagere...

... zur Ideensammlung verwende ich auch Mindmap, setze es aber nur dann beim Kunden ein, wenn ich weiss, dass der Kunde damit vertraut ist - Mindmapping kann auch verwirren...

... beim Freigabeworkflow setze ich mir eine Matrix auf, in der festgelegt wird, wer wann auf was zugreifen kann, welchen Status ein Dokument zu welchem Zeitpunkt erreicht etc. Hilfreich sind auch Flussdiagramme, die dann mit dem Kunden durchgesielt werden koennen...

... aehnlich wie Axel_Jannsen arbeite ich sehr gerne mit Prototyping. Der Kunde kann hier nochmals Verbesserungen einbringen. Wichtig beim Prototyping ist transparent zu halten, was bereits fertig ist, und was zunaechst Staffage ist...

ata

[eknori]

HMM, wenn du kein entwickler bist, kommt dir Notes entgegen, indem es Schablonen / Templates zur Verfügung stellt, mit denen du schnell die gewünscht Funktionalität auf den Bildschirm des Users zaubern kannst. Achtung, neues Schlagwort: Quick win Anwendung !!.
erstelle mal über Datei Datenbank Neu eine neue Datenbank und benutze die "Dok Bibliothek Notes und Web" ( heißt zumindest in R6 so).
Damit hast du dann erst einmal alles, was du so brauchst. Und das Bisschen "Customizing" schaffts du dann auch noch; selbst als Nicht-Designer  
Zum Thema Mindmap hat www.jnotes.de auch noch was auf der Pfanne.

eknori

[bob]

danke für Eure Tipps!

bye,
Bob