Systemdiagnose

[MidnightRun]

Hier nun mein derzeitiger Antrag :

Projektantrag

1.Projektbeschreibung(Ist-Zustand)

XXX ist der Anbieter von sofort einsatzfähigen Information-, Entertainment sowie Videoüberwachungssystemen für den Öffentlichen Verkehr.

In dieser Anwendungsdömane, in der sich viele verschiedene Komponenten befinden, ist es essentiell das alle Systeme fehlerfrei arbeiten und beim Auftreten von Problemen diese schnell erkannt werden um den sicheren Ablauf zu gewährleisten.

Aus diesem Grund wünscht sich XXX ein Fehlerdiagnose-System für die angebotenen Systeme. Diese sollte die Wartung vereinfachen, das auftreten von Problemen schnell erkennen aber auch dem Kunden eine höhere tranzparenz liefern.

2.Ziel des Projektes

Ziel des Projektes ist es ein erstes Konzept zu entwickeln für ein Fehlerdiagnose-System für die Angebotenen Systeme aufbauen auf der gesammelten erfahrung der Invoa Mitarbeiter über die Jahre zusammengestellt zu seiner Anforderungssammlung.

Zudem sind einige Designvorschriften einzuhalten, da XXX sich mit seinem System im Öffentlichen Verkeht befindet, ist die Vorgabe die UIC - International Union of Railways 557 (Diagnosetechnik in Reisezugwagen).

Unter berücksichtigung des bestehenden Systems und deren Komponenten soll ein erstes Prototyp Design eines Fehlerdiagnose-Systems erstellt werden.

3.Beschreibung des technischen Umfelds

Die Projektarbeit wird in den Gebäude von XXX durchgeführt. Als Entwicklungsrechner kommt ein WindowsXP System zum Einsatz.

Die Endgeräte besitzen ein Embedded Windows XP System.

Der Transferserver besitzt ein Suse Linux/? System.

Der Webserver besitzt ein Windows 2008 Server System.

Die eingesetzten Programmiersprachen in der Anwendungsdömane sind C/C++, C#, Vb.NET, ASP.NET.

Das Webportal ist aufbauen auf dem Portalframework DotNetNuke.

4.Projektphasen

1 Analyse

1.1 Analyse des derzeitigen System (Ist-Zustand)

1.1.2 Analyse der Systeme 3

1.1.3 Analyse der betroffenen Komponenten 3

1.2 Anforderungsanalyse

1.2.1 Anforderungsanalyse des Systems 5

1.2.2 Analyse der Designvorschriften 5

1.2.3 Definierung von Fallbeispielen 5

1.3 Definierung des Soll-Konzepts (Pflichenheft) 5

2 Konzept

2.1 Konzept der Schnittstellen

2.1.1 Konzept für den Diagnose-puffer erstellen 5

2.1.2 Konzept für die verschiedenen Entwertungsmöglichkeiten (Web, Lokal) etc. 5

2.2 Konzept des Datenaustauschs

2.2.1 Evaluierung der verschiedenen Möglichkeiten des Datenaustausches 5

2.3 Konzept des Datenbankentwurfs 10

3 Design

3.1 Systemdesign 10

4 Projektabschluss

4.1 Projektvalidierung

4.1.1 Entwertung des Konzepts durch die Entwickler der verschiedenen Systeme 1

4.2 Projektvorstellung 1

4.3 Erstellen der Projektdokumentation 7

5.Darstellung der eigenen Leistungen

• Analyse von Anforderungen für ein Fehlerdiagnose-System am aktuellen System(Ist-Zustand).
  
• Definierung von Anwendungsfällen unter Berücksichtigung geforderten Rechtlinien(UIC) und dem bestehenden System.
  
• Evaluierung von Lösungsansätzen in Anwendungsfällen wie Datenaustausch, Schnittstellen und Datenbank Design.
  
• Erstellung eines erstes Prototyps Designs.
  
• Ausarbeitung eines Pflichtenheftes bzw.
  

Danke nochmals für eure Hilfe die ich sehr zu schätzen weiß.

[flashpixx]

mit Diagnosepuffer meine ich die Datei die die Endgeräte schreiben sollen mit den Errorcode. Welche Daten sind wichtig in dieser Datei. Wie müssen diese Formatiert sein etc.

Das ist aber kein Puffer, siehe Puffer (Informatik) ? Wikipedia

Du hast hier eine Spezifikation, die der Hersteller des Gerätes Dir liefern sollte, d.h. dort ist beschrieben, welche Informationen wo in der Datei zu finden sind bzw wie diese zu verarbeiten sind.

