dotnetpro 2 2012_käfer_in_komponenten_windows_ce_kraaz
DESCRIPTION
Qualitätssicherung von Windows-Embedded-Compact-Projekten. Der Komponentendschungel, dem sich der Programmierer beim Entwickeln von und mitWindows Embedded Compact gegenübersieht, kann sehr schnell sehr unübersichtlich werden. Da kann so mancher Fehler unbemerkt überleben.TRANSCRIPT
72 2.2012 www.dotnetpro.de
PRAXIS
Qualitätssicherung von Windows-Embedded-Compact-Projekten
Käfer in KomponentenDer Komponentendschungel, dem sich der Programmierer beim Entwickeln von und mitWindows Embedded Compactgegenübersieht, kann sehr schnell sehr unübersichtlich werden. Da kann so mancher Fehler unbemerkt überleben.
W indows Embedded Compact, der
Nachfolger vonWindowsCE, istMi-
crosofts „kleinstes“ Betriebssystem
für Embedded-Devices. Neben Intel-Prozessoren
unterstützt das System auch MIPS- und ARM-
Prozessoren, und vor allem letztere erfreuen sich
einer weitenVerbreitung. Das echtzeitfähige Be-
triebssystem wird für internetfähige Geräte,
MP3-Player, Kameras, aber auch für Industrie-
Controller, medizinische Geräte und Heimauto-
mation verwendet – oder auch für Nähmaschi-
nen, wie Abbildung 1 bezeugt. Dabei wird Win-dows Embedded Compact gleichermaßen für
Systeme mit Display wie auch für solche ohne
Anzeige eingesetzt [1].
Durch die Modularisierung lässt sich das Be-
triebssystem genau auf den Anwendungsszweck
zurechtschneidern. In einer Minimalkonfigura-
tion benötigt es weniger als je 1 Megabyte Ar-
beits- undFlash-Speicher. Eine typischeKonfigu-
ration für ein berührungsempfindliches Bedien-
terminal bewegt sich im Bereich von 8 bis 16Me-
gabyte Flash-Speicher; die Konfiguration eines
Geräts heißt in der Fachsprache„OS-Design“.Die
Entwicklung am Betriebssystem erfolgt mit dem
Visual-Studio-Plug-in Platform Builder.
Windows Embedded Compact muss aber
nicht nur im Funktionsumfang, sondern auch
bei der Unterstützung verwendeter Hardware
großeVariabilität beweisen. Dazu dient das soge-
nannte Board Support Package (BSP). Der Begriff
bezeichnet die Zwischenschicht zwischen dem
allgemeinen Betriebssystemkern und der Hard-
ware. Im BSP erfolgt die Anpassung an den ver-
wendeten Prozessor, an spezielle Funktionen ei-
nes Geräts und generell an das Board, also die
Platine. Den größtenTeil des BSP dürften die Ge-
rätetreiber ausmachen.
Vom Evaluations-Kit zum fertigenDeviceAuf dem Markt gibt es zahlreiche Evaluations-
Kits für Prozessoren oder Hardwarekomponen-
ten, die ein ImagemitWindows EmbeddedCom-
pact enthalten. Mit diesen Evaluations-Kits lässt
sich innerhalb von Minuten das Betriebssystem
auf der Hardware installieren und starten und
das Zusammenspiel vonHardware und Software
testen.Verläuft derTest der jeweiligenHardware-
komponenten zur Zufriedenheit, kann die Ent-
wicklung der eigenen Hardware beginnen: Der
Formfaktor wird angepasst; Prozessoren und
Speicher werden vergrößert, um mehr Leistung
herauszuholen, oder verkleinert, um Kosten zu
sparen; und auch die Anschlüsse zu Peripherie
und Spannungsversorgung müssen angepasst
werden.
Meist lassen sich die benötigten Anwendun-
gen bereits auf dem Evaluations-Kit vorentwi-
ckeln, bis die endgültige Hardware verfügbar ist.
Und natürlich ist das BSP an die veränderte
Hardware anzupassen. Sobald Hardware, BSP
und Anwendung entwickelt und getestet sind,
kann das fertige Gerät ausgeliefert werden. So
weit zumindest der Plan.
Wer bis hierhin aufmerksam gelesen hat, wird
zumindest einemverbreiteten Irrtumnichtmehr
aufsitzen:Windows Embedded Compact kommt
nicht fix und fertig von Microsoft – das wäre bei
dem Variantenreichtum von Hardware für Em-
bedded-Systeme schlichtweg unmöglich. Insbe-
sondere die eigene entwickelte Hardware wird
wahrscheinlich nicht ohne Programmierauf-
wand sofort mit der Unterstützung aller Hard-
waremerkmale laufen.
Wie bereits angedeutet, muss ein Board Sup-
port Package für dieHardware entwickeltwerden,
damit Windows Embedded Compact auf der
Hardware laufen kann. Es spricht nichts dagegen,
ein fertiges BSP für eine ähnlicheHardware anzu-
passen; auch der reichhaltige Beispiel- und Bi-
bliothekscode vonMicrosoft kann als Grundlage
dafür dienen (Abbildung 2).
Auf einen Blick
Matthias Kraaz beschäftigtsich bei Zühlke mit dem auto-matisierten Testen von Medizin-technik-Geräten und anderenEmbedded-Systemen.Sie erreichen ihn ü[email protected].
Inhalt� Mit dem Board SupportPackage arbeiten.
� Das Test-Framework TUX.� Evaluations-Kits und automa-tisierte Tests.
� Externe Dienstleister.
Serie1. Qualitätssicherung von
Windows-Embedded-Projek-ten
2. BSPs für Windows CEentwickeln
A1202Embedded
dnpCode
[Abb. 1] Gar kein ungewöhnliches Anwendungsbeispiel:
eine Nähmaschine mit Windows CE.
072dnp_Embedded_ws2_jp_ws_sb_ws.qxp:Layout 1 22.12.2011 11:05 Uhr Seite 72
www.dotnetpro.de 2.2012 73
PRAXIS
Die Hardware für Embedded-Windows
beherrscht in der Regel einige für sie einzig-
artige Funktionen, die von den Applikatio-
nen aus benutztwerden sollen.Diese Funk-
tionenwerden den Anwendungen dann oft
über ein speziell entworfenes Plattform-API
zurVerfügung gestellt.
Wenn das BSP fertig ist, wird das OS-De-
sign erstellt, das Image gebaut und auf die
Hardware gespielt. Dieser Schritt erfolgt
während der Entwicklungsphasemeist be-
quemaus demPlatformBuilder herausmit
Unterstützung durch den Bootloader, der
ebenfalls zum BSP gehört.
Es empfiehlt sich, frühzeitig über die
Handhabung in der Geräteproduktion und
über Updates im Feld nachzudenken. Die
Produktion muss in die Lage versetzt wer-
den, mit ihren Mitteln das Image effizient
auf die Hardware zu überspielen. Auch das
Aktualisieren von Geräten „draußen“ beim
Nutzer sollte robust und einfach sein. Dazu
musseventuell dasFormatdes Imagesgeän-
dert oder ein zusätzlicher Mechanismus
zumAufspielen entwickelt werden.
Komponenten wollen geprüft seinDie vonMicrosoft gelieferten allgemeinen,
hardwareunabhängigen Merkmale von
Windows Embedded Compact haben die
größte Verbreitung. Dieser Code wird von
den meisten Entwicklern auf den meisten
Geräten verwendet, und so sind hier die
wenigsten Fehler zu erwarten.Nichtsdesto-
trotz vergeht kaum ein Monat, in dem Mi-
crosoft nicht zahlreiche Korrekturen für
diesen Teil des Systems bereitstellt. Diese
monatlichen Fehlerbereinigungen werden
als Quick Fix Engineering (QFE) bezeich-
net. Es lohnt sich, die Veröffentlichung der
QFEs auf Fehler hin zu beobachten, die die
eigene Entwicklung betreffen könnten [2].
Bei einschlägigen Anbietern gibt es BSPs
schon für wenigeTausend Euro. Sie sind auf
eine bestimmte Hardware, meist die eines
Evaluations-Kits, abgestimmt und dienen in
der Regel als Basis für die eigene Entwick-
lung.Dieser günstigePreis ist normalerweise
mit dem Hinweis verbunden, dass das BSP
für Lehre, Evaluation oder Prototypentwick-
lunggedacht ist.DieserHinweis ist sehrernst
zu nehmen: Er bedeutet, dass für die Pro-
duktentwicklung noch einiges an Arbeit in
die Stabilisierung undQualitätssicherung zu
investieren ist, bis der übernommene Code
Produktionsqualität erreicht hat. In diesem
Zusammenhang empfiehlt es sich allerdings
immer, eine detaillierte Dokumentation der
Interna des BSP inklusive einer Liste von
SchwächenundLücken zu verlangen.
Auchwenndas gleiche BSP schonmehr-
fach anderen Firmen als Ausgangsbasis ge-
dient hat, muss das nicht zurVerbesserung
derQualität des Layers geführt haben.Dies
ist wahrscheinlich nur dann der Fall, wenn
der Hersteller des BSP über Fehler infor-
miert wurde unddiese behoben hat. Daher
empfiehlt es sich, genauestens zu prüfen,
welche Teile davon in welchem Umfang
der Qualitätskontrolle unterliegen.
Die meisten BSPs enthalten Code aus
dreierlei Herkunft:
� hardwareunabhängiger Framework-Code
vonMicrosoft,
� Code für eine bestimmte CPU-Familie
wie x86, ARM et cetera, oder einen Pro-
zessortyp wie etwa eine System-on-a-
Chip-CPU, sowie
� Code, der eigens für einbestimmtesBoard
entwickelt wurde.
Je spezieller der Code, desto ausführli-
cher sollten die Tests sein. Am kritischsten
zu betrachten ist der Code, der für eine be-
stimmte Evaluations-Kit-Hardware erstellt
wurde. Abbildung 3 zeigt den Aufbau desPLATFORM-Verzeichnisses und den unge-
fähren Reifegrad der verschiedenen Be-
standteile des Platform Builders, die darin
zu finden sind.
Selbst wenn das übernommene BSP aus-
reichend getestetworden ist, sollten sich bei
einer Anpassung die eigenenTests nicht nur
auf die neuen oder geänderten Funktionen
beschränken.EineAnpassungdesBSPanei-
nerbestimmtenStelle kannganzandereTei-
le des Pakets in Mitleidenschaft ziehen. Am
besten ist es, alle verwendetenTeile des BSP
wie schon oben beschrieben zu testen.
Unter Windows EmbeddedCompact testenBeimTest eines BSP ist das Test-Kit vonMi-
crosoft immens hilfreich, insbesondere das
enthaltene FrameworkTUX, das die großen
Test-Suiten von Microsoft unterstützt. Da
diese Suiten enormen Speicherbedarf ha-
ben, der Speicher auf einem Test-Kit aber
beschränkt ist, lädt das Framework dieTests
einzeln auf das Gerät, führt sie aus und ent-
fernt sie wieder. Vor allem enthält das Test-
Kit schon eine große Menge von TUX-Tests
fürGerätetreiber verbreiteterHardwareklas-
sen wie Display, Flash-Speicher, Ethernet-
Anschlussundvielemehr.Das Schreiben ei-
gener Tests gestaltet sich nicht schwieriger
als bei den gängigen Test-Frameworks.
Außerdementhält dasTest-Kit noch eine
Reihe vonWerkzeugen:
� Der Application Verifier prüft die Frei-
gabe von Speicher und anderen System-
ressourcen.
� Das Windows CE Stress Tool lässt Tests
im Dauerbetrieb laufen.
� CPU Monitor zeigt die CPU- und Spei-
cher-Auslastung an.
[Abb. 2] Windows Embedded Compact besteht aus Micro-
softs Betriebssystemkern, dem teilweise selbst geschriebe-
nen BSP und den selbst geschriebenen Applikationen.
[Abb. 3] Eine
schematische
Darstellung der
Verzeichnisstruk-
tur des Platform
Builders und
eine grobe
Einschätzung
des Reifegrads
des Inhalts.
072dnp_Embedded_ws2_jp_ws_sb_ws.qxp:Layout 1 22.12.2011 11:05 Uhr Seite 73
74 2.2012 www.dotnetpro.de
PRAXIS _Qualitätssicherung von Windows-Embedded-Compact-Projekten
Funktionale Tests sind notwendig, rei-
chen aber nicht aus. Besser ist es, wenn bei-
spielsweise Langzeittestsmit einerÜberwa-
chung des Speicherverbrauchs einherge-
hen, umSpeicherlecks zu finden; Stresstests
wie die gleichzeitige Belastung aller Treiber
oder die dauerhafte starke Belastung eines
Treibers sind ebenfalls sinnvoll.
Wird einmal ein Fehler gefunden, ist ein
Regressionstest für ihn ebenfalls sehr sinn-
voll. Die Erfahrung zeigt, dass schon die
nächste Fehlerbehebung (am selben Trei-
ber) einen bereits behobenen Fehler wie-
der einführen kann.
Schnittstellenprobleme zwischenApplikation und HardwareRegelmäßig gibt es Missverständnisse bei
derVereinbarungder Schnittstelle zwischen
Applikation und Hardware, also dem Platt-
form-API. EineMöglichkeit, demvorzubeu-
gen, ist das Erstellen einer Spezifikation in
Form von ausführbaren Schnittstellentests,
die das gewünschte Verhalten der Schnitt-
stelle prüfen.DieseTests dienengleichzeitig
auch als Dokumentation der Schnittstelle
und ebenso der Qualitätssicherung.
Es gibt zwei Möglichkeiten, diese Tests
zu erstellen. In der einen Variante schrei-
ben die Autoren, die BSP und Schnittstel-
lenspezifikation erstellen, auch die Tests
dafür. In der anderen Variante schreiben
die Entwickler der Anwendungen, die auf
das BSP zugreifen, die Schnittstellentests
und spiegeln auf dieseWeise ihr Verständ-
nis der Schnittstellenspezifikation wider.
Nicht zuletzt verdienenPlattform-APIs ei-
nen besonders hohenTestaufwand, da hier
naturgemäßdermeisteneueCodeentsteht.
Die Testpyramide: Unit-TestsSehr effizient ist das agile Konzept derTest-
pyramide auch bei Embedded-Projekten;
der Autor des Artikels wendet es mit gro-
ßemErfolg in der täglichenArbeit an [3] [4].
Dieses Konzept sieht vor, dass der größte
Teil der Tests auf der Ebene der Unit-Tests
erfolgt. Hier werden die kleinsten, nicht
weiter sinnvoll zerlegbaren Einheiten des
Systems getestet, zum Beispiel ein einzel-
ner, nicht allzu komplexerTreiber. DerVor-
teil von Unit-Tests gegenüber Tests von
größeren Einheiten ist der geringe Auf-
wand bei der Suche und Behebung des
Fehlers imCode. Gleichzeitig ist die Stimu-
lation der zu testenden Einheit einfacher
und es sind beispielsweise Grenzwerttests
möglich, ohne dass andere Komponenten
die eventuell ungültigen Werte vom Test-
kandidaten fernhalten.
Die vorgetesteten Einheiten werden
schrittweise zusammengeführt und getes-
tet. Bei den Integrationstests dieser Units
kommt es dann zu wesentlich weniger
Fehlern als bei noch ungetesteten Einhei-
ten. Diese Fehler ergeben sich dann meis-
tens aus dem Zusammenspiel der Einhei-
ten und nicht aus deren intrinsischen Feh-
lern. Mit diesemWissen lassen sich in den
Integrationstests die meisten Fehler we-
sentlich schneller finden und beheben.
Dieses Vorgehen setzt sich schrittweise
fort, bis das System zusammengestellt ist.
Die letzte Stufe dieser Integrationstests ist
dann der Systemtest. Durch die vorherge-
hendenTestläufe lässt sich der Aufwand für
die Systemtests dramatisch reduzieren (Ab-bildung 4).
Auf jeder „tieferen“Testebene ist es noch
möglich, von der Hardwareumgebung zu
abstrahieren; spätestens auf der Ebene der
Systemtests ist die Peripherie, die von der
untersuchten Software kontrolliert wird,
nicht mehr herauszuhalten: Beim System-
test lassen sich die Treiber für die Kommu-
nikation mit der Peripherie per definitio-
nem nicht weglassen. Als System gilt hier-
bei das Board mit der darauf laufenden
Firmware.
Die Peripherie macht das Automatisie-
ren der Softwaretests gleichzeitig schwieri-
ger und lohnenswerter. Denken Sie nur an
eine Heizungssteuerung: Sie direkt zu tes-
ten – und damit in Echtzeit – hieße ja, tat-
sächlich die Raumtemperatur anzuheben
und zu senken. Mit diesem Testverfahren
würde die Entwicklung derHeizungssteue-
rung ewig dauern.
Auch aus anderen Gründen kommt der
Automatisierung von Systemtests eine be-
sondere Bedeutung zu: Sie sind die einzi-
gen Tests, die immer ausgeführt werden.
Alle anderenTests fallen aus verschiedens-
ten Gründen schon mal unter den Tisch.
Systemtests sind sozusagen die Nagelpro-
be, ob das System funktioniert und ausge-
liefert werden kann.
Systemtests sollten zudem so früh wie
möglich erfolgen. Nur dann besteht die
Chance, Fehler in der Hardwarearchitektur
oder der Software so rechtzeitig zu erken-
nen, dass sie sich noch beheben lassen.
Jedenoch sokomplizierte Peripherie lässt
sich glücklicherweise auf die elektrischen
Signale an der Schnittstelle zum Board re-
duzieren.Tests, die sonst die Peripherie ein-
bezögen, werden mittels Simulation und
Messung der entsprechenden elektrischen
Signale automatisiert. Für diese Simula-
tions- und Messaufgaben gibt es auf dem
Markt ein reichhaltigesAngebot vonLösun-
gen der Mess- und Automatisierungstech-
nik,mit derenHilfe sich ein passendesTest-
system komplett aus fertiger Hardware und
Software zusammenstellen lässt. Dabei
empfiehlt es sich, auf PXI-Systeme zu set-
zen: PXI (PCI eXtensions for Instrumenta-
tion [5]) ist einmodulares System für Steck-
kartenmitMess- undAutomatisierungsauf-
gaben. In der Regel bieten dieHersteller zur
PXI-Steckkarte eine Testumgebung, die die
Steckkarten ansteuert und die Tests aus-
führt.Das fertigeTestsystembestündedann
beispielsweise aus einem Standard-PC mit
der Testumgebung, einem PXI-Chassis und
den passenden PXI-Steckkarten.
Allerdings ist meistens noch eine Signal-
anpassung zwischen Testsystem und Board
[Abb. 4] Die Ebenen der Testpyramide bauen
aufeinander auf und ergeben zusammen die
nötige Testabdeckung.
Wie bei der Pyramide muss aber jede
„Testschicht“ sorgsamgelegtwerden, sonst
bricht das ganze Bauwerk zusammen. Nur
Unit-Tests mit einer hochgradigen Testab-
deckung ermöglichen es tatsächlich, sich
bei den Integrationstests auf die Probleme
des Zusammenspiels der verschiedenen
Teile zu konzentrieren.
Tests automatisierenAuf allen Stufen der Testpyramide ein-
schließlich der Ebene der Systemtests ist ei-
ne Automatisierung der Tests sinnvoll. Sie
hat zwei Effekte: Zum einen verringert sie
denTestaufwand,daderhöhereAufwandzu
Beginn sich nach ein paarWiederholungen
der Tests amortisiert; zum anderen können
automatisierteTestswesentlichhäufiger lau-
fen, sodass Fehler viel schneller gefunden
werden. Je früher aber ein Fehler gefunden
wird, nachdemer sich indie Software einge-
schlichen hat, desto einfacher haben es die
EntwicklermitderFehlersuche,weil derAuf-
wand pro Fehlerbehebung sinkt.
072dnp_Embedded_ws2_jp_ws_sb_ws.qxp:Layout 1 22.12.2011 11:05 Uhr Seite 74
PRAXIS
erforderlich. Diese Adaption erfolgt am
besten mit einer Adapterplatine, die wäh-
rend der Hardwareentwicklung mit gerin-
gem Zusatzaufwand gleich mitentwickelt
werden kann. Ein Beispiel für solch einen
Testaufbau zeigt Abbildung 5; hier ist die
neu entwickelte Hardware links im Bild zu
sehen, die Adapterplatinen rechts im Bild.
Die Tests mit der simulierten Peripherie
können natürlich nicht die Tests mit der
echten Peripherie ersetzen, aber ihre An-
zahl drastisch reduzieren.
Das Display testenEine weitere Hürde auf demWeg zur Test-
automatisierung stellen Displays dar, die
auf dem Board eines Evaluations-Kits an-
gebracht sind.Hier stellt sich die Frage, wie
sich die Prüfung so automatisieren lässt,
dass die Software während des Tests kor-
rekte Anzeigen produziert.
Hierzu ist entweder das Signal auf sei-
nem Weg zum Display abzugreifen oder
aber das Display mit einer Kamera zu fil-
men. Das Filmen ist am einfachsten, setzt
aber eine entsprechend komplizierte Bild-
erkennung voraus, um falsche von richti-
gen Anzeigen zu unterscheiden. Je nach
Projekt kann dieses Verfahren aber durch-
aus sinnvoll sein.
Am einfachsten ist die Prüfung der An-
zeige, wenndie Bildschirmausgabe vonder
zu testenden Software parallel auf eineDa-
tenschnittstelle übertragen wird. Hierbei
stellen sich allerdings schnell Problememit
der Bandbreite ein.
Eine weitere Möglichkeit ist, das Signal
direkt vor demDisplay abzugreifen unddie
Logik des Displays nachträglich zu imple-
mentieren.
[Abb. 5] Hier ist die getestete Hardware per Adapterplatine am Testsystem angeschlossen.
072dnp_Embedded_ws2_jp_ws_sb_ws.qxp:Layout 1 22.12.2011 11:05 Uhr Seite 75
76 2.2012 www.dotnetpro.de
PRAXIS _Qualitätssicherung von Windows-Embedded-Compact-Projekten
Fehler im PUBLIC-VerzeichnisTests werden unweigerlich Fehler finden –
das ist nunmal ihr Zweck. Solange diese im
Board Support Pack lokalisiert sind, ist ih-
re Korrektur nicht sonderlich schwierig.
Mitunter ergeben sich jedoch Fehler in den
Microsoft-Komponenten im PUBLIC-Ver-
zeichnis. Dann ist zuerst zu prüfen, ob
Microsoft schon einen Patch, also einen
QFE (siehe oben), dafür bereitstellt. Diese
Korrekturen fasstMicrosoftmonatlich und
jährlich zu sogenannten Roll-ups zusam-
men, die das Aktualisieren einer Platform-
Builder-Installation beschleunigen. Ist
noch kein QFE verfügbar, ist ein Fehlerbe-
richt an Microsoft mit einer Anleitung zur
Reproduktion durchaus sinnvoll, um eine
Fehlerbehebung zu erreichen.
Für viele PUBLIC-Komponenten ist der
Quellcode vorhanden, sodass der Entwick-
ler selbst den Fehler beheben kann. Dazu
ist die Komponente zunächst unter dem
Verzeichnis PLATFORM als Kopie anzule-
gen. In der „geklonten“ Komponente lässt
sich dann der Fehler ohneGefahr vonKon-
flikten ausbügeln, wenn später neue QFEs
unter PUBLIC eingespielt werden.
DieserWeg funktioniert allerdings nicht,
wenn die fehlerhafte Datei nicht zu einer
Komponente gehört – das betrifft zumBei-
spiel die Build-Skripte unterPUBLIC – oder
wenn die Komponente nicht kopierbar ist.
Dann führt nichts an einer Änderung di-
rekt im PUBLIC-Verzeichnis vorbei.
Bei FehlerbehebungenunterPUBLIC, sei
es per QFE oder durch eigene Änderungen,
muss sichergestellt sein, dass die Korrektur
alle Arbeitsplätze im Unternehmenmit ei-
ner Platform-Builder-Installation erreicht.
Nicht allein zu diesem Zweck empfiehlt es
sich, den gesamtenWINCEx00-Dateibaum
(das Wurzelverzeichnis einer Platform-
Builder-Installation) inklusive desPUBLIC-
Verzeichnisses trotz der beachtlichen Grö-
ße von mehreren Gigabyte unter Versions-
verwaltung zu stellen.Meist schreckt dieser
Schritt zunächst ab, die Erfahrung hat je-
doch gezeigt, dass dieVorteile langfristig al-
le Unannehmlichkeiten aufwiegen.
Ein Teil des Codes ist noch im PRIVATE-
Verzeichnis zu finden. Zwar wären die
meisten Komponenten dort übersetzbar,
prinzipiell dient der Code jedoch nur zum
Verständnis und zum Debugging. Ände-
rungen hier sind unwirksam.
Vergabe des BSP an einenexternen DienstleisterDie Erfahrung hat gezeigt, dass es bei der
Vergabe des BSP an einen externenDienst-
leister immer wieder zu denselben Proble-
men kommt, die sich aber durchaus lösen
lassen. In erster Linie ist eine klare Aufga-
benverteilung sicherzustellen. Dies be-
ginnt mit der Frage, in welchem Umfang
der Dienstleister selbst testet. Stehenmeh-
rere Dienstleister zur Auswahl, empfiehlt
es sich gerade bei wesentlich günstigeren
Angeboten zu prüfen, inwieweit Qualitäts-
sicherung dabei inbegriffen ist.
Esmag zwar für denAuftraggeber selbst-
verständlich sein, nur intensiv getestete
Software auszuliefern. Allerdings ist auch
die Ansicht anzutreffen, dassman ja sowie-
so erst dann richtig testen kann, wenn
Hardware, Peripherie, BSP und Applikatio-
nen verfügbar sind, also auf Systemebene.
Dementsprechend könnte ein Dienstleis-
ter davon ausgehen – und tut es mitunter
auch –, dass hauptsächlich der Auftragge-
ber testet, weil ja ohnehin nur bei ihm alle
Komponenten verfügbar sind.
Der Auftraggeber sollte Einblick in die
Tests des Dienstleisters erhalten. Zum ei-
nen ist dies wichtig, umdieQualitätssiche-
rung zu überwachen. Zum anderen kann
der Review der Tests des Dienstleisters
Missverständnisse bei der Schnittstellen-
vereinbarung aufdecken. Die Tests des
Dienstleisters können zudem als Grundla-
ge für eigene Tests dienen.
Die Erfahrung zeigt, dass eine BSP-An-
passung meist in wesentlich mehr Versio-
nen als ursprünglich geplant erfolgt, sodass
sich auch hier der Aufwand für die Automa-
tisierung der BSP-Tests schnell amortisiert.
Dazu eignet sich beispielsweise das schon
genannte TUX-Framework vonMicrosoft.
Findet der Auftraggeber einen Fehler im
BSP, empfiehlt es sich, den Bugmithilfe ei-
nes kleinen Testfalls dem Dienstleister zu
demonstrieren und um Behebung zu bit-
ten. Dieser Testfall kann dann auch gleich
in die – mittlerweile hoffentlich große –
Suite von BSP-Regressionstests aufgenom-
men werden.
Dienstleister, die BSPs erstellen, nehmen
oft ganz natürlich an, dass sich der Auftrag-
geber selbst um das OS-Design kümmert,
weil dazudie genaueKenntnis nötig ist, was
die Applikationen vonWindowsEmbedded
Compact benötigen. Technisch gesehen ist
es gar nicht falsch, dass das Erstellen des
OS-Designs beim Auftraggeber stattfindet,
dazu muss dieser aber entsprechendes
Know-how aufbauen. Im anderen Fall, also
wenn sich das Erstellen des OS-Designs
unddes Images zumDienstleister verlagert,
kommt es erfahrungsgemäß regelmäßig zu
ungeplanten Extralieferungen des Systems,
die zu begutachten sind. In jedem Fall soll-
te die Aufgabenverteilung vorab geklärt
und nicht den Annahmen der beteiligten
Parteien überlassen werden.
Und noch ein Punkt ist zu bedenken.
Probleme mit fremderstellten Artefakten
tauchen nicht immer sofort auf, sondern
oft erst, wenn die eigenen Entwickler die
entsprechenden Funktionen in Betrieb
nehmen. Eventuell sind dieMitarbeiter des
Dienstleisters dann aber schon mit einem
ganz anderen Projekt beschäftigt und die
Fehlerbehebung verzögert sich. Daher soll-
te mit dem Dienstleister ein Service Level
Agreement vereinbart werden, wie schnell
er nach derMeldung eines Fehlersmit des-
sen Behebung beginnt oder wie schnell er
Unterstützung anbietet, wenn der Auftrag-
gebermit demBSP desDienstleisters nicht
zurechtkommt. Eine solche Vereinbarung
muss der Dienstleister natürlich in seiner
Kalkulation berücksichtigen, ist damit aber
allemal günstiger als ein blockiertes Team
oder stillstehende Produktionsbänder.
ResümeeBeim Entwickeln eines Geräts mit Win-
dows Embedded Compact sind eine ange-
messeneQualitätssicherung und eine klare
Aufgabenverteilung essentiell für den Er-
folg des Projekts. Dazumuss klar sein, wel-
che Softwarekomponenten in unterschied-
lichen Reifegraden in das Endprodukt ein-
gehen. Entsprechend ist eine Teststrategie
gemäßdemaktuellen Stand derTechnik zu
entwickeln, basierend auf dem Konzept
der Pyramide. Tests sollten auf allen Ebe-
nen der Testpyramide automatisiert wer-
den, auf Integrations- und Systemtest-Ebe-
ne und mithilfe von entsprechenden Test-
systemen, welche die Peripherie simulie-
ren. Finden diese Punkte Beachtung, so
sollte es kein Problem sein, die Leistungs-
fähigkeit von Windows Embedded Com-
pact in den Produkten auszureizen und sie
im geplanten Zeit- und Budgetrahmen auf
denMarkt zu bringen. [jp]
[1] Windows Embedded,www.dotnetpro.de/SL1201Embedded1
[2] Windows Embedded, Monthly Updates forCompact 7 - What’s New,www.dotnetpro.de/SL1201Embedded2
[3] The Tar Pit, Test Automation Pyramid,www.dotnetpro.de/SL1201Embedded3
[4] Mike Cohn, Succeeding While Agile,Software Development Using Scrum,ISBN 978-0-321-57936-4
[5] Wikipedia, PCI eXtensions for Instrumentation,www.dotnetpro.de/SL1201Embedded4
072dnp_Embedded_ws2_jp_ws_sb_ws.qxp:Layout 1 22.12.2011 11:05 Uhr Seite 76