[FIAE] – Reicht das als Projekt

[Ralle]

Hi,

ich werde jetzt bald mein Projekt einreichen müssen.

In einem unserer Projekte haben wir eine SW entwickelt die immo nur durch eine Simulierte HW getestet werden kann.
Hier würde ich mit meinen Teilprojekt starten. Ich schreibe ein Programm welches die HW simuliert und über ein shmem (shared Memory) mit der neuen SW kommunizieren soll.
Dazu kommt dann noch der Test der von uns entwickelten SW um die Sache abzurunden. Meint ihr das reicht für ein Projekt?

Danke und Grüße
Ralle

[Angela]

Das kommt darauf an, wie umfangreich die Testsoftware ausfällt. Sind es, übertrieben gesagt, drei Zeilen Source wohl eher nicht. Reden wir hier von einigen Klassen, dann würde ich es anerkennen. Wir hatten hier schon mal ein ähnliches Projekt, das gut ankam.

[Ralle]

Habe jetzt ein Grobes Konzept ausgearbeitet.
Reicht das schon als Antrag?

1 Beschreibung
In dieser Projektaufgabe soll eine benötigte HW simuliert werden um deren neu entwickelten Treiber zu testen. Es ist nicht immer möglich die benötigte HW vor Ort zu haben.
Des Weiteren soll auch eine Testdokumentation für den Kunden angefertigt werden.

2 Ist – Zustand
Es ist ein Treiber entwickelt worden welcher eine spezielle HW verwendet. Nun soll dieser Treiber getestet werden, da die HW vom Kunden noch nicht geliefert werden kann soll diese simuliert werden.

3 Soll – Zustand
Der neu entwickelte Treiber wird nach den Vorgaben des Kunden mithilfe einer simulierten HW getestet. Die „HW“ wird durch ein Shared Memory dargestellt auf welches der entwickelte Treiber zugreift.
Des Weiteren soll ein Testprogramm geschrieben werden. In diesem wird die Vorbereitung, Durchführung und Auswertung der Testfälle realisiert.
Das Shared Memory welches die simulierte HW beschreibt soll unabhängig vom Testprogramm arbeiten. Das Testprogramm soll das Shared Memory lesen und schreiben können.

 
4 Vorgehen
4.1 Änderungen am Treiber
Das Öffnen der HW muss auf das Shared Memory umgeleitet werden. Ebenso muss der Zugriff auf das Shared Memory umgeleitet werden.

4.2 Aufbau des Testprogramms
Das Testprogramm wird die Libary des Treibers beinhalten. Es werden alle zur Verfügung stehenden Funktionalitäten getestet.
Zum einen wird das Shared Memory manipuliert und geprüft, ob der Treiber die Daten so von der Hardware liest es erwartet wird. Zu anderen schreibt das Testprogramm über den Treiber in das Shared Memory um zu prüfen, ob der Treiber alles korrekt in die „Hardware“ schreibt.
Ausgabe des Testprogramms:
1. Ausgabe auf dem Bildschirm während der Laufzeit
2. Generierung eines HTML Dokuments als Testdokumentation

6 Zeitliche Abschätzung
1. Ist – Analyse 3h
2. Soll – Analyse 3h
3. Entwicklung der simHW (shared Memory) 12h
4. Entwicklung des Testprogramms 18h
5. Testen der beiden Programme 13h
6. Testdurchführung und Erstellung Testdoku 2h
7. Soll/Ist Vergleich 4h
8. Projektabnahme 1h
9. Projektdokumentation 14h

---

– Gesamt 70h

[Ralle]

1 Thema der Projektarbeit
Simulation von HW für Tests und Durchführung der Test mit Testdokumentation

2 Geplanter Bearbeitungszeitraum
Beginn: 23.03.2014
Ende: 01.05.2014

3 Projektbeschreibung
In dieser Projektaufgabe soll eine benötigte HW, in diesem Fall bestehend aus einer DCF-Uhr
und den I/O-Schnittstellen, simuliert werden um neu entwickelte Treiber zu testen. Es ist nicht
immer möglich, die benötigte HW vor Ort zu haben.
Des Weiteren soll eine Testdokumentation für den Kunden angefertigt werden.

Ist–Zustand:
Der Treiber GPIO (General Purpose Input and Output) und eine Library zur Verarbeitung des
DCF77-Signals (DCF-Lib) sind entwickelt worden. Nun sollen der Treiber und die Komponente
zur Verarbeitung des DCF-Signals (Lib) getestet werden. Um die Tests durchführen zu können,
muss die HW, da noch nicht lieferbar, simuliert werden.

Soll–Zustand:
Der neu entwickelte Treiber und die Lib werden nach den Vorgaben des Kunden mithilfe einer
simulierten Hardware getestet. Die „Hardware“ umfasst einen gemeinsam genutzten Speicher
(engl.: Shared Memory), auf welchen der entwickelte GPIO-Treiber zugreift, und einen
DCF-Signal Generator, der das Signal im 100ms Takt in den Shared Memory schreibt.
Des Weiteren soll ein Testprogramm geschrieben werden, welches die Vorbereitung,
Durchführung und Auswertung der Testfälle realisiert.

Vorgehen:

Änderungen am GPIO:
Das Öffnen und der Zugriff auf die HW muss auf das Shared Memory umgeleitet werden.

DCF-Signal Generator:
Der DCF-Signal Generator wird die aktuelle Systemzeit lesen, auf Minuten genau in das
DCF77-Signal umwandeln und im 100ms-Takt in das Shared Memory schreiben, damit die
„DCF-Lib“ dies über den GPIO auslesen und verarbeiten kann.

Aufbau des Testprogramms:
Das Testprogramm wird die Programmbibliothek der DCF-Signalverarbeitung beinhalten. Es
werden alle Funktionalitäten zum Empfang und berechnen des DCF-Signals getestet.
Das DCF-Signal soll im Shared Memory manipuliert werden um zu testen, ob die DCF-Lib ein
fehlerhaftes Signal erkennt.

Ausgabe des Testprogramms:
1. Ausgabe auf dem Bildschirm während der Laufzeit
2. Generierung eines HTML Dokuments als Testdokumentation

4 Projektumfeld
Die softgate GmbH hat vier Abteilungen, ich arbeite in der Abteilung Emedded System. Hier
werden hardwarenahe Software-Lösungen entwickelt. Das verwendete Betriebssystem ist
kundenabhängig, in dieser Arbeit wird für das Echtzeitbetriebssystem QNX 6.5 entwickelt. Da
die Hardware nicht verfügbar ist werden die Arbeiten auf einer Virtuellen Maschine durchgeführt.

5 Projektphasen mit Zeitplanung
1. Ist–Analyse (3h)
2. Soll–Analyse (3h)
3. Entwicklung der simulierten Hardware (24h)
4. Entwicklung des Testprogramms (10h)
5. Funktionstests (13h)
6. Testdurchführung und Erstellung Testdoku (2h)
7. Soll/Ist Vergleich (4h)
8. Projektabnahme (1h)
9. Projektdokumentation (10h)
——————————————————————
– Gesamt (70h)

[Angela]

Geht aus meiner Sicht in Ordnung.

Lediglich die Testdoku finde ich mit 2h als sehr knapp kalkuliert, dagegen den Soll/Ist-Vergleich mit 4h sehr üppig. 😉

[Francis]

Ich finde es würde durchgehen.
Ich wünsche dir viel Glück !

[Autor]

Beiträge