Literaturtipp für SW-Entwicklung und Validierung

...na, dann warte erstmal auf ISO26262. würg

Klaus.

Hi Klaus2,

ich sehe, du darfst dich damit auch beschäftigen.

Wie realisierst Du dies?
Wie planst du?
Wie implementierst du?
Wie testest du?

Übrigens zu Ende eines Tests soll ein Protokoll über den Testvorgang 
erstellt werden. Die Info habe ich auch noch bekommen.

Gruss
Nobbie

Wenn du die Möglichkeit hast, schaue mal in eine Unibib.
Du wirst sicher einiges finden.

Wobei aus meiner "eingeschränkter" Sicht ein grossteil der
Entwicklungsmodell Bücher nur bla bla ist.

Aus meiner Sicht ist es produktiver/nützlicher sich mal
ein Paar Testframeworks herausgreifen und mal testen.

Testbenches sind meiner Meinung nach etwas wichtiges.
So oft man die Softwareteile/Klassen umschreiben, kann man
sich nach ein paar Zeilencode nicht mehr sicher sein, dass
man an alles gedacht hat. Da könnte man kurz 100 Tests laufen
lassen .. das berühigt ungemein :)

@Daniel:

Man darf nicht den Fehler machen eine Zertifizierung mit Tests 
gleichzusetzen. Natürlich sind saubere Tests mit einer möglichst 
vollständigen Abdeckung ein Teil eines guten Prozesses, aber da steckt 
auch noch mehr dahinter.

@Thread-Ersteller:

So hart es klingt, Standards lesen (je nach Bereich z.B. IEC 61508-3 
oder bald ISO 26262 (was 61508 etwas anders ist) für 
sicherheitsrelevante Systeme ) bringt viel Theoriewissen dazu. Das 
kombiniert man dann noch geschickt mit Sekundärliteratur wie bereits 
vorgeschlagen aus der Unibib oder einschlägigen Paperdatenbanken um 
einen Praxisbezug zu bekommen.

Die praktische Umsetzung eines solchen Prozesses, der nicht zwingend ein 
V-Modell sein muss, dies aber oft in diesem Zug genannt wird, erfordert 
viel Arbeit und meiner Meinung nach einer Art "Ausprobieren". Das 
"Ausprobieren" ist notwendig um zu sehen, wie man diese Prozesse im 
Entwickleralltag etablieren kann, ohne diese zu sehr zu belasten und vom 
Entwickeln abzuhalten.
Zu den Prozessen: Im Safety-Bereich wird in der Regel von den Standards 
das V-Modell genannt. Grundlegend muss der Prozess aber nur 
phasenorientiert sein und Verifikations- sowie 
Validationsaktivitäten/-phasen aufweisen. (Dies wird natürlich noch 
etwas präzisiert und ein paar weitere Anforderungen kommen dazu.)

Ok, konkreter Literaturvorschlag.

http://www.amazon.de/Software-Qualit%C3%A4t-Testen-Analysieren-Verifizieren-Software/dp/3827411181/ref=sr_1_4?ie=UTF8&s=books&qid=1243535408&sr=8-4

Ich habe das Buch nur auszugsweise gelesen, da ich eines bei dem Autor 
selbst in Vorlesungen gehört habe. Ich denke, dass das für den Anfang 
einen guten Überblick und evt. auch Erläuterungen zu Begriffen und 
Verfahren geben kann, die in den Normen nur hingeworfen werden oder 
veraltet sind (von der Idee aber natürlich noch brauchbar).

Ich hoffe, dir hilft das. Verschaffe dir vielleicht erstmal 2-3 Monate 
einen Überblick und mache viel Literaturarbeit. Es braucht Zeit, bis man 
mal die scheinbar einfachen Dinge (die dann doch komplizierter sind oder 
mehr dahinter steckt als man meint) in einen Zusammenhang setzen und 
richtig verstehen kann.

Bezüglich Software Engineering und Requirements Engineering sind die 
Bücher und Paper von http://www.cs.st-andrews.ac.uk/~ifs/ interessant. 
Eigentlich eines der Standardwerke in diesem Bereich.
Für Informationen über die eigentlichen Standards beziehungsweise die 
für eine Zertifizierung der Produkte benötigten Standards würde ich mal 
bei http://www.iec.ch/ stöbern. Sind allerdings nur Leseproben, 
vollständige Literatur kostet Geld. Allerdings lohnenswert, um sich 
Tipps für die weitere Suche zu besorgen.
Ansonsten nochmal beim TÜV stöbern oder die V-Modell Homepage mal direkt 
besuchen.

Abschließend noch ein Beispiellink:

http://webstore.iec.ch/preview/info_iec61508-0%7Bed1.0%7Db.pdf

Hallo,

Da es sowohl um PC wie Embedded Entwicklung geht fällt mir nur ein 
Englisches Buch ein und das wäre "Testing Embedded Software" (findet man 
bei Amazon) darin wird auch auf ein erweitertes V-Model eingegangen, das 
auf die Firmware Entwicklung zugeschnitten ist.

Allgemein würde ich mir überlegen ob man die ganze Entwicklung nicht auf 
Test Driven Development
(http://de.wikipedia.org/wiki/Testgetriebene_Entwicklung)
aufsetzt. Das sorgt zwar bei Safety Systemen für ein paar Probleme 
(Programmierer darf nicht Tester sein) mit einer richtigen 
Specifikation, an der sich sowohl der Progrmmierer wie auch der Tester 
orientieren können, sollte es jedoch auch da möglich sein.

Auf der Seite von Atomic Object (www.atomicobject.com) findet man dazu 
auch was im Embedded Bereich. Bei derem rudimentären Testframework (auf 
Rubby basierend) fehlt jedoch soweit ich es überblicken kann ein 
Coverage Analyser.
Trotzdem finde ich deren Test Ansatz für Embedded Systems nicht 
schlecht.

Gruß Crimson

Hi

@all

erst mal Danke für die hilfreichen Tipps und Links.
Wie zu erwarten wird es anscheinend ein langwieriger Prozess.

Ich denke, dass ich es zweigleisig betrachten und umsetzen muss.
Auf der einen Seite die firmwareseitige Umsetzung und auf der anderen 
Seite die PC-seitige Implementierung, usw.

Ich würde mich freuen, wenn wir diesen Thread weiterführen und uns zu 
diesem Thema weiter austauschen können.
Damit meine ich,

Welche Erfahrungen habt ihr gemacht?
Wie setzt ihr solche Dinge um?
Wie plant ihr?
Wie testet ihr?
...

Ich denke, dass dies Thema durchaus vom breiten Interesse ist.

Danke und Gruss
Nobbie

Ich würde doch auf jeden Fall mal Code Complete vorschlagen.

http://www.cc2e.com/