Dotnetpro 2 2012_käfer_in_komponenten_windows_ce_kraaz

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.



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.


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.



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


Technology

Dotnetpro 2 2012_käfer_in_komponenten_windows_ce_kraaz