Gnoraz

Also das find ich nun irgendwie nicht schlüssig, wieso sollte der Kudne eine Vorlage scannen?! Das macht null Sinn!

ich habe nun eine neue Projektbeschreibung verfasst. Den Aspekt der Sicherheit habe ich mal ganz aussen vor gelassen, da dieser Punkt wohl ausserhalb des Projekts geregelt ist. Eine leichte Sicherheit gewährt das Format dennoch. Dies würde dann näher in der Projektdoku beschrieben werden. Was haltet ihr davon? Verständlich genug?

Ich danke dir für deine Kritik. Ich werde den Antrag nochmal neu formulieren, damit etwas klarer hervorgeht wie ich mir das vorgestellt habe.

Muss ich mir im Antrag wirklich schon so tiefgehende und detaillierte Gedanken über das Projekt machen, dass der Antrag im Prinzip schon eine Dokumentation des Projekts darstellt? Mich würde nun interessieren: - Was wäre noch zu ergänzen um den Antrag etwas verständlicher zu machen? - Ist die Zeitgliederung in Ordnung? - Ist der Punkt Dokumentation in Ordnung? Ich weiss eure Mühe zu schätzen, das Projekt jetzt schon so umfassend ausklügeln zu wollen, aber muss man das tun? Natürlich informiert man sich im Vorab schonmal über das Thema in welches man vorhat sich zu begeben. Und daraus resuliert - Einfaches Suchen udn Ersetzen ist nicht möglich - Texte werden in Streamobjekten abgelegt, welche mit dem zLib Algo komprimiert sind. - dekomprimieren würde also auch wieder gehen. - um Text zu verändern müssen mehrere Teile der PDF neu generiert werden - die Referenztabelle der Objekte - Die Schriftartparameter des Schriftartdictionaries - das Streamobjekt selbst. - und weitere... In meinen Augen ist dies ein schönes 70 Stunden Projekt. Ich sehe nun momentan nicht was dagegen sprechen würde dies so umzusetzen?

Ich habe mir das bereits schonmal angesehn. Einfaches Suchen und Ersetzen ist dies bei weitem nicht. Wer das schonmal versucht hat weiss, dass jedes einzelne Zeichen in einer PDF mit einem definierten Abstand dort eingetragen wird, würde ich nun einfach einen Text ersetzen, würden sich ettliche Buchstaben einfach überlagern. So ist es dem Benutzer schonmal nicht möglich den Text einfach so zu verändern. Über zusätzliche Sicherungsmechanismen werde ich mir noch Gedanken machen. Die Dateien sind aber ohne hin über CRC-Prüfsummen geschützt, dies gehört jedoch nicht zu meinem Projekt.

Ich verstehe nun nicht ganz, was du mit diesem Druckertreiber meinst, meinst ich solle lieber einen Druckertreiber schreiben der das modifiziert? Das ist wohl nicht machbar Word wird im späteren betrieb kein Bestandteil der Prozesskette mehr sein. Es liegt eine PDF-Vorlage vor, diese wird durch die Klasse modifziert, fertig. --> Word und andere Software ausser dem Prüfprogramm ist auf den ausführenden Prüfrechnern nicht vorhanden.

Hrm das war mir seither entgangen, da werde ich nochmals genauer nachsehen. Danke für die Info

Sollte ich hier bei der Stelle, dass die Manipulation erschwert werden soll erwähnen, dass damit die Manipulation durch den Benutzer gemeint ist? Ich dachte das geht daraus hervor. Eine standard PDF liegt im komprimierten Format vor, hier ist die Rede von einer unkomprimierten PDF, dort ist zumindest der Inhalt klarschriftlich lesbar. Die Dokumentation von Adobe über die technischen Spezifikation des PDF Formats umfasst ca. 800 Seiten, das ist wahr. Jedoch werde ich für mein Vorhaben sicherlich nicht die komplette Spezifikation analysieren müssen, sondern jediglich das was ich für mein Projekt benötige. Dies würde die basics des PDF Formats betreffen und wie PDF mit Inhalten und Schriften verfährt. Eine API ist für das Projekt nicht vorgesehen. Geht aus dem Text nicht klar genug hervor, dass eine Protokollvorlage zunächst in Word erstellt wird, der Kunde dann noch das Layout beliebig anpassen kann und dann daraus eine PDF entsteht, welche für den Einsatz im Programm verwendet wird? Wäre es besser diesen Schritt garnicht zu erwähnen sondern gleich von einer fertigen Vorlage im PDF-Format auszugehen ?

