Re: [de-users] Anforderungskatalog - Druckvorstufe mit OOo
Am Dienstag, 3. Januar 2006 09:32 schrieb Siegfried Jetzke: Hallo Michael, Doch, es kann sein, dass zum Erstellen eines Briefes die Funktion Positionieren eines Adressfeldes für Fensterumschlag DIN C6 benötigt wird. Ein Test wäre dann das Testen dieser Funktion, nicht der Test Positionieren eines Textrahmens an beliebiger Stelle. Einspruch: Genau _diese_ Funktion muss getestet werden, denn sie ist die Grundlage für die Positionierung eines bestimmten Rahmens auf einem bestimmten Format! O.k., dieser Test wird auch benötigt. Wie Du sagst, ist er die Grundlage und ergibt sich als zwingende Voraussetzung aus dem anderen. Ich z.B. habe keine Lust, hunderte von Spezialvorlagen mitgeliefert zu bekommen, auch wenn die meisten sie irgendwann brauchen. Das kostet Ich hatte vor einiger Zeit begonnen, die Vorstellungen zu konkretisieren: Was gibt es für Textdokumente, was muss für eine Arbeit verfügbar sein? Ich denke nicht, dass es hunderte von Spezialvorlagen gibt. Du darfst nicht vergessen, das OOo ein _internationales_ Produkt ist! Letztlich müsstest du dann alle Normformate in allen Ländern abdecken. Ich habe mir für TeX und LaTeX alle Vorlagen erstellt, die ich benötige. Da ich es selbst machen musste, hab ich die Arbeit auf das notwendige Minimum beschränkt und habe so eine überschaubare Anzahl, die recht viel von dem abdeckt, was benötigt wird. Genau dies mache ich auch. Die gebe ich dann an jeden weiter, der sich dafür interessiert. Wenn ich Vorlagen bekomme finde ich das natürlich schön, aber wichtiger ist mir eine überschaubare Menge an Funktionen, die so vielseitig sind, dass ich alles selber machen _kann_. Oh, oh! Wer will den entscheiden, ob eine bestimmte Funktion von Nutzen ist oder nicht?! Ich kenne eine Menge Funktionen, die _ich_ für vollkommen unnötig halte, während mir Funktionen fehlen, die wahrscheinlich kein Schwein außer mir für gut hält... Nicht die, die am lautesten sind oder am meisten schreiben, sondern eine Abstimmung unter den AnwenderInnen. Dieses sehe ich als durchaus möglich an. Sorry: nein! Du wirst z.B. nur diejenigen erwischen, die hier mitlesen/schreiben. Selbst wenn du einen Aufruf in die Installationsroutine von OOo schreiben würdest, so wird nur ein Bruchteil der leute mitmachen. So gesehen, ist hier bestenfalls eine Umfrage unter den _aktven_ Benutzern möglich. Als Sysadmin, der auch diverse Schulungen durchführen durfte. habe ich mit Rückmeldungen durch die benutzer so meine Erfahrungen. Das betrifft besonders die Annahme meines Angebotes, _jedem jederzeit_ mit genaueren Erklärungen zur Verfügung zu stehen. Wieviele meiner 80 Kollegen hat wohl davon Gebrauch gemacht...? Die Umfrage, die du dir wünschst, ist definitiv der Weg über Issue und Voting. Ob dies der beste Weg ist, darüber lässt sich sicher lange diskutieren, aber so schaut die Realität aus... Es ist wie mit den Wegen in einem Park: Natürlich sind die gepflasterten so, dass Menschen auf ihnen gehen können, die von den Menschen genutzten Wege sind aber in der Regel andere. Das war mein Punkt. Die gepflasterten Wege, hier die Wege der Programmierer, sind die, die keiner geht. Deshalb macht es nur wenig Sinn, diese zu testen. Doch! Genau diese Wege müssen getestet werden, bis man davon ausgehen kann, dass nicht mal ein Schlafwandler in Gefahr gerät, wenn er darauf läuft. Erst danach kann man anfangen, die wichtigsten Trampelpfade zu Pflastern. Ich habe selber in einigen chaotischen Strukturen gearbeitet. Du bekommst da keinen großen Plan hinein transplantiert! Nimm einen losen Faden auf der dir zusagt und fange einfach an etwas zu machen. Wie oben gesagt, habe ich bereits vor langer Zeit einen ersten konkreten Vorschlag gemacht, in dem ich Arten von Textdokumenten nannte, die mit OOo erstellt werden können sollten. Dieses hat sich aber wieder sehr schnell in eine allgemeine Diskussion entwickelt. Dann mach einfach eine Übersicht, konkretisiere deine Spezifikationen und stelle das Ganze online (z. B. Homepage mit kleinem Hinweis hier in der Liste). Mit etwas Glück hast du dann jede Menge Anregungen und kannst mit möglichen Mitstreitern ein paar Issues produzieren. Gruß, Michael -- / / / / /__/ Michael Höhne / / / / / / [EMAIL PROTECTED] / _/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Anforderungskatalog - Druckvorstufe mit OOo
Hallo Siegfried, *, es tut mir leid, ich wollte schon auf Deine letzte Mail antworten, aber habe mir das verkniffen, aber jetzt antworte ich mal auf diese. Siegfried Jetzke schrieb: Hier haben ich und auch andere schon auf das absolute Chaos mit 1899 oder 1988 issues hingewiesen. Welches Chaos besteht dort? IMHO kann es evtl. sein das einige issues nicht richtig bearbeitet sind, aber ansonsten? Ich habe mir diese speziellen rund 1800 issues nicht angesehen, aber was sollte da sein? Alle issue werden IMHO ganz überwiegend schnell bearbeitet (wenn auch nicht in 24 Stunden) und was erwartest Du sonst noch. Gesagt worden ist Dir das wir mehr Leute brauchten, konkret für die issues wären das Programmierer, denn was ich bearbeitet nenne heißt nur das der issue geprüft wurde und dann ebend (grob gesagt) abgelehnt oder 'bestätigt' das entsprechende Änderungen/Fehlerbeseitigungen erfolgen werden. Sind Dir die dafür genannten Termine zu langfristig, dann ist das so, nur die Termine zu verkürzen würde mehr Programmierer erfordern. Bisher bist Du relativ wenig damit belastet, also, wo ist Dein Problem. Du beschwerst Dich in anderer Mail das wer auch immer hier Deine Fähigkeiten, Fertigkeiten und Kenntnisse unterschätzt und hältst André nun das hier entgegen? Es bahr jeder Substanz zu behaupten das André relativ wenig belastet sei. Dann schick doch einfach eine mail, mit dem, was OOo * machen soll, meinetwegen auch von SUN. Du versteht die Arbeit in einem OpenSource Projekt nicht, hier ist niemand den Du um Anweisungen anbetteln kannst oder der Dir welche aufzwingen wird. Wenn diese Anforderungen beinhaltet, ist diese Diskussion überflüssig. Diese Form der Diskussion hier ist ohnehin überflüssig. Würdest Du bitte verstehen, das das was Du scheinbar suchst ist nicht da. Es gibt ein Thema über das verschiedene Meinungen existieren (und ich *will garnicht* entscheiden wer recht hast) somit ist es ganz einfach, Du hast einen Vorschlag der Dir gut erscheint, dann suche Dir Mitstreiter und beginne mit der Umsetzung. Du brauchst kein OK von André, nur Du kannst doch auch nicht erwarten das er an etwas mitarbeitet von dem er nichts hält. Nur genau hier ist die Chance, beginne und zeige André das Dein Weg eine Verbesserung gegenüber dem jetzigen ist, dem wird er sich nicht entziehen. Nur bei theoretischen Diskussionen haben ebend die verschiedenen Seiten verschiedene Meinungen, das ist so. Und es ist kaum sinnvoll hier so lange zu reden bis alle Deiner Meinung sind, fange an und überzeuge durch das praktische Ergebnis. Akzeptiere doch einfach, dass ich zum Rumprobieren keine Lust habe. Das *ist* doch längst akzeptiert, weil das hier ganz übliche Akzeptanzen sind. Wenn Du und die Hauptverantwortlichen möchten, dass ich mittue, dann lass doch diesen Anforderungskatalog entstehen. *Wer* hindert Dich denn? Das Wort 'Hauptverantwortliche' ist schon unpassend, aber ganz sicher wird hier niemand beginnen Deine Arbeit aufzuhalten oder zu untergraben wenn Du denn nach Deinen Vorstellungen beginnst. Mit dem was Du geschrieben hast, könntest Du dieses durch einen einfache Weiterleitung Deiner Informationen von SUN das beenden. Tut mir leid, das ist eine völlige Verkennung der Situation oder glaubst Du das SUN hier Befehle erteilen kann. Ja versuchen können sie, aber sobald die sagen ihr *müßt* das hier so und so machen, dürften sich die Reihen hier heftig lichten, weil keiner bereit ist sich in einen OpenSource-Projekt kommandieren zu lassen. Andernfalls lass uns doch endlich die Anforderungen aufschreiben. Wer hindert Dich daran? Es tut mir leid, aber: *als ich hier vor knapp 2 Jahren anfing erschienen mir viele 'organisationstechnische' Dinge hier im Projekt genauso grotesk wie Dir jetzt auch, denn auch ich komme aus dem realen (Wirtschafts)leben und bin dort anderes gewöhnt. Nur auch ich mußte mich an die herrschende Situation gewöhnen und die hat nicht nur Schattenseiten. (Du kannst jetzt gerne Deine Zeit darauf verwenden die Situation ändern zu wollen, ich halte es für zweifelhaft das Du das schaffst, aber selbst wenn ist das Ergebnis das dann bei veränderter Situation die Leute aufhören die unter geänderten Bedingungen keine Lust mehr haben. Hier steht niemand unter Vertragserfüllungpflicht) *es ist wirklich und wahrhaftig ernst gemeint wenn ich Dir hier mehrfach sagte fange einfach an und schiele nicht auf die Meinung der Anderen. Gruß Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Anforderungskatalog - Druckvorstufe mit OOo
Am Montag, 2. Januar 2006 23:26 schrieb Siegfried Jetzke: Hallo, Genügt OOo diesem Szenario? Wenn nicht, was fehlt? (3) Ja ebend und das hat IMHO nichts direkt mit Testen zu tun. Doch, es kann sein, dass zum Erstellen eines Briefes die Funktion Positionieren eines Adressfeldes für Fensterumschlag DIN C6 benötigt wird. Ein Test wäre dann das Testen dieser Funktion, nicht der Test Positionieren eines Textrahmens an beliebiger Stelle. Einspruch: Genau _diese_ Funktion muss getestet werden, denn sie ist die Grundlage für die Positionierung eines bestimmten Rahmens auf einem bestimmten Format! Ich z.B. habe keine Lust, hunderte von Spezialvorlagen mitgeliefert zu bekommen, auch wenn die meisten sie irgendwann brauchen. Das kostet unnötig viel Platz. Aber: ich möchte mich darauf verlassen können, dass ich mir die benötigten Vorlagen jederzeit selber zusammenbauen kann. Alternativ: Die Positionierung wird perfektioniert, indem ein paar Anwender diese Funktion bei der Anlage der von ihnen benötigten Vorlagen testen. Wenn sie dann die von ihnen erstellten Vorlagen zur Verfügung stellen, haben alle was davon: Fehler beim Anlegen münden in Issues. Anwender, die eine bestimmte Vorlage benötigen, können sie kostenlos herunterladen. Das kommt doch dem Nahe was du möchtest: Testen des Programmes mittels praktischer Aufgaben... ... Ausgangspunkt waren Tests, die meines Erachtens keinen Sinn machen, wenn es keine möglich Anwendung gibt, für die eine eventuell als funktionsfähig getestete Funktion benötigt wird und es ging darum, aufgetretene Katastrophen, die das Arbeiten mit OOo unmöglich machen zu vermeiden. Oh, oh! Wer will den entscheiden, ob eine bestimmte Funktion von Nutzen ist oder nicht?! Ich kenne eine Menge Funktionen, die _ich_ für vollkommen unnötig halte, während mir Funktionen fehlen, die wahrscheinlich kein Schwein außer mir für gut hält... Fazit: Ich müsste ein Issue anlegen und genug Werbung dafür machen. Gibt es zu wenig Interesse, so habe ich Pech gehabt. Es ist wie mit den Wegen in einem Park: Natürlich sind die gepflasterten so, dass Menschen auf ihnen gehen können, die von den Menschen genutzten Wege sind aber in der Regel andere. Es macht keinen Sinn, nur die geplanten Wege zu testen und die gebräuchlichen zu ignorieren. Ergänzung: Dann baue mal ein paar Wege und du wirst merken, dass sich das Gehverhalten der Leute ändert. Dabei kannst du so viele Wege nachbauen wie du möchtest, irgendwo entsteht immer wieder ein wilder Trampelpfad... ;-) Ich habe selber in einigen chaotischen Strukturen gearbeitet. Du bekommst da keinen großen Plan hinein transplantiert! Nimm einen losen Faden auf der dir zusagt und fange einfach an etwas zu machen. Gruß, Michael -- / / / / /__/ Michael Höhne / / / / / / [EMAIL PROTECTED] / _/ -- / / / / /__/ Michael Höhne / / / / / / [EMAIL PROTECTED] / _/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Anforderungskatalog - Druckvorstufe mit OOo
Am Montag, 2. Januar 2006 23:26 schrieb Siegfried Jetzke: Hallo, Genügt OOo diesem Szenario? Wenn nicht, was fehlt? (3) Ja ebend und das hat IMHO nichts direkt mit Testen zu tun. Doch, es kann sein, dass zum Erstellen eines Briefes die Funktion Positionieren eines Adressfeldes für Fensterumschlag DIN C6 benötigt wird. Ein Test wäre dann das Testen dieser Funktion, nicht der Test Positionieren eines Textrahmens an beliebiger Stelle. Einspruch: Genau _diese_ Funktion muss getestet werden, denn sie ist die Grundlage für die Positionierung eines bestimmten Rahmens auf einem bestimmten Format! Ich z.B. habe keine Lust, hunderte von Spezialvorlagen mitgeliefert zu bekommen, auch wenn die meisten sie irgendwann brauchen. Das kostet unnötig viel Platz. Aber: ich möchte mich darauf verlassen können, dass ich mir die benötigten Vorlagen jederzeit selber zusammenbauen kann. Alternativ: Die Positionierung wird perfektioniert, indem ein paar Anwender diese Funktion bei der Anlage der von ihnen benötigten Vorlagen testen. Wenn sie dann die von ihnen erstellten Vorlagen zur Verfügung stellen, haben alle was davon: Fehler beim Anlegen münden in Issues. Anwender, die eine bestimmte Vorlage benötigen, können sie kostenlos herunterladen. Das kommt doch dem Nahe was du möchtest: Testen des Programmes mittels praktischer Aufgaben... ... Ausgangspunkt waren Tests, die meines Erachtens keinen Sinn machen, wenn es keine möglich Anwendung gibt, für die eine eventuell als funktionsfähig getestete Funktion benötigt wird und es ging darum, aufgetretene Katastrophen, die das Arbeiten mit OOo unmöglich machen zu vermeiden. Oh, oh! Wer will den entscheiden, ob eine bestimmte Funktion von Nutzen ist oder nicht?! Ich kenne eine Menge Funktionen, die _ich_ für vollkommen unnötig halte, während mir Funktionen fehlen, die wahrscheinlich kein Schwein außer mir für gut hält... Fazit: Ich müsste ein Issue anlegen und genug Werbung dafür machen. Gibt es zu wenig Interesse, so habe ich Pech gehabt. Es ist wie mit den Wegen in einem Park: Natürlich sind die gepflasterten so, dass Menschen auf ihnen gehen können, die von den Menschen genutzten Wege sind aber in der Regel andere. Es macht keinen Sinn, nur die geplanten Wege zu testen und die gebräuchlichen zu ignorieren. Ergänzung: Dann baue mal ein paar Wege und du wirst merken, dass sich das Gehverhalten der Leute ändert. Dabei kannst du so viele Wege nachbauen wie du möchtest, irgendwo entsteht immer wieder ein wilder Trampelpfad... ;-) Ich habe selber in einigen chaotischen Strukturen gearbeitet. Du bekommst da keinen großen Plan hinein transplantiert! Nimm einen losen Faden auf der dir zusagt und fange einfach an etwas zu machen. Gruß, Michael -- / / / / /__/ Michael Höhne / / / / / / [EMAIL PROTECTED] / _/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Anforderungskatalog - Druckvorstufe mit OOo
Grüß' euch, kann es sein, daß trotz Boards, Listen etc. immer noch zuviel Chaos bei OOo herrscht? Kreatives Chaos ist ja ok, aber Chaos, das blockiert wohl weniger. Ich habe jetzt etliche Links aus Mails rausgezogen und versuche mal, mich da durchzukauen. Aber das wird wohl etliche Zeit dauern, bis ich einigermaßen durchblicke. Geht es nicht einfacher? Zu einer Mail bzgl. AutoBeispiel für Tests; das ist zutreffend, daß bei einem bestehenden Kfz sinnvolle Tests her müssen. Aber auch ein Autohersteller wird sich Gedanken machen, wie er diese Version (z.B. Ford Focus) weiterentwickeln kann, wie er weitere Käuferschichten mit dem Produkt erreichen kann usw. Von daher genügen Tests allein nicht - das Ganze muß betrachtet werden. Wenn OOo ein Produkt ist, das noch mehr Nutzer erreichen soll, kann es nicht bei Test einer aktuellen Version bleiben. Das Ziel des Produktes muß klar werden. Und in diese Richtung gehen meine penetranten Vorschläge bzgl. Kategorien, Bereiche etc. Da muß ein klarer Faden rein, eine richtig gute Struktur, um es allen eingebundenen Personen so leicht wie möglich zu machen, und auch die Nutzer mit Funktionen zu bedienen, mit denen sie OOo anderen Office-Paketen den Vorzug geben. Was bislang an Diskussionen abgeht, wirkt auf mich wie das Fehlen einer klaren Struktur. Funktioniert das auf Dauer optimal? Johannes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Anforderungskatalog - Druckvorstufe mit OOo
Hallo, da ich der Auto-Mann war fühle ich mich mal angesprochen ;-) J.A. Bodwing schrieb: Aber auch ein Autohersteller wird sich Gedanken machen, wie er diese Version (z.B. Ford Focus) weiterentwickeln kann, wie er weitere Käuferschichten mit dem Produkt erreichen kann usw. Ja, sehr richtig, das macht aber die Marketing-Abteilung oder die Abteilung Produkt-Entwicklung oder wer sonst immer, aber *Nicht* die Testabteilung Das und nur das war hier mein Punkt, den ich rüber bringen wollte. Von daher genügen Tests allein nicht - das Ganze muß betrachtet werden. Ja, natürlich. Bloß irgendwie ist es logisch und üblich das hier jeder eine (oder mehrere) konkrete Aufgaben bearbeitet. Ja und IMHO war die konkrete Aufgabe, die nicht ich zugewiesen, sonden für die andere von sich aus Interesse bekundet hatten die Entwicklung von Test's. Das diejenigen die sich in diesem Sinne also Testentwickler nennen könnten auch mit anderen zusammenarbeiten das das rauskommt was Du beschreibst ist völlig logisch. Nur logisch ist IMHO auch das sich jeder auf die ihn am Meisten ansprechenden Bereiche 'spezialisiert' und nicht Einzelne ihre Arbeit auf jeden möglichen Teilbereich zersplittern. Was bislang an Diskussionen abgeht, wirkt auf mich wie das Fehlen einer klaren Struktur. Ja, nur von welcher Seite aus gesehen? Wenn ich euch mehrfach darauf hinweise das jeder gesammelte und kategorisierte Vorschlag zur Verbesserung von OOo 'heiße Luft' ist _solange_ er nicht zumindest in Form eines issues vorliegt, dann sind das Arbeitsstrukturen die einfach objektiv gegeben sind. Die auch kein Neueinsteiger gleich kennen muß, aber wenn man sie ihm nennt sollte er sie zur Kenntnis nehmen, denn ich fürchte sonst wird nichts werden. Ach und: es geht hier garnicht um Dogmatismus, wenn Dir oder anderen issuzilla nicht gefällt könnt ihr gerne versuchen etwas Besseres zu initiieren, da hat keiner prinzipiell was gegen, nur ebend solange nichts Besseres da ist heißt der Weg ebend issuezilla. Wenn Eric darauf hinweist einmal die praktische Seite zu betrachten und sich auf das derzeitig Leistbare zu beschränken, statt Super-Planungen für zukünftig evtl. denkbare Szenarien zu machen, so ist das keine Abfuhr an neue Ideen sondern lediglich Ausdruck der Kenntnis der 'Personallage' hier im Projekt. Bei allem was Du machen möchtest brauchst Du nämlich Freiwillige, niemand kann Dir hier Leute zuweisen, ganz egal wie gut wir Deine Pläne finden. So sieht es nun mal aus. Funktioniert das auf Dauer optimal? Bisher trafen Änderungswünsche in Richtung einer (allgemein gesagt) verbesserten Organisation nicht auf eine Mehrheit. Ich mußte das leider in der Vergangenheit in diversen Diskussionen zur Kenntnis nehmen, so wie Du jetzt. Somit wären Änderungen in der Organisation vielleicht oder sicherlich ganz sinnvoll, nur sie sind solange nicht durchsetzbar wie das die Mehrzahl das nicht will und wir müssen mit den Freiwilligen arbeiten die da sind und zu den 'Konditionen' auf die sich diese Freiwilligen einlassen, sonst gehen die einfach. Ansonsten: Dir legt hier keiner Steine in den Weg, Du brauchst nicht (unbedingt) nach Zustimmung zu fragen. Wenn Du etwas machen willst suche Dir Mitstreiter und fange an. Es ist wirklich ganz egal was andere über Dein Tun denken, denn andere haben keine Möglichkeit Dich aufzuhalten im Sinne Dich zu zwingen. (Naja, Du kannst natürlich sicher sein das Dich die Gemeinschaft der Community aufhalten wird wenn Du versuchen würdest bewußt etwas für uns Schädliches zu tun, nur davon kann ja hier nicht die Rede sein.) Gruß Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Anforderungskatalog - Druckvorstufe mit OOo
Hi, J.A. Bodwing schrieb: Grüß' euch, kann es sein, daß trotz Boards, Listen etc. immer noch zuviel Chaos bei OOo herrscht? Kreatives Chaos ist ja ok, aber Chaos, das blockiert wohl weniger. Ich habe jetzt etliche Links aus Mails rausgezogen und versuche mal, mich da durchzukauen. Aber das wird wohl etliche Zeit dauern, bis ich einigermaßen durchblicke. Geht es nicht einfacher? Zu einer Mail bzgl. AutoBeispiel für Tests; das ist zutreffend, daß bei einem bestehenden Kfz sinnvolle Tests her müssen. Aber auch ein Autohersteller wird sich Gedanken machen, wie er diese Version (z.B. Ford Focus) weiterentwickeln kann, wie er weitere Käuferschichten mit dem Produkt erreichen kann usw. Von daher genügen Tests allein nicht - das Ganze muß betrachtet werden. Ok .. meine definitv letzte mail in diesem Thread: Geh mal zu Ford und versuche als Laie herauszufinden, was Ford alles tut, um die Qualität eines einzelnen Autos in der Serienproduktion sicherzustellen (auch im Automobilbau sind tests ährend der Produktion etwas komplett anderes als Prototypen-Tests). Vielleicht findest du einen netten Mitarbeiter, der versucht, dir das ansatzweise zu erklären. Dann erzählst du ihm, dass das ja alles nichts hilft, sondern dass er ja erstmal wissen muss, was die Käufer von Ford wollen. Voraussichtlich wird er dir sagen, dass Ford das schon macht, dass aber auch er nciht konkret weiss, wer das nun tut (ist eher Aufgabe der marketingabteilung). Nachher hältst du ihm nen Vortrag, dass es aber ja wohl nicht angeht, dass das alles so kompliziert ist. Frage: wie lange dauert es, bis der nette Mitarbeiter dir sagt wir kommen hier vom huntertsten ins tausendste .. ich hab dir versucht, meinen Fachbereich zu erklären, du willst aber von mir was vollkommen anderes wissen .. nerv mich nicht noch weiter damit sondern lass mich meine Arbeit machen. Nochmal: usability-Tests wurden bisher hauptsächlich von Sun gemacht, Anforderungen ebenfalls .. vereinzelt sind diese aber auch in Issuezilla zu finden, es gibt einen Prozess, der beschreibt, wie man versucht, diese aufzubereiten. Kommentar dazu war bisher ist mir zu kompliziert, ich will mich nicht mit sowas befassen. Leute .. konzentriert euch auf ein Thema, das ihr überblicken bearbeiten *könnt* und geht davon aus, dass es es für andere Themen andere Leute gibt. André - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Anforderungskatalog - Druckvorstufe mit OOo
Grüß' dich trotzdem, André. Deine Ausführungen sind soweit klar und nachvollziehbar. Mein Problem war, und ist es noch immer, mich als Neuling hier zurechtzufinden. Wenn du schreibst, daß es für andere Themen andere Leute gibt, warum kommt dann OOo 2.0 raus, und man kann z.B. ein Textformat, das seit StarOffice-Zeiten zu Writer gehört, nicht mehr in ein Globaldokument einfügen? Vor diesem Hintergrund dachte ich, es könnt evtl. einfacher gemacht werden, damit solche Dinge nicht mehr passieren. Womit es bei mir eigentl. die ganze Zeit um Test-Bedingungen ging, nur evtl. erst mal auf einer allgemeineren Ebene. Wie gesagt, ich bin Neuling, ihr seid Experten. Wenn aber bei OOo an allen Themen Leute arbeiten, kann ja nichts passieren. Demnach läuft alles rund. Also fange ich jetzt mal an, mich durch sämtliche Links zu arbeiten, um einen Ansatz zu finden, wo ich was mithelfen könnte. Sobald mir das gelungen ist, melde ich mich wieder zur Mitarbeit. Gruß, Johannes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Anforderungskatalog - Druckvorstufe mit OOo
Jens Nürnberger schrieb: Hallo Daniel, hallo Anforderungsdiskutierende, schnipp / Es fehlt eine Anleitung (auf Grundlagen Neveau) für Base! Wer schreibt gerade dran? Ich würde gerne helfen! Ich quäle mich gerade dadurch. Bin über jede Unterstützung dankbar. Meine ersten Entwürfe kannst Du unter www.mechtilde.de sehen. Wenn die Dokumente einigermaßem fertig sind, sollen sie auch auf den OOo-Seiten veröffentlicht werden. Es fehlen Anleitungen (oder Infoblätter) für OOo 2.0, gerade 3 Stück sind Online (http://de.openoffice.org/doc/howto/index.html), Writer Draw fehlen ganz!! ... sind diese Probleme nicht wichtiger? Dafür haben wir leider nur sehr wenige Mitstreiter Bitte beantwortet nicht alle Fragen und Gedanken von mir, ich möchte damit nicht schon wieder eine Welle des Protests oder der Zustimmung lostreten. Diese Gedanken sollen nur das sein was sie sind Gedanken! Das hab auch schon öfters angesprochen. Bisher gab es darauf nur wenig Resonanz. schnipp / Mechtilde - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Anforderungskatalog - Druckvorstufe mit OOo
Hallo Mechtilde, Ich quäle mich gerade dadurch. Bin über jede Unterstützung dankbar. Meine ersten Entwürfe kannst Du unter www.mechtilde.de sehen. Wenn die Dokumente einigermaÃem fertig sind, sollen sie auch auf den OOo-Seiten veröffentlicht werden. Sehr gut, willst du die Anleitung in HTML oder in Opendocument verfassen, bei beiden Helfe ich dir gerne weiter, ich habe vor einiger Zeit (dienstlich) mal eine Anleitung zum Einstieg in Access verfasst und unterrichte dieses auch, diese könnte man sicherlich anpassen auf OpenOffice. Wie kann amn am Projekt mitarbeiten. Guten Rutsch und Grüße Jens - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Anforderungskatalog - Druckvorstufe mit OOo
Hallo Jens Nürnberger schrieb: Hallo Mechtilde, Ich quäle mich gerade dadurch. Bin über jede Unterstützung dankbar. Meine ersten Entwürfe kannst Du unter www.mechtilde.de sehen. Wenn die Dokumente einigermaßem fertig sind, sollen sie auch auf den OOo-Seiten veröffentlicht werden. Sehr gut, willst du die Anleitung in HTML oder in Opendocument verfassen, Das ist mir egal. Zur Veröffentlichung auf einer Web-Seite finde ich HTML besser. Ich kann Dir aber auch eine OpenDokument-Version schicken, da darin besser Korrekturen und Ergänzungen gemacht werden können. Vielleicht dann auch ohne die Bilder. bei beiden Helfe ich dir gerne weiter, ich habe vor einiger Zeit (dienstlich) mal eine Anleitung zum Einstieg in Access verfasst und unterrichte dieses auch, diese könnte man sicherlich anpassen auf OpenOffice. Vielleicht kannst Du mir ja auch mal einen Link schicken. Wie kann amn am Projekt mitarbeiten. Auch eine gemeinsame Arbeit an einem Dokument im Wiki könnte ich mir vorstellen. Mechtilde - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Anforderungskatalog - Druckvorstufe mit OOo
Mechtilde schrieb: Hallo Jens Nürnberger schrieb: Hallo Mechtilde, Ich quäle mich gerade dadurch. Bin über jede Unterstützung dankbar. Meine ersten Entwürfe kannst Du unter www.mechtilde.de sehen. Wenn die Dokumente einigermaßem fertig sind, sollen sie auch auf den OOo-Seiten veröffentlicht werden. Sehr gut, willst du die Anleitung in HTML oder in Opendocument verfassen, Das ist mir egal. Zur Veröffentlichung auf einer Web-Seite finde ich HTML besser. Ich kann Dir aber auch eine OpenDokument-Version schicken, da darin besser Korrekturen und Ergänzungen gemacht werden können. Vielleicht dann auch ohne die Bilder. bei beiden Helfe ich dir gerne weiter, ich habe vor einiger Zeit (dienstlich) mal eine Anleitung zum Einstieg in Access verfasst und unterrichte dieses auch, diese könnte man sicherlich anpassen auf OpenOffice. Vielleicht kannst Du mir ja auch mal einen Link schicken. Wie kann amn am Projekt mitarbeiten. Auch eine gemeinsame Arbeit an einem Dokument im Wiki könnte ich mir vorstellen. Wir sollte diese diskussion aber auf dev@de.openoffice.org in einem neuen Thread weiterführen. Außerdem gebe es auch sie Möglichkeit, sich zeitweise im Chat (möglicherweise auch in einem eigenen Channel) darüber auszutauschen. Mechtilde - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Anforderungskatalog - Druckvorstufe mit OOo
Hallo, Jens Nürnberger schrieb: Bitte beantwortet nicht alle Fragen und Gedanken von mir, ich möchte damit nicht schon wieder eine Welle des Protests oder der Zustimmung lostreten. Diese Gedanken sollen nur das sein was sie sind Gedanken! Ich tue mal meine dazu: Ich bin teilweise irritiert worum es hier geht. Situation ist wir können nicht so gut und ausgiebig testen wie wir möchten, was ursächlich mit verschiedenen Dingen zusammenhängt, wie: Personalmangel, Zeitmangel, ungenügend detaillierte Testbeschreibungen/Szenarien ... Nun haben sich Leute gefunden die versuchen wollen diese Situation zu verbessern. Prima, ich freue mich und bin wirklich gespannt auf neue frische Ideen. Bloß was erlebe ich: das überhaupt bzw. unverhältnismäßig viel darüber doziert wird was OOo denn nun können soll oder nicht, nur das ist doch der Bereich 'Produktentwicklung' und nicht der Bereich 'Testen' zumal ich mehrfach darauf hingewiesen habe von welch verschwindend geringer praktischer Relevanz diese Art Diskussionen sind _wenn_ nicht gleich berücksichtigt wird das diese in die 'offizielle' Struktur eingepaßt werden. Jederzeit lese ich hier gerne solche Hinweise von Usern, nur wenn wir hier ein Unterprojekt aufmachen dann muß/darf doch mal darauf hingewiesen werden wie die organisatorisch notwendige Vorgehensweise sein muß. Wenn wir hier Autos herstellen würden, dann wäre die Situation jetzt so das wir feststellen müssen das unser neues Modell 2.0 Fehler hat und das das die Kunden rügen. Ganz allgemein haben wir nun festestellt das diese Fehler wohl vor der Serienfreigabe hätten gefunden werden können wenn das Testen besser gelaufen wäre. Nun kommen ein paar neue Ingenieure ins Team die den Bereich Produkttestung verstärken wollen. Volle Zustimmung. Aber statt nun im Kern nach Verfahren zu suchen wie man derzeitige und zukünftige Prototypen zuverlässiger testen kann lese ich nur Forderungen der Art wir müssen erstmal die Kunden befragen was sie für ein Auto wollen und wir müssen erstmal die Forschungs- und Entwicklungsabteilung darauf hinweisen was zusätzlich in das Auto gehört usw.. Wäre es nicht zunächst der richtige Weg (aus Sicht der Testabteilung!) zu sagen: der Prototyp ist da und es geht zunächst nur um die Verbesserung der Test's und nicht um Ratschläge wie der Prototyp zuerst einmal überarbeitet werden soll. (Bei uns heißen Prototypen i.d.S. übrigens snapshots, Beta-Versionen und RC's). Bitte: Ich kritisiere hier Niemanden und Niemand soll sich zurückgesetzt fühlen. Meine Meinung ist zunächst nicht besser als die jedes Anderen und einzig ist es so das ich hier Einiges genannt habe was mich in einer Diskussion irritiert, die ich ansonsten mit Interesse verfolge. Ist Buchdruck nicht auch DTP - DT steht für Desktop also Bildschirm mehr nicht, jedes Druckwerk was am Bildschirm erstellt werden und in einer Druckerei gedruckt wird ist doch DTP? Oder? So kannst Du das IMHO nicht sehen. DTP ist ein inhaltlich festgelegter Begriff, den man vielleicht charakterisieren könnte als layoutorientierte (Text)dokument-Erstellung. Und dafür ist es egal was der Begriff dem Wortsinn nach meint, denn ganz sicher meint der Begriff Textverarbeitung auch nicht alle Programme die Texte verarbeiten, sondern eine spezifische Kategorie dieser Programme. Gruß Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Anforderungskatalog - Druckvorstufe mit OOo
Hallo, Am Samstag, 31. Dezember 2005 12:57 schrieb Jörg Schmidt: Ich bin teilweise irritiert worum es hier geht. Situation ist wir können nicht so gut und ausgiebig testen wie wir möchten, was ursächlich mit verschiedenen Dingen zusammenhängt, wie: Personalmangel, Zeitmangel, ungenügend detaillierte Testbeschreibungen/Szenarien ... Vielleicht verstehe ich das falsch. Aber die Frage war doch: welche Nutzungs-Szenarien gibt es. Denn nur anhand von Szenarien kann man Fragen klären: (1) Ist es wünschenswert, dass OOo in diesem Szenario genügt? (2) Genügt OOo diesem Szenario? Wenn nicht, was fehlt? (3) Ist es realistisch, OOo so zu entwickeln, dass es diesem Szenario genügt das überhaupt bzw. unverhältnismäßig viel darüber doziert wird was OOo denn nun können soll oder nicht, nur das ist doch der Bereich 'Produktentwicklung' und nicht der Bereich 'Testen' zumal ich mehrfach [[schnipp]] Wenn wir hier Autos herstellen würden, dann wäre die Situation jetzt so das wir feststellen müssen das unser neues Modell 2.0 Fehler hat und das das die Kunden rügen. wirklich? Ich habe da einen ganz anderen Eindruck. Die Frage wäre, wenn die Unterscheidung von Produktentwicklung und Testen so klar ist... Was ist denn dann der Unterschied zwischen dem hier diskutierten Testen und einem normalen Debugging. Das kommt ohne Szenarios aus, und es fragt auch nicht danach, wie benutzerfreundlich oder aufgabenspezifisch eine Funktion ausgelegt ist, sondern nur, ob sie ohne Fehler funktioniert. an Jens Nürnberger... So kannst Du das IMHO nicht sehen. DTP ist ein inhaltlich festgelegter Begriff, den man vielleicht charakterisieren könnte als layoutorientierte (Text)dokument-Erstellung. Und dafür ist es egal was der Begriff dem Wortsinn nach meint, denn ganz sicher meint der Begriff Textverarbeitung auch nicht alle Programme die Texte verarbeiten, sondern eine spezifische Kategorie dieser Programme. Auch aus meiner Sicht ist DTP mit Aldus Pagemaker aufgekommen und bezeichnet das, was dieses Programm und seine Nachfolger können. Ich habe in meinem Mail versucht, Aufgabebereiche zu unterscheiden: verschiedene Typen von Druckwerken. Jens Nürnberger hat das differenziert. Er hat gesagt, OOo sollte Flyer u.ä. für den Hausgebrauch machen können. Das sehe ich auch so. Dann aber unterscheidet sich die Liste dessen, was das Programm können muss von einer Liste, die man aufstellen müsste, um mit Indesign und Scribus gleichzuziehen (z.B. Farbmanagement). Grüße Daniel Wrana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Anforderungskatalog - Druckvorstufe mit OOo
Hi, wirklich? Ich habe da einen ganz anderen Eindruck. Die Frage wäre, wenn die Unterscheidung von Produktentwicklung und Testen so klar ist... Was ist denn dann der Unterschied zwischen dem hier diskutierten Testen und einem normalen Debugging. Hier in diesem Thread wird kein Testen diskutiert, sondern ein Anforderungskatalog. Ich hatte ursprünglich vorgeschlagen, sich auf Beschreibungen für funktionales Testen zu konzentrieren, macht aber niemand. Das kommt ohne Szenarios aus, und es fragt auch nicht danach, wie benutzerfreundlich oder aufgabenspezifisch eine Funktion ausgelegt ist, sondern nur, ob sie ohne Fehler funktioniert. Und hier liegt das Problem: wann funktioniert OOo ohne Fehler? Und welche funktionen sind das, die ohne Fehler funktionieren müssen, um einen Release vertreten zu können. Wenn jetzt auch nur einer antwortet natürlich alle, dann möge derjenige hingehen und alle Funktionen testen. Er kann mir das Protokoll dann zuschicken, wenn OOo 5.0 fertig ist, denn solang wird er etwa brauchen. Nur um dann gleich von vorne anfangen zu können, denn Ooo 5.0 müsste natürlich auch getestet werden. Von allen die hier mit diskutieren hat meines wissens noch keiner Release-Tests abgearbeitet und erlebt was passiert, wenn man dabei Fehler findet, sie bewerten muss, an die Entwickler weitergeben und vielleicht noch versuchen muss, den Release zu stoppen. Eine der Fragen, die dabei am häufigsten kommen ist: Bin ich nur zu blöd, oder ist ddas jetzt wirklich ein Fehler .. und genau *deshalb* brauchen wir bessere Beschreibungen für funktionale Tests, die ganz konkrete Funktionen testen. André - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Anforderungskatalog - Druckvorstufe mit OOo
Hallo, Daniel Wrana schrieb: Vielleicht verstehe ich das falsch. Aber die Frage war doch: welche Nutzungs-Szenarien gibt es. Denn nur anhand von Szenarien kann man Fragen klären: (1) Ist es wünschenswert, dass OOo in diesem Szenario genügt? (2) Genügt OOo diesem Szenario? Wenn nicht, was fehlt? (3) Ja ebend und das hat IMHO nichts direkt mit Testen zu tun. Testen heißt doch es gibt eine Programmversion die bestimmte Features hat und es ist zu prüfen ob diese Features funktionieren wie sie sollten. Und das hat nichts damit zu tun ob die Features nun Features sind die die User wollen, brauchen oder deren Bedienung ergonomisch wäre, sondern nur mit dem Test das alles wie beabsichtigt funktioniert, nicht mehr. Alle Maßnahmen die sicherstellen das das Programm erweitert/verbessert wird das es den User-Bedürfnissen mehr und mehr angenähert funktioniert sind ja für mich *völlig ohne Widerspruch* und wer sich darum kümmern möchte soll es doch gerne tun. Ich verstehe einzig nicht was das mit Test's zu tun hat. IMHO entweder: *die Mitstreiter die sich für Test-Verbesserungen einsetzen, machen das und lassen dann aber die 'User-Wunschlistensammlung für neue Features und Verbesserungen' weg *oder ich habe die bisherige Diskussion mißverstanden und es geht garnicht um Test's sondern ebend um Sammlung und Ordnen von Userwünschen Ich habe gegen Beides nicht das Geringste und hege nicht mal die Absicht jemanden zu drängen meinen Überlegungen zu folgen, aber im Moment verwirrt mich das inhaltlich verschiedene Dinge unter einer Überschrift stehen und (nach meinem Eindruck) Abhängigkeiten konstituiert werden die garnicht da sind. klar ist... Was ist denn dann der Unterschied zwischen dem hier diskutierten Testen und einem normalen Debugging. IMHO: Testen: meint das Finden von Fehler im eigentlichen Programm durch dessen Benutzung nach festgelegten Arbeitsabläufen (Testszenarien/Testlisten u.ä.) Debugging: meint das Beseitigen von Fehlern im Quellcode mit oder ohne das vorherige Vorliegen von Test-Ergebnissen *Der deutliche Unterschied ist das Testen nur Fehler feststellt ohne diese zu beseitigen und Debugging Fehler beseitigt*, die beim Debugging oder auch beim Testen gefunden wurden. (Theoretischerseits ist Debuggig Arbeit am Quellcode und Testen Arbeit mit dem Kompillat.) Das kommt ohne Szenarios aus, und es fragt auch nicht danach, wie benutzerfreundlich oder aufgabenspezifisch eine Funktion ausgelegt ist, sondern nur, ob sie ohne Fehler funktioniert. Ja, OK hier ist dann die Stelle wo zumindest wir zwei uns mißverstehen. Das was Du hier beschreibst ist nämlich für mich Testen und nicht Debugging (s.o.). Gruß Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Anforderungskatalog - Druckvorstufe mit OOo
Hallo, Andre Schnabel schrieb: Hier in diesem Thread wird kein Testen diskutiert, sondern ein Anforderungskatalog. Ich hatte ursprünglich vorgeschlagen, sich auf Beschreibungen für funktionales Testen zu konzentrieren, ja, und ich hatte nun verstanden das dieser Anforderungskatalog irgendwie im Zusammenhang mit dem Testen (bzw. dessen zukünftiger Verbesserung) stünde (warum das so sein könnte war mir ja nun gerade nicht klar) macht aber niemand. gut (oder nicht), zumindest in soweit gut als das ich nun verstehe das es hier eigentlich nicht mehr um die Verbesserung _des Testens_ (bzw. der Verfahren dazu) geht. Gruß Jörg P.S. Und welche funktionen sind das, die ohne Fehler funktionieren müssen, um einen Release vertreten zu können. Es geht jetzt hier darum zu sagen welche Funktionen müßten wir testen das weitere Funktionen (die da 'dranhängen') ebenfalls mit einiger Sicherheit funktionieren, weil wir nicht alles einzeln testen können - habe ich das so richtig verstanden? Nur dann muß ich sagen das können wir doch hier nicht verläßlich entscheiden, hierzu brauchten wir Quasi den Programmablaufplan anhand dessen der Code geschrieben wird. Ich kenne zwar das Dokument welches die 'Coding-Richtlinien' für den C++-Code von OOo beschreibt, aber das sagt (logischer Weise) nichts über die Zusammenhänge. Um solche Entscheidungen zu treffen muß man wissen wie im Code ein tatsächliches Ergebnis erzeugt wird, denn es reicht nicht das Ergenis zu kennen, weil 'viele Wege führen nach Rom' aber je nach Weg sind die Abhängigkeiten anders. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Anforderungskatalog - Druckvorstufe mit OOo
Hallo André u.* On Saturday 31 December 2005 17:29, Jörg Schmidt wrote: ja, und ich hatte nun verstanden das dieser Anforderungskatalog irgendwie im Zusammenhang mit dem Testen (bzw. dessen zukünftiger Verbesserung) stünde (warum das so sein könnte war mir ja nun gerade nicht klar) aus meiner Sicht: Anforderungen beschreiben, was eine Software können soll. Anforderungen sind aus Sicht der Benutzer verfasst (einen Brief verfassen und ausdrucken), umfassen daher häufig eine ganze Reihe von (Programm-) Funktionen. Tests beschreiben, wie getestet wird, ob eine bestimmte Funktion korrekt implementiert ist (also funktioniert). Daher ist der Zusammenhang der: Der Test beschreibt, welche Funktion wie getestet wird. Die (zugehörige) Anforderung macht deutlich, wofür diese Funktion benötigt wird und stellt den einzelnen Test somit in einen (allgemeinverständlichen) Kontext, strukturiert sozusagen die vielen Testfälle. So gesehen, sollte es keine Testfälle geben, die nicht (mindestens) einer Anforderung entsprechen, und es sollten zu jeder Anforderung ausreichend Testfälle geben. In jedem Fall halte ich die explizite Darstellung des Zusammenhangs zwischen Testfällen und Anforderungspunkten für hilfreich, um Testfälle zu konstruieren, bzw. ihre Vollständigkeit bezüglich einer bestimmten Anforderung zu überblicken. macht aber niemand. gut (oder nicht), zumindest in soweit gut als das ich nun verstehe das es hier eigentlich nicht mehr um die Verbesserung _des Testens_ (bzw. der Verfahren dazu) geht. für mich schon ?!? Und welche funktionen sind das, die ohne Fehler funktionieren müssen, um einen Release vertreten zu können. Es geht jetzt hier darum zu sagen welche Funktionen müßten wir testen das weitere Funktionen (die da 'dranhängen') ebenfalls mit einiger Sicherheit funktionieren, weil wir nicht alles einzeln testen können - habe ich das so richtig verstanden? seh ich genau so. Nur dann muß ich sagen das können wir doch hier nicht verläßlich entscheiden, hierzu brauchten wir Quasi den Programmablaufplan anhand dessen der Code geschrieben wird. Ich kenne zwar das Dokument welches die 'Coding-Richtlinien' für den C++-Code von OOo beschreibt, aber das sagt (logischer Weise) nichts über die Zusammenhänge. wenn wir aber testen, ob eine bestimmte Anforderung erfüllt wird Um solche Entscheidungen zu treffen muß man wissen wie im Code ein tatsächliches Ergebnis erzeugt wird, denn es reicht nicht das Ergenis zu kennen, weil 'viele Wege führen nach Rom' aber je nach Weg sind die Abhängigkeiten anders. Wenn wir aber die Anforderungen, die zu einem bestimmten Testfall gehören, kennen, dann brauchen wir nur zu testen, ob sie (bzw. in wie weit sie) erfüllt sind, egal wie das codiert ist: entweder kriegen wir unser Ergebnis oder nicht. Gruß Nino - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Anforderungskatalog - Druckvorstufe mit OOo
Hallo, Nino Novak schrieb: Daher ist der Zusammenhang der: Der Test beschreibt, welche Funktion wie getestet wird. Na prima. Die (zugehörige) Anforderung macht deutlich, wofür diese Funktion benötigt wird und stellt den einzelnen Test somit in einen (allgemeinverständlichen) Kontext, strukturiert sozusagen die vielen Testfälle. Ja, auch prima. *Nur was machen wir denn wenn ein Anforderungsfall eine Funktion benötigt, die dann auch getestet werden müßte, nur diese (für den Anforderungsfall notwendige) Funktion ist garnicht im Programm enthalten?* Nur genau darum geht es (zumindest mir) an dieser Stelle die ganze Zeit. *Oder willst Du auf Grund der Anforderungen Test's entwickeln deren eigentliche praktische Bedeutung dann (an einigen Stellen) darin läge das der Tester feststellt der Test ist garnicht durchführbar weil die Funktion die der Test auf Fehlerfreiheit testen soll noch garnicht im Programm vorhanden ist?* Gruß Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Anforderungskatalog - Druckvorstufe mit OOo
Moin, On Saturday 31 December 2005 19:15, Jörg Schmidt wrote: *Nur was machen wir denn wenn ein Anforderungsfall eine Funktion benötigt, die dann auch getestet werden müßte, nur diese (für den Anforderungsfall notwendige) Funktion ist garnicht im Programm enthalten?* Nur genau darum geht es (zumindest mir) an dieser Stelle die ganze Zeit. Gute Frage. Wie ist das bisher gelöst? Sollangabe des Ziel-Release im Issuezilla? Auflistung der Release-Notes? Auflisten gefixter Bugs für jedes Release? Die Frage ist, wo kann man was tun, um diese Zusammenhänge transparenter und ggf. in Teilen auch für Laien nachvollziehbar zu machen. *Oder willst Du auf Grund der Anforderungen Test's entwickeln deren eigentliche praktische Bedeutung dann (an einigen Stellen) darin läge das der Tester feststellt der Test ist garnicht durchführbar weil die Funktion die der Test auf Fehlerfreiheit testen soll noch garnicht im Programm vorhanden ist?* im Programm bezieht sich immer auf eine bestimmte Version des Programms, daher wird es immer Anforderungen geben (und damit Tests), die *noch* nicht implementiert sind und vielleicht auch welche, die nicht *mehr* implementiert sind, aus welchen Gründen auch immer. Aber jede Anforderung/Testszeanrio sollte für ein bestimmtes Release definiert sein, das ist klar. Gruß Nino - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Anforderungskatalog - Druckvorstufe mit OOo
Hallo Mechtilde, bei beiden Helfe ich dir gerne weiter, ich habe vor einiger Zeit (dienstlich) mal eine Anleitung zum Einstieg in Access verfasst und unterrichte dieses auch, diese könnte man sicherlich anpassen auf OpenOffice. Vielleicht kannst Du mir ja auch mal einen Link schicken. Anbei der Link, gerade Online gegangen, eine sehr sehr frühe Version http://jensnuernberger.homepage.t-online.de/ Hilfe der Erstellung erbeten! Ich kann aus organisatorischen Gründen nur einige Stunden pro Woche an den Projekt arbeiten, daher wird es sehr langsam voran gehen! Auch eine gemeinsame Arbeit an einem Dokument im Wiki könnte ich mir vorstellen. Ich habe leider keine Möglichkeit ein Wiki zu gründen das beste wärs allerdings, kann man die Materialien auch im OpenOffice.org-Wiki (http://www.ooowiki.de/) online stellen? Mir würde es nur gefallen beide Versione zu haben, einmal Online und einmal OpenDocument. Guten Rutsch Grüße Jens - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Anforderungskatalog - Druckvorstufe mit OOo
Liebe Anforderungsdiskutierende, die Diskussion hier ist ein wenig emotional, was offensichtlich daran liegt, dass die Diskutierenden sich schon kennen :o). Ich will mal versuchen, zwei Anforderungsprofile zu definieren, die meines Erachtens beim Thema DTP-Buchdruck-Druckvorstufe-Diplomarbeit ein wenig durcheinander gehen. Zunächst Definitionen: Als Druckvorstufe (Prepress) definiert die Wikipedia: Zusammenfassung aller Prozesse vor dem Druck. Das Ziel ist dabei der Erstellung einer Druckform. Das fängt beim Layouten an, geht über das Optimieren von Bilden etc bis hin zur Endoptimierung und Farbmanagement. Das Produkt ist ein ps oder immer öfter ein pdf, das auf eine Druckmaschine gejagt wird. Also auf eine richtige hochauflösende Druckmaschine (mit Filmerstellung oder direkt ausgedruckt, gibts inzwischen auch alles). Veränderung in den letzten Jahren: Während die Druckvorstufe die Aufgabe eines eigenen Berufszweigs war und im Profibereich immer noch ist, hat sich das geändert. Erstens ist die Druckvorstufe teuer und handkopierte Flyer sind irgendwie out. Zweitens gibt es Computer und Programme, mit denen grundsätzlich jeder Teile der Druckvorstufe erledigen kann. Ähnliches gilt für Bücher: die Verlage sagen: Wir schicken eine Dokumentvorlage, machen Sie das mit Word und schicken sie ein pdf. Man erstellt also ein Dokument mit einem Programm (meistens Word), gibt es als pdf aus und schickt dieses an Verlag oder Druckerei. Das ist die gängige Praxis. Frage ist nun: inwiefern kann OOo in so einem Prozess nützlich sein, welcher Anforderungskatalog gilt, was ist sein Spezialgebiet? (1) Desktop Publishing Anforderungen: - komplexes grafisches Seitenlayout mit Hintergründen, verschiedenen direkt positionierten Texten (Fließtext und Überschriften), - mehrspaltensatz, oft mit zusätzlichen Textfeldern - professionelles farbmanagement in CMYK, oft auf nur Schmuckfarben (also Schwarz plus eine Einzelfarbe wie etwa ein bestimmtes Blau) - grafische Gestaltungselemente, die bis an den Seitenrand gehen (nicht so banal wie es klingt) - eher wenige seiten Textarten: - Flyer, Broschüren, Zeitschriften, Einladungen, Werbematerial... Zielgruppen: - Alle Organisationen, Vereine, Firmen, Schulen etc. eher im Low-Profit-Bereich, denn die gut verdienenden Firmen nehmen nach wie vor Grafiker Druckvorstufe: in der Regel ja Programme: - Proprietär: QuarkExpress, InDesign - OpenSource: Scribus (2) Buchdruck Anforderungen: - viele, viele Seiten und viel Fließtext - Kopf- und Fußzeilen - Verzeichnisse (Inhalt, Literaturverz., Abbildungs...) - Referenzen - Fuß- oder Endnoten - Überarbeitungsmarkierungen und Notizen für den Korrekturworkflow und das gemeinsame Schreiben - gelegentlich ein Textrahmen (gerne ausführlicher im Wiki) Textarten: - Bücher aller Art, Diplomarbeiten, Dissertationen etc., Berichte Zielgruppen: - Studierende, Wissenschaftlerinnen, Kopfarbeiterinnen aller Länder... Druckvorstufe: nicht alle, aber manchmal und oft so, dass man das erst nach der Fertigstellung weiss wie... also erstmal nicht, später vielleicht doch... Programme: - Word - OpenOffice - Framemaker (?) - Tex -- Einschätzung meinerseits: zu (1) Den ersten Bereich kann OOo gar nicht gut erfüllen, genausowenig wie Word es kann. Das ProgrammPrinzip ist ein anderes, ob man gelegentlich einen Textrahmen hat oder eine Broschüre komplett aus solchen aufgebaut ist. Hier gilt der Vorschlag von Eric Hoch. Texten in OOo und dann exportieren in ein DTP-Programm. zu (2) Indesign (1.5 kenne ich), Scribus und die anderen sind dafür definitiv ungeeignet. Die können vom Fußnotenapparat bis zum automatischen Inhaltsverzeichnis rein gar nichts. Das ist die Domäne eines Satzprogrammes. Tex ist nett. Damit habe ich eine weile gearbeitet. Aber die Verlage haben VOrlagen zur Formatierung, so soll das definitv aussehen, und die mit LaTex zu erfüllen ist so gut wie unmöglich, wenn man kein absoluter Profi ist - habe das versucht. Bleiben Word und OpenOffice. Die Zeitschrift CT ist der Auffassung, dass OOo hierfür viel besser geeignet ist als Word. Es bringt die Fussnoten auf die richtige Seite, es lässt die Grafiken wo sie sind usw. Ich teile diese Einschätzung. OOo ist gegenwärtig das beste und allgemein zugänglichste Programm zum erstellen von Büchern, auch und gerade für solche, die dann professionell gedruckt werden (wage ich mich zu sehr raus?). Auch meiner Auffassung nach gibt es noch eine ganze Reihe Dinge, die man verbessern kann. Siegfrieds Initiative begrüße ich sehr! Aber das ist nicht Thema meines Mails. Grüße Daniel Wrana Ich kenne Framemaker nicht, aber es wird im übrigen von Adobe nicht mehr weiter geführt und nur die wenigsten dürften es haben. Am Freitag, 30. Dezember 2005 09:22 schrieb Siegfried Jetzke: Hallo Liste, wie es scheint, hat dieses Thema eine Menge an Ideen losgetreten. Da gestern nicht nur Anforderungen sondern auch