Ein Puffer ist eine temporäre Speicherung von irgendwelche Daten weil z.B. ein Gerät nicht so schnell die Daten verarbeiten kann, wie sie eingehen. Wichtig hierbei ist, dass das nur temporär ist.

Die UIC, wie du schon richtig gesagt hast die "International Union of Railways", definiert genaue Beschreibungen wie Fehlerpuffer aussehen sollen damit das Wartungspersonal diese versteht.

Ich gehe nicht davon aus, dass hier ein "Puffer" definiert wird (wenn doch, einmal bitte den Link posten). Die UIC wird ein Stylguide o.ä. angeben, wie eben ein solches, ich nenne es mal Fehlerprotokoll, auszusehen hat. Genau hierbei ist wichtig zu wissen, ist das eine "may / can" Formulierung oder ist das ein "must". Zweitens ist wichtig zu wissen "wo" genau diese Vorgabe Dein Projekt berührt. Ist vorgegeben wie der Endanwender die Daten sieht oder müssen ggf Routinen intern gewisse Normen erfüllen z.B. Latenzen, Sicherheitsaspekte, Redundanzen, Ausfallsicherheit usw.

Es ist somit wichtig zu wissen, an welchen Punkten im Designprozess der Software musst Du eben externe Spezifikationen einhalten.

Bei dem Punkt Entwertungsmöglichkeiten haben schon einige aus der Entwicklung ihre Ideen eingebracht, als vor einigen Monaten das Thema Fehlerdiagnose aufkam.

siehe Entwertung ? Wikipedia

Der Begriff "entwerten" ist hier falsch, sofern man eben nicht über den gleichen Kenntnisstand verfügt. Was entwertest Du hier?

Z.B. soll das Modell Ereignisgesteuert sein ? Oder dauerhaft überprüfen ? Und darauf hin meine Lösung aufbauen.

Das ist eine konkrete Überlegung im Designprozess, wobei aber hier eben ggf die vorgeschriebenen Spezifikationen greifen. Sprich, wenn Du z.B. einen Sensor hast, der kontinuierlich Daten auswertet, dann musst Du Dir eben auch überlegen, wie oft fragst Du die Daten des Sensors ab (hier greift das Nyquist-Shannon-Abtasttheorem ? Wikipedia), d.h. bevor Du überhaupt anfängst irgendwas zu coden, musst Du erst einmal wissen, welche Art von Daten treten in Deinem System auf und mit welcher Frequenz kommen diese an. Aber Achtung, bei sehr großen Datenmengen können auch seltene Ereignisse eintreten, die Du beachten musst.

Du musst im Grunde für den Sensor den Datenraum (welche Daten können überhaupt eintreten) und die Frequenz kennen.

Der Punkt Entwertung durch Entwickler ist durch die Besitzer der einzelnen Komponenten gewünscht worden. Sie wollten sich vorab das Diagnosesystem ansehen und wissen was genau sie betrifft und neue Ideen anmerken, da aufbauen auf meine Arbeit in nächster Zeit auch wirklich das System entwickelt werden soll.

Das ist ein falscher Ansatz. Hier geht es um Spezifikationen, diese kannst Du nicht an unterschiedliche Personen /-kreise auslagern, da wird nichts definiertes heraus kommen. Du konzipierst ein System, d.h. Du musst mit allen Informationen klar kommen, d.h. Du gibst die Spezifikation vor, an die sich externe Komponenten halten müssen.

Mache es wie in der OOP, generiere eine "Basisklasse", jede externe Entwicklung kann dann auf dieser Klasse aufsetzen und diese verfeinern, aber Du hast dadurch sichergestellt, dass die von Dir vorgegebenen Strukturen vorhanden sind (ich würde hier auf XML + XSD setzen, da es wohlgeformt und plattformunabhängig ist).

Für Deine Arbeit ist es essentiell, dass Du eben klare Definitionen vor gibst, denn sonst wird das ein Fass ohne Boden und Du musst für jede Komponente händisch arbeiten. Steck' Arbeit in die Definition, da Du das Gesamtsystem, das eben alle Daten verarbeiten muss, konzipierst, alle anderen müssen sich dann an Deine Spezifikation halten (wenn sie es nicht machen, dann können sie eben nicht mit Deinem System zusammenarbeiten) und können aber diese Spezifikation weiter verfeinern (gerade in XML kann man so etwas schön via Namespaces realisieren).

[MidnightRun]

. . .

Danke flashpixx für deinen Denkanstoß,