Hallo, ich würde mich über eine Bewertung meines Projektantrags sehr freuen. Konstruktive Kritik würde mir sehr weiter helfen ___________________________________________________________________________ Thema Entwicklung einer Klasse zum nachträglichen Ersetzen von Platzhaltern in einer PDF-Datei. Projektbeschreibung 3.1 Ist-Zustand Es wurde ein Prüfprogramm auf Basis von C# unter Verwendung von Visual Studio entwickelt. Dieses dient der rechnergestützten, wiederkehrenden Prüfung der analogen Rechenschaltungen der Reaktorschutzsysteme, sowie Neutronenflusssysteme der Kernkraftwerksanlagen XXXX und XXXXXX. Dieses Programm muss von den Gutachtern des TÜV entsprechend qualifiziert werden, erst dann ist das Prüfprogramm für den Einsatz dieser Prüfungen im Kernkraftwerk zugelassen. Unter Berücksichtung der Sicherheitsauflagen einer solchen Software muss gewährleistet sein, dass die Prüfergebnisse korrekt auf dem Prüfprotokoll ausgegeben werden, eine gewollte oder unbeabsichtigte Manipulation muss erschwert werden. 3.2 Soll-Konzept Als Teilprojekt des Prüfsystems entwickle ich eine eigenständige Klasse unter Verwendung von C# und der Entwicklungsumgebung Visual Studio 2010. Diese Klasse soll es ermöglichen eine bereits generierte PDF nachträglich so zu verändern, dass in ihr enthaltene Platzhalter mit den entsprechenden Werten des Prüfsystems ersetzt werden. Diese Platzhalter weisen einen definierten Nummernbereich zur exakten Identifikation der durch den Prüfbetrieb entstandenen Werte auf. Ist die Wordvorlage nun entsprechend mit Platzhaltern für die Werte versehen, wird aus ihr eine dekomprimierte PDF generiert, welche weitere Manipulationen der Messwerte durch den Benutzer im befüllten Bericht ausschließt. Die von mir zu entwickelnde Klasse soll nun diese in die Vorlage integrierten Platzhalter mit den dazugehörigen Werten entgegennehmen und die in der PDF-Protokollvorlage enthaltenen Platzhalter mit Werten befüllen. Diese Verfahrensweise hat den Vorteil, dass das Layout eines Prüfprotokolls auch ohne eine weitere Änderung des Quellcodes des Prüfprogramms angepasst werden kann. Da lediglich das Prüfprotokoll nach einer Änderung erneut qualifiziert werden muss und nicht das komplette Prüfprogramm, hält sich bei dieser Methode der Aufwand in Grenzen. Wohingegen die Qualifizierung des Prüfprogramms nach einer Quellcodeänderung erheblichen Aufwand bedeuten würde. Außerdem wird dem Kunden ermöglicht schnell und unkompliziert neue Protokollvorlagen mit allen komfortablen Möglichkeiten der Formatierung in Word zu erstellen. Projektumfeld Das Projekt wird in den Räumlichkeiten der Firma XXX bearbeitet. - Entwicklungsumgebung: Visual Studio 2010 - Eingesetztes Betriebssystem: Windows 7 32 bit - Zielsystem: Windows 7 32 bit - Programmiersprache: C# - Quellcodeverwaltung: Microsoft Visual Sourcesafe Das Projekt stellt ein Teilprojekt dar, welches in ein durch den TÜV zu qualifizierendes Prüfsystem für den Kunden XXX, integriert wird. Projektphasen Ist-/Soll-Analyse (2 Stunden) Analyse der technischen Spezifikationen und Aufbau des PDF-Formats von Adobe (20 Stunden) Erstellen eines Grobentwurfs (2 Stunden) Erstellen eines Klassenentwurfs/Feinentwurf (4 Stunden) Entwicklung eines Prototypen (4 Stunden) Entwicklung der PDF-Klasse (12 Stunden) Testen der Klasse und Fehlerkorrektur (8 Stunden) Dokumentation der Projektarbeit (10 Stunden) Erstellung der Projektpräsentation (6 Stunden) Puffer (2 Stunden) Gesamtbearbeitungszeit: 70 Stunden Dokumentation Art: Prozessorientierte Projektdokumentation Aufbau: Titelblatt Inhaltsverzeichnis 1. Einleitung 2. Problemstellung 2.1 Ist-Analyse 2.2 Soll-Konzept 3. Projektplanung 3.1 Zeitlicher Ablauf 4. Analyse des PDF-Formats von Adobe 5. Entwurf 5.1 Klassenentwurf 6. Umsetzung 7. Testphase 8. Begriffserklärung 9. Quellenangabe 10. Anlagen 10.1 Quellcodedokumentation 10.2 Anwenderdokumentation