Spezifizieren einer Notes DB, mit einer Notes DB

[ERGE]

Hallo Notes Folks

He habe eine neue Aufgabe oder Frage an Euch.
Ein Entwickler einer DB hat ausgiebige und lange Gespräche mit dem Kunden, wenn er eine DB spezifiziert.

Ich suche ein Tool oder Db welche ich dem Kunden zur Verfügung stelle wo er z.B anklicken kann, so müsste mein Framset 1 sein, so mein zweites, etc. Auch sollte es möglich sein irgendwie grafisch zu zeigen so sollte meine Form aussehen, resp. so heissen meine Felder und was kommt da rein (Zahl, Text, etc.).

Klar denkt Ihr jetzt, der hat doch ne Meise kann man auch mit Word oder PowerPoint tun, klar aber ich möchte dies in Notes versuchen. Hat von Euch jemand schon daran gearbeitet oder kennt ansatzweise so was?
Ich hoffe auf Eure Antworten.

Danke

[Thomas Schulte]

Einfache Antwort: Vergiss es.
zumindet mit Notes Bordmitteln. Wenn du unbedingt den Designer nachprogrammieren willst. OK aber ansonsten tust du dir keinen Gefallen mit diesem Projekt.

Thomas

[Semeaphoros]

Sehe ich auch so. Das ganze lässt sich als der erste Teil von Prototyping und dafür gibt es mehr als genug sinnvolle und andere Tools, die über deutlich bessere Eigenschaften für so etwas besitzen.

Allenfalls lässt es sich sogar mit Word oder StromPunkt machen, wie schon erwähnt wurde.

[Thomas Schulte]

Eins von diesen Tools ist z.B. Smart draw. Damit kannst du so Zueg mit den entsprechenden Bibliotheken richtig gut und vor allem schnell basteln.

Thomas

[Axel Janssen temp]

nein. nein. nein.  

Sämtliche Anwendungen - selbst die einfachsten - bilden in einem gewissen Sinne Geschäftsprozesse ab.
Das sind nicht Masken und Felder und Ansichten. Es geht um ganz andere Dinge. Die Kunden versprechen sich von einer Anwendung Geschäftsziele zu erreichen. Diese muß ich in den Grundzügen verstehen. Dafür ist die menschliche Sprache sehr gut geeignet.

Sämtliche mir bekannten modernen Ansätze des Projektmanagements (Rational Unified Process, Xtreme Programming) unterstreichen nachdrücklichst die Bedeutung der Interaktion von Kunden und Entwicklern.

Was du willst ist eine Welt, wo auf der einen Seite der Wand die Kunden sitzen und auf der anderen Seite "some code monkeys which are dificult to communicate with, but who know their API very well". Die Kunden werfen die requirements rüber und 2 Monate später werfen die monkeys die Anwendung zurück.

Ich erlebe auch an Entwicklern, die nach diesem Prinzip arbeiten wollen, mit der Zeit abstumpfen. Ich brauche jede Woche meinen fair share of Keks-Tellern, Meetings und Interaktion mit Anwendern.

Die Frage ist nur, wie man diese Anwenderinteraktion möglichst effizient gestaltet. Im Internet gibt es Tonnen von guten Templates zu guten Projektmanagement-Dokumenten. Das ist etwas, wo ich mir aus einem RUP Ansatz heraus, eine collection zusammenstellen will.

Die dot.com Krise hat erneut gezeigt, dass der monkey-Ansatz nicht funktioniert. Ich bin da völlig emotionslos.

Gruß Axel

[Semeaphoros]

Das ist richtig. Einen zusätzlichen Formalismus-Layer dazwischen zu legen macht keinen Sinn.

[Thomas Schulte]

Und das war jetzt die Meinung von drei Entwicklern, von denen ich zwei für extrem gut halte.
Hey ich bin in der Auswahl nicht drin.

Thomas

[eknori]

Ich erlebe das selbst Tag für Tag. Die Anwender kommen mit einer eventuell guten Idee an, werfen mir ein paar Begriffe ihres Fachbereichs an den Kopf und wollen dann von mir eine Anwendung. Und schwups sind se wieder weg.
Ich gucke ann erst einmal ziemlich blöd aus der Wäsche und mache dann gleich am nächsten Tag einen Termin mit der Fachabteilung. Meistens haut das dann auch hin. Also gehe ich in die Abteilung und lasse mir von den Anwendern erst einmal erklären, wie das Problem heute gelöst wird. Und dann die Frage, warum man ein möglicherweise effektives Vorgehen völlig auf den Kopf stellen soll, Altbewährtes und Optimiertes durch ein neues "Produkt" ersetzen soll.
Dann gucken die meist dumm aus der Wäsche ( kleine Rache meinerseits )

Oder man kommt zu der Überzeugung, daß das, was heute betrieben wird optimiert werden kann. Dann machen wir das auch; ich bin nicht unbedingt auf Notes fixiert.

Sollte man dennoch zu der Überzeugung kommen, es muß was neues her und das in Notes... bitteschön, könnt ihr haben, aber dazu muß ich verstehen, wie ihr arbeitet, elchen Zweck ihr verfolgt.
Das ist nur interaktiv mit dem/ den Usern möglich.
Dem User irgendein Tool an die Hand zu geben, wo er ala datenbanken24.de seine Wunschapplikation zusammenklicken kann ist nicht wirklich erfolgverspechend.