also der Begriff Diagnosepuffer ist aus dem Meeting entstanden da es eben historisch gewachsen schon einmal da Unstimmigkeiten gab.

Natürlich ist es eine Datei wie von dir vormutet.

An welchen Punkten Punkten die externe Spezifikation meine Arbeit beeinflusst weiß ich bis dato noch nicht.

Die Idee mit der XML + XSD hatte ich auch schon im Hinterkopf

Wie bzw. wo sollte ich die Anmerkung anfügen das ich im Designprozess wieder mal eine Entscheidung machen muss zum Modell selbst ?

Danke

[flashpixx]

Danke flashpixx für deinen Denkanstoß,

also der Begriff Diagnosepuffer ist aus dem Meeting entstanden da es eben historisch gewachsen schon einmal da Unstimmigkeiten gab.

:-P Ich hätte Dir eben so etwas als fachlich falsch bewertet, denn derjenige, der Deine Arbeit liest kennt die internen Begrifflichkeiten nicht, d.h. aber für Dich, dass Du jeden Begriff, den Du verwendest dahin prüfen musst, ob Ihr da nicht eine eigene Definition verwendet. Alles was von den gängigen Standards abweicht, musst Du angeben. Das macht man z.B. über Fußnoten oder schöner über einen Glossar.

Es ist halt wichtig, dass Du klar formulierst.

An welchen Punkten Punkten die externe Spezifikation meine Arbeit beeinflusst weiß ich bis dato noch nicht.

Dann schreib das doch auch in den Antrag rein z.B. "Auswertung und Evaluierung der Spezifikationen"

Die Idee mit der XML + XSD hatte ich auch schon im Hinterkopf

Halte ich für eine sehr gute Möglichkeit. Selbst wenn ein Hersteller da seine eigene Suppe kochen möchte, dann brauchst Du eben nur einen Converter schreiben, der seine Datenstruktur in die XML Struktur überführt. Dafür hast Du aber einen klar definierte und vor allem wohlgeformte Datenstruktur.

Da man eben auch schön mit XML modellieren kann (siehe MBSE Links von mir), kannst Du aus dem XML + XSD direkt Klassencode erzeugen. Nimmst Du dann ein MBSE Tool, dann kannst Du dort dann den Methodencode einfach mit der XML Spezifikation zusammenführen. Vorteil bei Erweiterungen Du musst eben recht wenig händisch machen.

Wie bzw. wo sollte ich die Anmerkung anfügen das ich im Designprozess wieder mal eine Entscheidung machen muss zum Modell selbst ?

Ich würde bei der IST Analyse irgendwie einen Punkt setzen "Auswertung technischer Spezifikationen" o.ä. Wobei dann eben auch später ein Review rein gehört, ob die Spezifikation umgesetzt wurde. Nur weil man es ja rein schreibst heißt es ja nicht, dass es auch im Quellcode zu finden ist.

Ich würde mir aber, bevor Du den Antrag fertig schreibst, die Spezifikationen einmal anschauen und lesen. Denn wie schon gesagt, es gibt Spezifikationen, die die Geschäftsprozesse definieren bzw. deren Kontrollinstanzen. So etwas wäre für Dich kaum von Belang. Im Normalfall dauert es einige Stunden bis man so eine Spezifikation durch gearbeitet hat.

[MidnightRun]

So,

hier mein Finaler (falls noch was drin ist bitte melden) Projektantrag :

- - - - -

1. Problembeschreibung (Ist-Zustand) / Aus welchen Gründen wurde das Projekt veranlasst?

Die XXX ist im Bereich Fahrgastinformation ein Anbieter von Komplettlösungen

zur Verwaltung, Verteilung und Darstellung von multimedialen Inhalten sowie der Fahrgastinformation.

Neben der Installation und Inbetriebnahme von Systemen übernimmt die XXX auch

die Gewährleistung für den technischen Betrieb der Systeme.

XXX entwickelt und produziert Komponenten für die Verwaltung, Verteilung und

Darstellung der Inhalte. Das Spektrum des Angebots geht von der Planung der

Infrastrukturkomponenten wie Server und WLAN Netzen bis zur Entwicklung und Fertigung von

Hardwarekomponenten für den mobilen Einsatz.

Die Komponenten der Systemketten werden in unterschiedlichen Ausprägungen durch manuelle

oder teilweise auch automatische Prozesse überwacht.

Für den Betrieb aller Systeme ist es notwendig ein einheitliches Diagnosemanagement einzuführen.

Dieses soll in späteren Ausbaustufen neben der Überwachung der Systeme ein schnelles und