DinA4 und Bleistift und die Bereitschaft zuzuhören bewirken da viel mehr.

Ulrich

[Semeaphoros]

Hey, danke fürs Kompliment, aber ich denke, wir nehmen Dich da schon mit ins Boot :-)

Ueber das Thema hatte ich Vortrag an der Developer 2003: Prototyping. Mein Tipp dort: Handarbeit! Papier und Bleistift. Und da stehe ich nicht alleine. Rocky Oliver hat ebenfalls einen Vortrag in ähnlicher Richtung gehalten und sein Vortrag sagt dasselbe, genauso wie ein guter Artikel zum Thema bei IBM:

http://www-106.ibm.com/developerworks/web/library/us-paper/

[Driri]

Hi,

einen gewissen Formalismus kann ich aus meiner Erfahrung nur begrüßen, daß die User einfach ihre Wunschanwendung zusammenklicken halte ich allerdings nicht für sinnvoll.

A-bär :

Was spricht dagegen, den Anwender erstmal ein Formular ausfüllen zu lassen, in dem er in einfachen Worten beschreibt, was er eigentlich haben will. Also was ist der Ziel der Anwendung, welche Daten werden benötigt, wie werden die Daten eingegeben, von wem, welche Funktionalität wird benötigt, etc. ?

So etwas ist in meinen Augen extrem sinnvoll, denn sonst kriegt man irgendwas vor den Latz geballert, der Anwender zieht sich zurück und bekommt dann ein Produkt, was er so nicht wollte.

Ein Formular, wie oben beschrieben, ließe sich auch ohne Probleme in einer Notes-DB abbilden.

[Thomas Schulte]

@driri
Du hast teilweise recht, a-bär.
Das mit den Formularen wurde als Ansatz schon mehrfach versucht. Ich habe diese Vorgehensweise das erstemal 1986 in einem Projekt kennengelernt und das war damals schon Müll. Wenn du einem Anwender ein Formular zur Verfügung stellst und er dann seine Wünsche eintragen soll, verzögerst du die Entwicklung in der Regel. Du als Designer (Entwickler will ich hier nicht sagen weil das erst später kommt) hast dann ein oder auch mehrere Blatt Papier auf denen der Anwender in seiner Sprache aufgeschrieben hat was er denn meint zu brauchen. Das deckt sich in den seltensten Fällen mit deiner Sprache also hast du zwei Möglichkeiten.
1. du nimmst das was er da niedergeschrieben hat für bare Münze, entwickelst und hast anschließend genau den selben Ärger wie bereits beschrieben.
2. du gehst mit den Aufzeichnungen zum Anwender, fragst nach, versuchst zu präzisieren, klärst Begriffe und Definitionen ab und brauchst dafür eine Menge Zeit.
Da geh ich doch lieber gleich hin, rede mit den Leuten und versuche es beim ersten Schritt richtig hinzubekommen.
Übrigens, das wichtigste bei der SW Entwicklung ist es meiner Meinung nach dem Anwender zuzuhören. Formulare können das nun einmal nicht.

Thomas

[ERGE]

OK Jungs

Eure Lobhudelei und selbst "du bist gut" Darstellung in Ehren aber was ich suche ist etwas simples. Natürlich geht nichts über das Gespräch mit dem Kunden, es soll auch nicht so sein, dass der Kunde seine DB selber zusammen klickt und fertig.
Die Richtung zum Dokument wo er mal spezifiziert ist schon richtig, den wenn ihr 2 Kunden nehmt und mit denen spricht so ist der Unterschied des Ansatzes ziemlich verschieden. Ich mach euch ein Beispiel:
K1 sagt ich brauch eine DB mit einem Dokument wo ich Daten eingebe.
K2 sagt ich brauche DB mit einem Dokument wo ich Name, Vorname, Datum etc. eingeben kann und diese nach Datum,Name etc sortieren kann.
Dies meine Herren ist Realität und führt nicht an Gesprächen vorbei. Aber ist es sinnvoll einem Menschen immer sagen zu müssen"du willst jetzt gehen, also fuss eins vor fuss zwei und so weiter" und 2 Stunden später im nächsten Meet. fängst du wieder von vorne an.
Ok kann so sein, aber ich suche da eine neue Möglichkeit dem Kunden und mir das Leben zu vereinfachen in dem ich ein sogenanntes "Wunschkonzert" verabstallte, wo der OWNER der Datenbank sich Gedanken über seine Zukünftige Anwendung machen sollte und ich dies elektronisch erfasse und weiter Verarbeiten im Sinne einer Projektdoku kann.
Wenn Ihr ISO kennt so ist dies ja grundlegend einfach. Ich gehe zum Kunden frage wo ist dein Ablaufprozess und damit hat sichs wie die db aussehen soll.
Das mit dem Papier ist schon richtig aber gibts was das in Form DB in diese Richtung geht oder habe ich da wirklich einen Ansatz der unsere Informatikwelt noch nicht Gedanklich angepackt hat?