effizientes Verfahren zur Fehlerbehebung und Erstellung von vorbeugenden Maßnahmen aus der

Fehlerdiagnose ermöglichen.

2. Ziel des Projektes (Soll-Zustand).

Ziel des Projektes ist es ein Konzept für ein einheitliches Diagnosemanagment System zu entwickeln.

Das Konzept soll neben einem statischen Modell (z.B.: Datenhaltung, Diagnose Speicher,

Diagnoseschnittstellen) auch ein dynamisches Modell (z.B.: Datenübertragung, Signalisierung)

enthalten.

Hierbei sind die internen und externen Anforderungen aufzunehmen und bei der Konzeptionierung

zu berücksichtigen. Eine Berücksichtigung von vorhandenen Softwarelösungen oder Schnittstellen

zu diesen Systemen ist einzuhalten.

Neben diesen Anforderungen gibt es allgemein technische Standards, die zur Lösung

beitragen können.

Unter berücksichtigung des bestehenden Systems und deren Komponenten soll ein erster

Design Prototyp der Presentationschicht für ein Diagnosemanagment Systems erstellt werden.

3. Beschreibung des technischen Umfeldes / Systemumgebung – z. B.: Betriebssystem, Datenbanksystem,

Programmiersprachen, Entwicklungsumgebung.

Als Entwicklungsrechner kommt ein WindowsXP System zum Einsatz.

Die Endgeräte besitzen ein Embedded Windows XP System.

Der Transferserver besitzt ein Suse Linux/Windows 2003 Server System.

Der Webserver besitzt ein Windows 2008 Server System.

Die eingesetzten Programmiersprachen in der Anwendungsdömane sind C/C++, C#, Vb.NET, ASP.NET

Das Webportal baut auf dem Portalframework DotNetNuke auf.

4. Projektphasen in Stunden (max. 70 Std.):

1 Analyse(33 Std.)

1.1 Analyse des derzeitigen System (Ist-Zustand) 7 Std.

1.2 Anforderungsanalyse 15 Std.

1.3 Ausarbeitung der Software Requirements Specification (Soll-Zustand) 6 Std.

1.4 Auswertung und Evaluierung der Spezifikationen 5 Std.

2 Konzept (22 Std.)

2.2 Konzept der Schnittstellen 6 Std.

2.3 Konzept des Datenaustauschs 6 Std.

2.4 Konzept des Datenbankentwurfs 10 Std.

3 Design (10 Std.)

3.1 Prototyp Design 10 Std.

4 Projektabschluss (5 Std.)

4.1 Projektvorstellung 1 Std.

4.2 Erstellen der Projektdokumentation 4 Std.

Summer = 70 Stunden

5. Darstellung der eigenen Leistung und gegebenenfalls die Einordnung in das Gesamtprojekt:

- Analyse von Anforderungen für ein Diagnosemanagment System am aktuellen System.

- Definierung von Anwendungsfällen unter Berücksichtigung geforderten Rechtlinien und

Designvorschriften am bestehenden System.

- Evaluierung von Lösungsansätzen in Anwendungsfällen wie Datenaustausch, Schnittstellen und

Datenbank Design.

- Ausarbeitung einer Software Requirements Specification (Lasten- und Pflichtenheft).

- Erstellung eines erstes Designs des Prototypens, aufbauend auf der erstellten Architektur.

- - - - -

Any thoughts ? Danke

[flashpixx]

Ich find es sehr gut. Zeitplan hab ich jetzt nicht durchgeschaut, aber ich nehme an, dass er okay ist.

[MidnightRun]

Hallo Freunde

Ich bin gerade dabei meine Projektarbeit zu bearbeiten. Ich würde gerne BPMN Diagramme zur Veranschaulichung der Prozesse nutzen. Ich bin da mir aber nicht so sicher, dass ich da alles richtig mache.

Gibt es hier jemanden der mir vielleicht dabei helfen könnte ? Bzw. rüber schauen würde ob alles so richtig ist ?

Danke

[MidnightRun]

So,

ich bin nun fertig mit meinem Projekt und beginne meine Projektdokumentation. Im Laufe meines Projektes habe ich eine Software Requirements Specification erstellt. In dieser habe ich viele Grafiken, UML Diagramme z.B., verwendet zu Veranschaulichung.

Nun würde ich auch gerne diese Grafiken in meine Dokumentation eintragen. Muss ich da einen Verweis auf die SRS selbst legen ? Da sie ja dieser dann entstammen.

Die Frage nach einem BPMN Spezialisten besteht immer noch

Dankeschön