Informatik-Abschluss 2009

Beste Schweizer Abschlussarbeiten

2

Die besten Informatik-Abschlussarbeiten des Jahres 2009

Wie kommt es zu diesen Arbeiten?

Die Informatik-Grundbildung wird mit einer 2-wöchigen “individuellen praktischen Arbeit” abgeschlossen, der IPA. Während dieser belegen die Absolventinnen und Absolventen der 4-jährigen dualen Lehre, der verkürz-ten dualen Zweitausbildung und der 4-jährigen schulischen Bildung, die nach Berufsbildungsreglement mit einem min. 220-tägigen Praktikum in einem Betrieb abgeschlossen wird, dass sie nun Fachleute geworden sind. Die IPA wird im letzten Semester der Grundbildung ausgeführt, im Einsatzgebiet des letzten Grundbil-dungsjahres. Die Aufgabe wird vom Betrieb gestellt und von Validierungsexperten der kantonalen Prüfungskommission auf ihre Eignung überprüft und allenfalls so lange zurückgewiesen, bis diese den Anforderungen entspricht. Auf diese Weise wird sichergestellt, dass alle Lernenden eine einigermassen gleich komplexe Arbeit be-kommen und dass diese eben die Ausbildungsziele der Informatik-Grundbildung auch erfüllt. Die Arbeit wird im gewählten Zeitraum durchgeführt und von einem Fachexperten begleitet. Der Verantwort-liche des Betriebes, der Fachvorgesetzte, nimmt die Arbeit ab und beurteilt/benotet diese ebenso wie der Experte. Sind sich beide einig, gilt diese, sonst wird die Arbeit dem Chefexperten vorgelegt. Hohes Niveau

Während der 4-jährigen Lehre besuchen die Lernenden an 2 Tagen pro Woche die Berufsfachschule. An dieser und in den „überbetrieblichen Kursen“ erlernen sie die Grundkompetenzen des Berufes. Während 1200 bis 1400 Lektionen durchlaufen sie rund 30 Module - handlungsorientierte Einheiten, die sich an be-trieblichen Aufgaben orientieren. Beispielsweise “einen Internetserver in Betrieb nehmen” für Systemtechni-ker und Supporter oder “eine Applikation objektorientiert entwerfen und implementieren”. Während den rund 2 ½ Jahren betrieblichen Einsatzes werden sie in die betrieblichen Aufgabenstellungen eingeführt und an täglicher Arbeit sukzessive zu Fachpersonen. Es ist das Ziel des dualen Bildungssystems, dass die Lernen-den im 3. Lehrjahr (von 4) ungefähr 60% des Leistungsbeitrages einer Fachperson leisten und im letzten Lehrjahr sollten sie 80% erreichen. Nach der Lehre werden sie ja als Fachleute angestellt - teilweise mit doch beachtlichen Salären. Entsprechend belegen die Grundbildungsabsolvent/-innen mit ihrer IPA, dass sie in der Tat Fachleute ge-worden sind - nicht alle leider, doch zunehmend viele. Diese Broschüre belegt die hohe Kompetenz der Ab-schlussarbeiten. Es lohnt sich die Arbeiten anzusehen. Wie werden die besten Abschlussarbeiten auserwählt?

Im Sommer 2009 haben rund 2’200 Damen und Herren ihre Informatik-Grundbildung abgeschlossen. Die besten Arbeiten aus jedem Kanton wurden durch die Chefexpertenkonferenz nochmals untereinander vergli-chen und die besten 23 daraus bestimmt. Da die Absolvent/-innen der Generalisten-Lehre allesamt entwe-der an Systemen arbeiteten oder Applikationen entwickelten, fielen die Arbeiten in die entsprechende Be-rufsfeld-Gruppe. Die Verfasser der besten 10 Applikationsentwicklungen, 10 Systemtechnik-Projekten und 3 Supporter-Prüfungen wurden am 20. Oktober 2009 anlässlich der Rangverkündigung an den Comdays in Biel geehrt. Auszeichnung der Besten Abschlussarbeiten als Leistungsanerkennung

Wer gute Arbeit leistet, soll dafür belohnt werden. Die Auszeichnung der besten Abschlussarbeiten des Jah-res soll diejenigen Absolventen, die durch ihre Arbeiten positiv auffallen, entsprechend belohnen. Mit der Auszeichnung der besten Arbeiten in jedem Kanton und danach der ganzen Schweiz wollen wir auch die Qualität der Grundbildung positiv beeinflussen. Der Vergleich unter den Absolventen und unter den Kanto-nen stellt zudem eine interkantonale Nivellierung sicher. Berufsmeisterschaften und Auszeichnung der bes-ten Arbeiten sind zudem Talentförderungsmittel, sie sollen helfen, den Sprung von der Grundbildung in die Informatik-Karriere möglichst positiv zu sichern. Und wer aus dem Nebel des Durchschnitts hervorragt, ist am Arbeitsmarkt begehrt. Wir freuen uns, Ihnen diese Facharbeiten präsentieren zu dürfen und danken allen Betrieben, den Lernen-den und den Experten für ihr Engagement in der Berufsbildung. SwissICT, Fachgruppe Lehr- und Praktikumsbetriebe

Alfred Breu

3

RANGLISTE

APPLIKATIONSENTWICKLUNG

1. Rang Baechler Loic, IPA Kanton FR, Ecole des métiers de Fribourg 5

2. Rang Meuwly Reto, IPA Kanton FR, Ecole des métiers de Fribourg 6

3. Rang Wegberg Gregor, IPA Kanton ZH, SIX Swiss Exchange AG 7

Alessandri Dominik, IPA Kanton ZG, Siemens Schweiz AG nicht publ.

Bracher Patrick, IPA Kanton BE, Swisscom AG 8

Kury Nicolas, IPA Kanton JU, Ecole des métiers techniques Porrentruy 9

Sebel Michael, IPA Kanton BE, Intersim AG 10

Vogt Michael, IPA Kanton ZH, ISE AG Informatik Solutions Einsiedeln 11

Wicht Maxime, IPA Kanton FR, Ecole des métiers de Fribourg 12

Zähringer Yann, IPA Kanton VS, Polyright SA 13

SYSTEMTECHNIK

1. Rang Csontos Robin, IPA Kanton BE, SQS 15

2. Rang Banz Andreas, IPA Kanton LU, Stadt Luzern 16

3. Rang Cioccarelli Ramona, IPA Kanton BE, Bundesamt für Information und

Telekommunikation 17

Brugnoni Silvano, IPA Kanton BS, Woertz AG – EDV 18

Jeitziner Roman, IPA Kanton BS, ControlTech Engineering 19

Jost Thomas, IPA Kanton BE, Die Schweizerische Post 20

Luginbühl Marc, IPA Kanton ZH, ALCAN Technology & Management

AG Neuhausen 21

Pauchard Daniel, IPA Kanton VD, Arches Formations Lausanne 22

Stampfli Philipp, IPA Kanton BS, Sourcag AG 23

Weber Simon, IPA Kanton ZH, Trivadis AG, Glattbrugg 24

SUPPORT

1. Rang Hanselmann Simon, IPA Kanton ZH, Coca-Cola Beverages AG 26

2. Rang Zemp Remo, IPA Kanton ZH, Tomac Computer Concept AG 27

3. Rang Pfiffner Philippe, IPA Kanton ZH, Jet Schweiz IT AG 28

4

Applikationsentwicklung

5 Loic Baechler Ecole des métiers de Fribourg

Beste IPA 2009 der Schweiz: Applikationsentwicklung

Pilotage d’un robot avec une manette Wii

Description

Développer une application Java qui doit permet-tre à un utilisateur de piloter un robot du genre Hemisson par le biais d’une manette Wii. Le robot est muni d’un bras articulé qui doit également être manipulé en sélectionnant le bouton (B) de la manette Wii. Une webcam filmera la scène et les déplacements du robot. Matériels utilisés

• Une manette Wii • Un robot Hemisson • Deux clés bluetooth • Une webcam Logitech • Un poste de développement Logiciels:

• Netbeans IDE 6.5.1 • Librairie JavaCom • Librairie JMF • Librairie bluecove-2.0.3 • Librairie WiiRemoteJ Objectif

Créer une application J2SE en respectant la norme MVC2 et les standards de développement de l’EMF. Utiliser des Threads pour permettre à l’application d’effectuer plusieurs actions en même temps. Décomposer les métiers de manière judicieuse et efficace en tenant compte de la réutilisation po-tentielle. Fonctionnalité

Les rotations vers la droite ou vers la gauche de la WiiMote feront tourner le robot. L’inclinaison vers l’avant de la manette le fera avancer et l’inverse le fera reculer. Les mouvements seront transmis à la pince quand le bouton (B) situé en dessous de la ma-nette Wii sera pressé. Les rotations vers la droite et vers la gauche feront ouvrir et fermer la pince. Pour monter et descendre le bras, il faudra incli-ner verticalement la WiiMote. Pour des raisons de sécurité il n’est pas possible d’ouvrir la pince lors-que le bras est levé. Une interface graphique permettra de gérer la connexion du matériel et également de piloter le robot et manipuler la pince. Une fenêtre affichera à l’écran l’image de la webcam.

Marche à suivre

J’ai commencé par analyser mon projet en créant des diagrammes UML en fonction du cahier des charges. J’ai ensuite établi un planning des activi-tés à faire. Pour garantir la fonctionnalité de mon projet, j’ai réalisé un test de toutes les différentes technolo-gies utilisées. Cela m’a permis de gagner beau-coup de temps lors de la réalisation finale de mon projet ainsi que d’avoir une structure propre et logique. Conclusion

Le pilotage du robot est fluide et très réactif. Sim-ple d’utilisation et ludique, il pourrait permettre de présenter le côté fun du métier d’informaticien. De plus, la technologie de la robotique est en pleine extension et jumelée avec les performan-ces de la manette Wii, elle rend ce travail vrai-ment très passionnant.

6 Reto Meuwly Ecole des métiers de Fribourg

Interface JavaFX pour EmfBoard

Le logiciel EmfBoard:

L’Ecole des métiers de Fribourg veut équiper les salles de classe de son nouveau bâtiment d’un tableau blanc virtuel : système informatique com-posé d’un PC avec un logiciel spécifique, d’une tablette graphique faisant office d’écran pour l’enseignant et d’un projecteur vidéo faisant office de tableau pour les élèves. Le logiciel permettant de remplacer le tableau noir traditionnel s’appelle EmfBoard, il est développé par des élèves de la section Informatique Problématique:

Le logiciel s’est bien stabilisé, mais son interface graphique a peu évolué car la librairie du GUI est Java/Swing. Elle ne permet pas ou difficilement de créer des interfaces graphiques attrayantes ne possédant pas une forme rectangulaire. Objectif du projet:

Le but du projet CFC est de refaire l’interface graphique d’EmfBoard, spécialement la barre d’outils, avec le nouveau langage de Script « Ja-vaFX ». JavaFX est une nouvelle technologie de Sun, qui a pour but de développer des applications riches sur une multitude de plateformes (desktop, mo-bile, …). La partie dessin du projet et gestion des fichiers, qui a été réalisé en Java, ne doit pas être tou-chée, car elle donne entière satisfaction.

Etapes de réalisation:

Faire une analyse de l’application existante, et concevoir une nouvelle interface, qui a les mêmes fonctionnalités que l’ancienne, mais avec un de-sign plus attrayant. Cette étape a nécessité une prise en main de JavaFX, langage qui était nou-veau pour moi. Mettre en place un système de communication entre JavaFX et Java, entre le nouveau GUI et la partie existante de l’application EmfBoard. Il est important que l’application démarre avec JavaFX et c’est lui qui initie les communications vers Java. De cette manière on peut créer des interfaces possédant des formes de fenêtres quelconques. Combiner la nouvelle partie JavaFX et la partie dessin d’EmfBoard pour avoir une application fonctionnelle.

Résultat

Voici l’application EmfBoard, avec la nouvelle barre d’outils développée en JavaFX Conclusion

Le développement s’est généralement bien dérou-lé. Je réussi à créer une boite à outil qui est bien finalisé au niveau visuel et aussi au niveau du code. JavaFX est un langage avec beaucoup de poten-tiel, même s’il contient encore quelques erreurs de jeunesse.

7 Gregor Wegberg SIX Swiss Exchange AG

Generischer XML-Editor

Umfeld der Arbeit

XML Dokumente werden immer häufiger zum Spei-chern und Transportieren von Informationen verwendet. Das XML Format erlaubt das Lesen des Inhaltes ohne besondere Werkzeuge. Gleichzeitig sind die Daten in einem standardisierten Format abgelegt, was die einfa-che Verarbeitung durch Computerprogramme ermög-licht. Bei der SIX Swiss Exchange werden XML Doku-mente durch die Applikationen verwendet, um ver-schiedenste Daten zu speichern. Durch die Vielfalt und Informationsdichte der Daten, ist das Editieren der XML Dokumente in einem Texteditor kein leichtes Spiel. Fehler schleichen sich immer wieder ein und werden erst beim Start der jeweiligen Applikation bemerkt.

Auftrag

Das Projekt «Generischer XML-Editor» soll das Editie-ren der XML Daten vereinfachen und auch für Stan-dard-PC-Benutzer ermöglichen. Folgend die wichtigsten Anforderungen: • Eine zentrale Benutzeroberfläche zum Editieren

von XML Dokumenten verschiedener Ausprägun-gen anbieten.

• Zwei Formen der Ansicht (tabellarische und hierar-chische) ermöglichen. Diese sind jeweils abhängig vom Aufbau des XML Schema Dokuments (XSD, Regelwerk zum Aufbau eines XML Dokuments).

• Benutzerfreundliche Benutzeroberfläche mit Wie-dererkennungswert von weit verbreiteten Applikati-onen bieten.

• Validation der eingegebenen Daten und passende Rückmeldungen an den Benutzer ermöglichen.

• Möglichkeit, externe Editorkomponenten zu ver-wenden und explizit im XML Schema Dokument anzugeben .

Grundidee hinter dem Projekt

Der Leitgedanke dieses Projekts liegt im Gebrauch des XML Schema Dokuments (XSD), um das Editieren des beschriebenen XML Dokuments zu ermöglichen. Ein XSD beschreibt eine bestimmte Art von XML Dokumen-ten. Dazu gehören die möglichen Informationen, Daten-typen, etc. Genau hier setzt dieses Projekt an. Auf der Basis des XSD wird die gesamte Benutzeroberfläche aufgebaut, werden die Eingaben validiert und dem Benutzer Informationen angezeigt. Die Verbindung beider Formate unterstützt Benutzer beim Editieren verschiedenster XML Dokumente. Dieser Aspekt ist auch das «Generisch» in «Generischer XML-Editor». Übersicht der Realisierung

Das IPA Projekt besteht aus zwei Teilprojekten. Das Teilprojekt «Library» stellt den Generischen XML-Editor in Form von Programmlogik und vorbereiteten GUI (grafische Benutzeroberfläche) Elementen bereit. Es handelt sich hierbei nicht um ein ausführbares Pro-gramm, sondern um eine Bibliothek von Abläufen zum Editieren eines XML Dokuments. Diese Bibliothek kann durch Drittentwickler für ihre eigenen Applikationen verwendet werden und ermöglicht das Wiederverwen-den des Generischen XML-Editors für fast jede Ausprä-gung einer .NET Applikation. Das zweite Teilprojekt

«Windows Forms Editor» ist die ausführbare Applikati-on, die während der IPA erstellt wurde. Es handelt sich dabei um eine Beispielimplementierung der Library in eine «Windows Forms» Applikation. Während der IPA wurden alle Kundenanforderungen erreicht. Nachfol-gend möchte ich auf einige Besonderheiten des Pro-jekts eingehen. Mehrsprachigkeit

Beide Teilprojekte sind mehrsprachig aufgebaut. Die einzige Arbeit, um eine andere Sprache zu verwenden, liegt im Erstellen der Übersetzungsdateien. Add-In System

Im Teilprojekt Library ist ein Add-In System eingebaut, eine Erweiterung der Applikation, welche während der Laufzeit geladen wird. Es ist somit zur Entwicklungszeit nicht bekannt, was für Erweiterungen geladen werden. Im Generischen XML-Editor wird die Vielfalt an Editor-komponenten durch Erweiterungen vergrössert. Da-durch lässt sich die Library ideal an verschiedenste Anforderungen und XML Dokumente anpassen. Es ist möglich, einzelne Datentypen explizit mit einer be-stimmten Erweiterung zu editieren. Somit kann dem Benutzer der zugrundeliegende Datensatz im XML verschleiert werden. Die Add-Ins haben die Hoheit auf das Wissen, wie ein XML Wert editiert wird. Die Appli-kation ist nur der Rahmen für diese Wissensträger und gibt den Ablauf vor, hat aber keine Ahnung wie sie das XML Dokument editieren muss. Die Library enthält bereits mehrere Erweiterungen. Diese implementieren die nötigen Editorkomponenten für die Kundenanforde-rungen. Validation

Die Validation der eingegebenen Werte ist ein zentraler Punkt dieses Projekts. Alle eingegebenen Werte müs-sen zwingend überprüft werden. Die Applikation unter-stützt den Benutzer dabei auf mehrfache Weise. Wäh-rend der Eingabe eines Wertes wird dieser sofort gegen das XML Schema Dokument validiert. Fehler werden dem Benutzer direkt neben der Eingabe angezeigt. Gleichzeitig hat der Benutzer der Applikation jederzeit die Möglichkeit, das gesamte XML Dokument zu vali-dieren. Mögliche Fehler werden in einem eigenen Text-feld, unten in der Applikation, angezeigt. Auf diese Weise ist dem Benutzer jederzeit bekannt, welche Wer-te gültig sind. Kann der Benutzer aus irgendeinem Grund das Dokument nicht in einen gültigen Zustand bringen, hat er jederzeit die Möglichkeit, das Dokument als Textdokument zu speichern. Dadurch wird die Vali-dierung beim Speichern umgangen. Mittel und Methoden

Das Projekt wurde in der Programmiersprache C# ge-schrieben. Die Entwicklung fand in Microsoft Visual Studio 2008 statt und baut auf dem Microsoft .NET Framework 3.5 auf. Die Realisierung wurde auf dem Prinzip der testgetriebenen Entwicklung (zuerst Tests schreiben, dann die eigentliche Implementation) aufge-baut. Funktionale Tests wurden zum Testen der grafi-schen Benutzeroberfläche durchgeführt.

8 Patrick Bracher Swisscom AG

Backup-Reporting-Tool

Aufgabenstellung

Backup war bei Swisscom Mobile ein freier Servi-ce. Das Backup Reporting wurde nur sporadisch manuell durchgeführt. Mit der Übernahme vom Swisscom Mobile Infrastruktur-Team von Swiss-com IT Services wurde auch das Reporting zu-nehmend wichtiger. Vor allem für das Charge-backreporting gab es noch keine Lösung. Der Reportingprozess der Ex- Swisscom Mobile Backupinfrastruktur soll geplant und automatisiert werden können. Dazu wird eine Applikation pro-grammiert die als Schnittstelle vom BackupAdmi-nistrator zu den Backup und VTL Server dient. Die Applikation kann Scripts und andere Befehle auf einem konfigurierten Server ausführen und den Output in ein Excel File exportieren. Um die Re-portingzeiten zu verkürzen, kann die Applikation verschiedene Vorgänge parallel ausführen. Die Applikation automatisiert den Reporting Prozess durch einen eingebundenen Scheduler, welcher die Backup Chargeback Reports und die VTL Reports zu vordefinierten Zeiten startet. Konzept

Für die Applikation wurde der Name BCKReptor gewählt. Die Applikation wurde als Client – Server Architektur in der Swisscom integriert, wobei der Server auf einem Backup Management Server und der Client auf den Swisscom Standard PCs liegt.

Der Server ist für den Prozess vom Start eines oder mehreren Jobs über die Rapportierung bis hin zum versenden eines Excel Reports verant-wortlich. Dabei schreibt die Applikation auf dem Server in eine Log-Datei um Fehler und Aktivitä-ten zu dokumentieren. Auf dem Client wird lediglich die grafische Benut-zeroberfläche gestartet. Der Client verbindet sich via RMI – Bus an den Server. So können Konfigu-rationen vorgenommen, Jobs gestartet, Jobs be-endet und überwacht werden. Die Java Applikation wurde mit der Modellierungs-sprache UML geplant. Die daraus entstandenen Diagramme dienten zu Dokumentationszwecken von Analyse und Design der Applikation. Probleme

Als Hauptproblem während der IPA kristallisierte sich eindeutig der Client Teil der Applikation her-aus. Die Server-Internen Abläufe wie Job starten, Excel Report abfüllen und Report versenden wur-de anfänglich ohne RMI geplant und konnten in der geplanten Zeitspanne implementiert werden. Das Design für die Client Server Architektur wur-de erst während der Realisierungs- und Imple-mentierungsphase von BCKReptor erstellt. Bei der genaueren Analyse von Java RMI ist erst während der Realisierungsphase aufgefallen, dass in den RMI-BUS keine Frames wie auch kein Thread serialisiert und exportiert werden können. Daher musste das Design von der Client-Server Architektur neu geplant und implementiert wer-den. BCKReptor ist die erste Applikation, die mit Java RMI in einem solchen Ausmass geplant und erstellt wurde. Fazit

Mit der Applikation BCKReptor konnten alle Krite-rien die an die IPA gestellt wurden gut erfüllt wer-den. Das Projekt BCKReptor ist jedoch noch lan-ge nicht fertig. Die IPA bietet eine Basis von ei-nem Backup-Reporting Tool, das in der Zukunft weiter verbessert werden kann. Die UML Dia-gramme wie auch die Dokumentation im Quellco-de vereinfachen die Weiterentwicklungen für zu-künftige Arbeiten. Während der IPA habe ich sehr viel gelernt. Vor allem die Bereiche UML, RMI, und Frames waren noch sehr neu

9 Nicolas Kury Ecole des métiers techniques Porrentruy

Gestion des absences

Environnement

L’application de gestion des absences est une fonctionnalité implémentée dans un programme permettant de gérer les notes, bulletins et acteurs relatifs à une école. Ces données confidentielles doivent être traitées de manière sécurisée. La Gestion des Notes est accessible par Intranet depuis chaque ordinateur connecté au réseau de l’école et par Internet. Elle a été mise en produc-tion il y a plusieurs années ce qui engendre des exigences de la part des utilisateurs lors de modi-fications du système qu’ils emploient régulière-ment. Un établissement tel que celui dans lequel le programme est intégré comprend de nombreu-ses contraintes de par la diversité des formations offertes. Des solutions individuelles en terme d’horaires et de plans de formation sont, par ail-leurs, proposées à chaque élève en ayant la né-cessité. Tout élément développé doit donc faire preuve de souplesse pour s’y adapter. Les absences des élèves sont des informations qui nécessitent d’être traitées quotidiennement. Leur gestion doit être peu contraignante et forcer à la rigueur. Caractéristiques techniques

L’application de gestion des notes est constituée d’une BDD Oracle et d’une interface PHP fonc-tionnant sur un « serveur physique » (Windows 2003 Server) sur lequel est installé un « serveur virtuel » (VMware server). L’objectif est d’optimiser et de simplifier la mise en production et d’assurer la portabilité du système. Objectifs

Le travail consiste à : 1. Implémenter un système de gestion des ab-

sences pour décharger le travail du secréta-riat

2. Envoyer automatiquement par email la feuille d’absence à l’élève et au maître d’apprentissage pour offrir un suivi en temps réel

3. Documenter le travail effectué pour assurer la viabilité à long terme de l’application

Résultat

Existant: Lors de l’absence d’un élève, chaque enseignant rempli un formulaire en papier qu’il transmet au secrétariat. Ce dernier rassemble toutes les informations concernant l’apprenti dans un fichier informatique qu’il transmet par courrier à l’employeur. À son retour dans l’entreprise, l’élève se rend auprès de son formateur pour récupérer et faire valider ladite feuille avant de la présenter à ses professeurs.

Solution: Des postes clients sont installés dans chaque salle de classe pour permettre aux ensei-gnants d’insérer les absents à chaque début de cours. Ils sont recensés dans la BDD à la fin de la journée, puis envoyés automatiquement par email à l’élève et à son maitre d’apprentissage. En conséquence, le formateur est informé en temps réel et l’apprenti est responsabilisé en imprimant et présentant la feuille aux personnes concernées (citées précédemment). Si le formateur ne dis-pose pas d’une adresse email, le secrétariat rece-vra la feuille d’absence à sa place et la lui trans-mettra par courrier. Conclusion

La complexité de ce travail ne réside pas seule-ment dans le développement. Tout d’abord, il est difficile de s’intégrer à un projet ayant cours de-puis presque dix ans où les développeurs ont été nombreux. Chaque ajout de fonctionnalité néces-site une bonne prise en compte de l’existant et une anticipation des conséquences sur l’ensemble du programme. Par ailleurs, la docu-mentation joue un rôle fondamental dans ce type de projet pour en assurer la pérennité. Enfin, des compétences humaines sont indispensables pour faire valoir un tel projet auprès des utilisateurs.

10 Michael Sebel Intersim AG

Abstraktionsschicht für Kartendienste

Ausgangslage

Momentan werden Kartendienste (Google Maps, Map24 etc.) nur selten in CMS Projekten der Intersim AG eingesetzt. Künftig möchte man dem Kunden aber im Rahmen des eigens entwickelten CMS Sitevision auch Module und Funktionen in diesem Stil anbieten können. Daher soll im Kern von Sitevision in C#.NET eine Kom-ponente geschrieben werden, welche diese Funktionali-tät abdeckt. Im Rahmen der IPA werden zwei Karten-dienste, Google Maps und Map24 implementiert. Ziele

• Kurze Einarbeitungszeit durch einheitliche Anwen-dung der Kartendienste.

• Möglichkeit zur Generierung einer verständlichen Entwicklerreferenz.

• Erweiterungen gewährleisten (für weitere Karten-dienste wie Mapsearch, Windows Live Maps, Via-michelin oder neue Funktionen).

• Spezifikation gibt Aufschluss über den Aufbau und die internen Abläufe der Komponente. Das zugrun-de liegende Datenmodell ist soweit dokumentiert, dass man problemlos weitere Schnittstellen (z.B. automatisches GPS Tracking) anbinden könnte.

Mittel und Methoden

Das Software-Design wird mit den klassischen Hilfsmit-teln ERD und UML gestaltet. Die Projektmethode setzt sich aus der Weg-Resultat-Matrix und Teilen des Ratio-nal Unified Process zusammen. Vom Rational Unified Process kommen dabei primär der iterative Entwick-lungsprozess sowie der Test Workflow zum Einsatz. Daraus ergibt sich eine Projektmethode, die optimal für kleine bis mittlere Projekte geeignet ist. Umsetzung Der erste Schritt bestand daraus, eine abstrakte Basis-klasse zur Verfügung zu stellen, welche Grundfunktio-nen aufweist und ein zwingendes Gerüst für alle erwei-ternden Klassen bereitstellt (abstrakte Methoden). Die verschiedenen Funktionen werden in Schnittstellen gruppiert, um die Verwendung der Dienste verständlich und übersichtlich zu machen. • Anzeigen von Orten auf der Karte mit HTML/Icon. • Anzeigekonfiguration der Karte, zoomen, zentrie-

ren etc. • Suche nach Koordinaten anhand von Sucheinga-

ben. • Konfiguration der Komponente selbst (API Schlüs-

sel, Sprache, eigene Parameter). • Kartendaten speichern und laden. • Routenberechnungen. Selbstverständlich implementiert nicht jeder Karten-dienst alle Schnittstellen (Mapsearch z.B. könnte keine Routenberechnung durchführen). Für jeden Karten-dienst sollen daher nur die passenden Interfaces imp-lementiert werden.

Basiskomponente durch Schnittstellen mit Map24 / Google Maps erweitern

Google Maps und Map24 erben nun jeweils von der Basisklasse und implementieren alle Interfaces, wo-durch keine spezifischen sichtbaren Methoden mehr nötig und die Kartendienste absolut gleich zu bedienen sind. Was dahinter abläuft, muss den anwendenden Entwickler nicht kümmern. Im Fall von Google Maps wird Javascript generiert, bei Map24 hingegen werden Webservices angesprochen. Objekte an COM-fähige Sprachen zur Verfügung stellen

Schlussendlich sollen die Google Maps und Map24 Objekte – wie alle wichtigen Objekte innerhalb des Kernmoduls von Sitevision – als COM Objekte in Skriptsprachen wie klassischem ASP zur Verfügung gestellt werden. Fazit

Die Umsetzung dieser Komponente hat einiges gefor-dert und trotzdem hat die Zeit am Ende gereicht, um alle Ziele zu erfüllen. Die Arbeit an der IPA war für mich vom ersten bis zum letzten Tag spannend und ich bin überrascht wie viel Dokumentation und Code ich in der kurzen Zeit produziert habe. Das Thema der Arbeit war sehr interessant und ich denke, dass mit dem Resultat einige spannende Features für unser CMS Sitevision aufgebaut werden können.

11 Michael Vogt ISE AG Informatik Solutions Einsiedeln

Vokabeltrainer für SharePoint

Ausgangslage

Für die bestehende E-Learning Plattform soll ein Modul «Vokabeltrainer» realisiert werden. Ein Lernender soll beliebig viele Vokabulare erstellen und verwalten kön-nen. Wenn der Anwender das Training startet, über-setzt er vom System ausgewählte Vokabeln und wird über Erfolg oder Misserfolg informiert. Zu jedem Voka-bular soll eine Statistik generiert werden. Daten und Schnittstellen

Neben dem eigentlichen Funktionsumfang des Pro-dukts mussten einige Anforderungen berücksichtigt werden: • Anwendungsspezifische Konfigurationsdaten wer-

den in einer für diesen Zweck bereitgestellten XML-Datei verwaltet.

• Ein MOSS Feature dient als Template zum Erstel-len eines Vokabulars und der verschiedenen Views.

• Jedes Vokabular wird als SharePoint Liste (SPList) erstellt und enthält pro Vokabel ein SPList-Item.

• Die Statistikdaten sollen in der DefaultView des Vokabulars angezeigt werden.

• Die Metadaten jedes Vokabulars werden in einer separaten Datenbank gespeichert.

Lösung

Mein Design sah drei zentrale Klassen vor: • Die Klasse AppConfigService kümmert sich um alle

vokabularübergreifenden Aspekte. Sie liest die an-wendungsspezifischen Daten aus der XML Datei ein, stellt ein Template mit Defaultwerten zum Erstellen von Vokabularen bereit und liefert be-stimmte GUI Parameter.

• Die ListConfigService Klasse kümmert sich um alle vokabularspezifischen Daten und speichert diese per DAO Klasse in der MSSQL Datenbank.

• Die Trainer Klasse enthält den zentralen Algorith-mus zum Trainieren von Vokabeln. Der Trainer er-stellt eine Trainingsliste, stellt zu übersetzende Vo-kabeln bereit, wertet Übersetzungen aus und spei-chert die Statistikwerte.

Den Zugriff auf die verschiedenen Datenquellen konnte ich auf elegante Weise auf ein Minimum reduzieren. Zugriffe erfolgen nur im absoluten Bedarfsfall. Der Benutzer kann – auch mitten im Training – die Abfragerichtung oder die erforderliche Anzahl korrekter Übersetzungen ändern. Der Algorithmus zum Trainieren ist so aufgebaut, dass häufig fehlerhaft übersetzte Vokabeln häufiger abge-fragt werden. Vokabeln, die in einer bestimmten Anzahl nacheinander korrekt übersetzt wurden, werden im laufenden Training nicht mehr abgefragt. Resultat

Der Vokabeltrainer kann sich sehen lassen. Die Ziele und Anforderungen konnten umgesetzt werden. Die Zeit reichte, um den einen oder anderen zusätzlich während der IPA vom Auftraggeber angebrachten Wunsch zu berücksichtigen. Fazit

Auch wenn es zwei der hektischsten Wochen meines Lebens waren, machte mir das Projekt IPA viel Spass. Vor allem, da ich das modellierte Design wie geplant umsetzen konnte. Auch sind ein paar .NET Highlights in den VocabularyTrainer eingeflossen. Natürlich sorgten ein paar Denk- und Laufzeitfehler für kurzfristige Adrenalinschübe. Zum Glück liessen sich diese Probleme jeweils innert nützlicher Frist beheben. Der zentrale Algorithmus des Trainers sollte nach der IPA noch ein bisschen intelligenter gelöst werden. Vor allem sollte dafür gesorgt werden, dass die gleiche Vokabel nicht mehrmals nacheinander abgefragt wird. Ganz besonders stolz bin ich, dass ich – nicht nur mir selbst – gezeigt habe, dass auch ein blinder Mensch durchaus fähig sein kann, so eine anspruchsvolle Aus-bildung zu absolvieren. Die IPA ist eine geeignete Mög-lichkeit, die Leistungsfähigkeit zu messen und natürlich auch um aufzuzeigen, wo die Grenzen für einen nicht sehenden Menschen liegen.

12 Maxime Wicht Ecole des métiers de Fribourg

Application multi-tactile pour la visualisation de composants multimédias

Environnement

Fin 2006, le fabricant de consoles de jeux vidéo Nintendo développe la Wiimote, une formidable manette de jeu comportant plusieurs capteurs et une caméra infrarouge capable de suivre jusqu’à 4 points infrarouges en mouvement. Les écrans tactiles étant actuellement très coû-teux (999 € pour une version 15 pouces chez Wacom), l’idée de combiner la caméra de la Wii-mote avec des crayons infrarouges donne une excellente alternative pour simuler un écran tac-tile.

Objectif

Ce projet a pour but de créer une application mul-ti-tactile capable de visualiser sous diverses for-mes des composants multimédias. Elle permet de transformer toutes les surfaces en une interface multi-tactile à moindre coût. La Wiimote de Nin-tendo et deux crayons leds infrarouges joueront le rôle de capteurs pour l’interface multi-tactile. Cette application permet de : • Visualiser des images sous différentes formes • Déplacer, faire pivoter et redimensionner des

images • Transférer une image entre deux zones de

travail

Solution

Application réalisée avec les technologies suivan-tes: • Wiimote de Nintendo, manette de la console

Wii, peu coûteuse qui permet de détecter 4 points infrarouges simultanément.

• Adobe AIR, machine virtuelle d’Adobe qui exécute des applications Internet Riches en version desktop.

• WiiFlash, application open source qui facilite la communication entre Flash et la Wiimote (fourni une API Flash et un Serveur).

• PureMVC, framework basé sur le modèle de conception Model-View-Controller qui permet une excellente lecture/maintenance du code.

La réalisation du projet s’est déroulée de la ma-nière suivante:

1. Analyse des besoins par rapport au cahier des charges, réalisation des diagrammes UML correspondants.

2. Réalisation d’un planning détaillé. 3. Développement de l’application et créa-

tion de la documentation avec le système de développement FlexBuilder d’Adobe.

4. Test des fonctionnalités.

Conclusion

Le concept de cette application est innovant à plus d’un point de vue : • Il permet de réaliser dans de nombreux

domaines des applications destinées à l’enseignement.

• Chose non négligeable, il permet enfin de posséder un écran multi-tactile pour moins de cent francs.

13 Yann Zähringer Polyright SA

Polyright iPurse

Contexte du projet

La société polyright est spécialisée dans le déve-loppement de plateformes multifonctions utilisant

une carte à puce (contact ou sans contact), dans les domaines de la santé, de l’éducation et des entreprises. Le produit polyright permet de gérer, avec une seule puce, plusieurs services liés à l’accès ou au paiement électronique. Chaque puce est en relation avec une personne-utilisateur

dans la base de données polyright. Polyright fournit des WebServices pour permettre d’accéder via un nom d’utilisateur et un mot de passe aux données de la personne (état du compte, transactions, …). Ce projet consiste à réaliser une application pour « iPhone ou iPod Touch » d’Apple, utilisant nos WebServices, pour permettre aux utilisateurs du produit polyright en possession d’un iPhone d’accéder aux différents services proposés. Objectif du projet

L’objectif du projet est de développer une applica-tion pour « iPhone OS » qui utilisera les WebSer-vices que polyright fournit, pour accéder aux diffé-rents services proposés. Polyright a déjà conçu ses WebServices, pour les utiliser il faut mettre en place l’infrastructure Ser-veur Web, Serveur DB Oracle 10g polyright et Client. L’interopérabilité des WebServices est mise à l’épreuve car ceux-ci vont être utilisés depuis une autre plateforme et depuis un autre système d’exploitation. Ce projet consistait donc à : - Documenter et effectuer une étude prélimi-

naire sur MacOS X, Cocoa, Objective-C et l’utilisation des WebServices

- Préparer l’environnement « X-Code » pour le développement

- Installer l’infrastructure serveur polyright Ora-cle et WebServices

- Apprendre les bases du langage Objective-C et Cocoa

- Prendre en main Mac OS X et son environ-nement de développement

- Développer la partie appel des WebServices polyright en Objective-C

- Développer l’interface graphique pour iPhone - Documenter l’application

Infrastructure

1. Serveur polyright Oracle 10g o Base de données polyright

2. Serveur polyright WebServices o WebServices polyright hébergés par IIS et connectés au serveur Oracle 10g

3. Produits polyright o Produits polyright (Paiement, sécurité, …) connectés au serveur Oracle 10g

4. iPhone/iPod Touch o Application iPurse cliente des WebSer-vices polyright

Conclusion

Beaucoup de gens disent que celui qui utilise MacOS X pour la première fois, « l’adopte ». Dans mon cas, cela est arrivé et depuis, utiliser un envi-ronnement MacOS X ne me dérange pas. Programmer pour celui-ci ou pour iPhone n’est pas si compliqué que je l’imaginais, surtout qu’on peut faire de grandes choses avec peu de code et peu de temps. L’interopérabilité des WebServices a encore une fois été prouvée car ceux-ci ont été utilisés depuis un autre système d’exploitation et depuis une autre plateforme.

14

Systemtechnik

15

Beste IPA 2009 der Schweiz: Systemtechnik

Evaluation, Integration und Betrieb eines neuen Helpdesksystems

Umfeld

Die SQS beschäftigt rund 150 Mitarbeitende. 1/3 der Mitarbeitenden arbeitet am Geschäftssitz in Zollikofen. Die Aussendienstmitarbeitenden be-nützten Telearbeitsplätze und greifen via VPN auf die IT-Services zu. Neben der Betreuung der IT-Services ist auch der Support der Mitarbeiter ein grosser Aufgaben-bereich. Problemanfragen kommen meistens per Mail oder Telefon in die Informatikabteilung. Dort werden die Pendenzen entweder mit Excellisten oder Outlook-Aufgaben festgehalten. Dieses System beinhaltet viele Schwachstellen. Es fehlt eine automatische Feedbackfunktion, welche den Kunden und die IT bei Änderungen am Ticket informiert. Abgeschlossene Arbeiten werden nicht festgehalten. Lösungen zu den Problemen sind somit nicht vorhanden und es kann nicht eingese-hen werden wie viele Probleme in einem be-stimmten Zeitrahmen in einem Bereich aufge-taucht sind. Aufgabe

Die Aufgabe war es, anhand eines Kriterienkata-logs eine geeignete Helpdesk-Software zu evalu-ieren. Das evaluierte Produkt muss in der SQS installiert und konfiguriert werden. Die Lösung soll kosten-günstig und benutzerfreundlich sein. Die Kunden sollen für ihre Ticketoberfläche dasselbe Login verwenden wie an ihren Arbeitsplätzen. E-Mails müssen die Supporter und Kunden über den ak-tuellsten Stand informieren. Sie sollen bei Status-änderungen und neuen Tickets informiert werden. Zusätzlich muss das System Statistiken auswer-ten können und Lösungen in einer Wissensdaten-bank festhalten. Anhand der Statistiken soll z.B. eingesehen werden in welchem Bereich sich die meisten Probleme ergeben. Ein zusätzliches Kri-terium war die Windows-Kompatibilität. Das Pro-dukt soll auf einem Windows 2003 Server aufge-setzt werden. Da es bei der Einführung eines Helpdesk-Systems ein paar organisatorische Änderungen gibt, soll ein neuer Support-Prozess erstellt wer-den.

Lösung

Anhand einer Nutzwertanalyse wurden 2 Produkte miteinander verglichen. Schlussendlich wurde die Open-Source Software OTRS evaluiert. Für den Betrieb von OTRS wurde ein HP ProLiant ML370 Server mit RAID1 + Spare-Disk in Betrieb genommen. Als Betriebssystem wird Windows 2003 Server verwendet. OTRS wurde als Paket mit Apache und MySQL installiert und den Be-dürfnissen angepasst.

Damit die Mitarbeiter ihr gewohntes Login beibe-halten, wurde das LDAP Back-End von OTRS eingerichtet. Bei einer Anmeldung am Kundenin-terface authentifizieren sich die Mitarbeiter mit dem Domänencontroller der SQS. Für den E-Mail Versand der Statusnachrichten wurde der Exchange Server der SQS als SMTP-Relay hinterlegt. Der OTRS Server sendet seine Nachrichten an den Exchange, welcher sie an-schliessend an die betroffenen Personen sendet. Die Supporter sind jeweils ihren Queues (Katego-rien) zugeteilt und werden über Änderungen in ihrer Queue per E-Mail informiert. Damit die Informatikabteilung Änderungen am System vornehmen kann, wurde ein Administrato-renmanual erstellt, welches die wichtigsten Punk-te beinhaltet. Die internen und externen Mitarbei-ter der SQS erhalten eine kurze Benutzeranlei-tung welche ihnen das Kundeninterface erklärt und zeigt wie ein Ticket erstellt wird.

Robin Csontos SQS

16 Andreas Banz Stadt Luzern

Servervirtualisierung

Ausgangslage

Im Rechenzentrum der Stadt Luzern werden bis dato alle Serverbetriebssysteme auf physischer Hardware betrieben, die vereinzelt nicht mehr den Leistungsanforderungen entspricht, oder veraltet ist. Das enorme Wachstum der Serverfarm in den letzten Jahren hat den Managementaufwand be-trächtlich erhöht und den Überblick über die ein-gesetzten Server infolge der Hardwarevielfalt erschwert. Die in der Vorstudie durchgeführte IST-Analyse der Serverfarm hat gezeigt, dass bei einem Ser-verhardwareausfall zu viel Zeit verstreicht, bis das System wieder verfügbar ist. Durch die Servervir-tualisierung soll in den Punkten Verfügbarkeit, Management und Desaster Recovery eine ersicht-liche Verbesserung entstehen. Aufgabe

Die Aufgabe meiner Facharbeit bestand darin ein Netzwerk aufzubauen, welches den Alltag mit einer virtuellen Infrastruktur fehlerfrei demonst-riert. Als Weiteres wurden folgende Ziele und funktionale Anforderungen definiert. � Die neue Lösung muss die Funktionen der

physischen Server vollumfänglich zu über-nehmen können.

� Das Desaster Recovery ist effizienter und schneller durchführbar.

� Server können mit geringerem Zeitaufwand installiert und konfiguriert werden.

� Dedizierte Server sind auf virtuelle Maschinen zu verlagern, um so die Anzahl der physi-schen Rechner zu reduzieren und die Hard-ware-Auslastung deutlich zu verbessern.

� Die Verwaltung der virtuellen Server ist von jedem Arbeitsplatz aus möglich.

� Die Live-Migrationen von virtuellen Maschinen ist möglich.

� Es stehen Funktionen zur dynamischen Last-verteilung und Zuweisung von Ressourcen für virtuelle Maschinen zur Verfügung.

Lösung

Die im Grobkonzept erarbeitete Wirtschaftlich-keits-analyse und der Ist- / Soll-Vergleich zeigten auf, dass in der virtuellen Infrastruktur enormes Potenzial steckt, das genutzt werden soll. Nach der Abnahme des Grobkonzepts wurden im De-tailkonzept Architektur- und Designüberlegungen erarbeitet, die als Ziel eine optimale Eingliederung der virtuellen Infrastruktur haben. Des Weiteren sind die Konfigurationen der einzelnen Kompo-

nenten definiert und die Backup-Empfehlung aus-gearbeitet. In der Implementationsphase sind die im Detail-konzept definierten Varianten folgendermassen aufgebaut worden. Zuerst wurden die Server mit einem Switch untereinander verbunden um die Kommunikation gewährleisten zu können. Danach wurde auf den HP DL380G5 Servern der ESX-Server von VMware installiert und die Server ins SAN eingebunden. Das Herzstück der virtuellen Infrastruktur, der VirtualCenter Server, ist auf ei-nem virtuellen Server installiert worden, um die Hochverfügbarkeit zu nutzen. Anschliessend wur-den dann die Funktionen HA, DRS und Vmotion auf dem VirtualCenter hinzugefügt um Hochver-fügbarkeit, Lastausgleich und Live-Migrationen zu garantieren. Das Backup wurde mittels VMware Consolidated Backup realisiert und so konfiguriert, dass LANfree gesichert werden kann. Dazu wurde für den VCB-Proxy ein Storage-Node eingerichtet,

um die Daten direkt auf die virtuelle Tape Library schreiben zu können. Mit der Variante VCB wird bei einer Sicherung der virtuelle Server nicht hö-herer Belastung ausgesetzt, da das Backup über den VCB-Proxy gezogen wird. Fazit

Die erwarteten Ergebnisse wurden in vollem Um-fang erreicht. In den 13 Tagen meiner Facharbeit ist eine nachvollziehbare und ausführliche Pro-jektdokumentation entstanden, mit der die Demo-Umgebung aufgebaut werden konnte. Auch die Tests zeigten, dass die spannende, aber auch sehr intensive Zeit erfolgreich abgeschlossen werden konnte. Die Arbeit wird als Grundlage für Fragen und Ideen beim Konzept der Realisierung mit dem zukünftigen Integrator im Projekt IT-Virtualisierung bei der Stadt Luzern einbezogen.

17

Erstellung & Konfiguration von Netzzonen auf bestehender VC/ESX-Umgebung

Umfeld und Ziel der Arbeit

Im Bereich 'IT-Sicherheit & Risikomanagement' (BPSR) des Bundesamtes für Informatik und Tele-kommunikation (BIT) wird eine Testumgebung einge-setzt. Diese besteht aus mehreren Komponenten, ei-nem Virtual Center (VC), einem ESX-Server, einem ESXi-Server und einem NAS. Damit geltende Weisungen und Standards eingehalten werden können und der Unterhalt dieser Testinfrastruk-tur vereinfacht werden kann, wurde diese Umgebung reorganisiert. Dabei wurde darauf geachtet, dass, wo immer möglich, BIT Standardinstallationen, Prozesse und Produkte eingesetzt werden. Dazu werden die Systeme nicht mehr von BPSR, sondern von den ent-sprechenden Bereichen bereitgestellt und gewartet, während BPSR darauf aufbauend nur noch einige Ap-plikationen (insbesondere das VC, die virtuellen Instan-zen und entsprechende Tools) administriert. Im nächsten Schritt ging es darum, innerhalb der virtu-ellen Umgebung dedizierte Netzzonen für die verschie-denen Bedürfnisse zu erarbeiten und umzusetzen. Dabei tritt vor allem die Problematik der Sicherheitsrisi-ken in den Vordergrund: Die Umgebung umfasst so-wohl produktive Systeme als auch Testgeräte (mit zum Teil heiklen, verwundbaren Democlients). In der alten virtuellen Umgebung war bisher eine provisorische Lösung in Betrieb, welche eine solche Netzzone ent-hielt. Im Rahmen der IPA war es nun das Ziel diese Lösung zu ersetzen. Dafür wurden entsprechende Firewallsysteme installiert und konfiguriert. Diese Sys-teme teilten anschliessend die virtuellen Systeme der Testumgebung in verschiedene Zonen auf. Neben einigen zu übernehmenden Zonen, wurde auch eine neue Netzzone für Nessus-Präsentationen erstellt. In dieser Netzzone sind, Zwecks Vorführungen, neben einer Nessus-Sonde auch Testclients und ein WSUS-Server erstellt worden. Nachfolgende Grafik zeigt eine Darstellung der erwähn-ten Systeme und ihrer jeweiligen Netzzonen.

Beschreibung der Arbeit und der Lösung

Im Rahmen der Realisierung der Arbeit wurden folgen-de Elemente erstellt: • BPSR_FW_Testumgebung

Diese Firewall trennt die produktiven Netzzonen, von jenen, der Testsysteme. Dabei schützt sie die produktiven Netze auch dadurch, dass "Testkonfi-gurationen" ausschließlich auf der zweiten Firewall durchgeführt werden.

• Test_FW_01 Diese Firewall unterteilt die verschiedenen Test-systeme in die jeweiligen Netzzonen. Der vorher-gehenden Grafik können die Schnittstellen ent-nommen werden, über welche die beiden Win-dows-Netzzonen und die Nessus-Netzzone mit der Firewall verbunden sind. Zuletzt verfügt die Firewall über eine Verbindung zur "BPSR_FW_Testumgebung", um trotz allem einen dedizierten Datenverkehr zwischen den Testsys-temen und dem Intranet, oder dem Internet, sicher-stellen zu können.

• Nessus_WSUS_01 Bei diesem System handelt es sich um einen Win-dows Server 2003, auf welchem ein WSUS instal-liert wurde. Dieser Server stellt den Testclients der Netzzone "Nessus_LAN1" die benötigten Updates zur Verfügung und sorgt damit für deren "Up to Date"–Status.

• Nessus-Sonde-01 Hierbei handelt es sich um einen SUSE Linux En-terprise Server 10. Auf dem System wurde nebst einer minimalen Grundinstallation die Software für eine Nessus-Sonde installiert. Über das Tenable Security Center des BIT können Scanning-Vorgänge über diese Sonde vorgenom-men werden. So scannt die Sonde ein System ihrer Netzzone und liefert das Ergebnis zurück an das Security Center. Dort können die Ergebnisse an-schliessend ausgewertet werden.

• Nessus_WinXP_01 Dies ist ein Testclient-System, welches mit einem Windows XP SP2 installiert wurde und automatisch vom WSUS gepatcht wird. Dadurch bietet es mög-lichst keine Sicherheitslücken an, was durch Scans über die Nessus-Sonde analysiert und demonstriert werden kann.

• Nessus_WinXP_02 Auch hierbei handelt es sich um einen Windows XP SP2 Testclient. Dieser bezieht seine Updates ebenfalls beim netzinternen WSUS, installiert sie jedoch nicht automatisch. Dadurch bietet er eine bessere Angriffsfläche aufgrund von Sicherheitslü-cken. Ein Scan auf dieses System würde im Ver-lauf einer Demonstration dementsprechende Schwachstellen aufweisen.

Sämtliche Konfigurationen und Informationen, welche für Demonstrationen und andere Vorgehen im Rahmen der Netzzone "Nessus_LAN1" benötigt werden, wurden ausserdem in einem Betriebshandbuch zu Handen der Abteilung BPSR zusammengefasst.

Ramona Cioccarelli Bundesamt für Informatik und Telekommunikation

18

Desktop Management mit OPSI

Was ist opsi?

Opsi (open-pc server integration) ist ein freies auf Linux basierendes Desktop-Management System. Es umfasst folgende Kernfunktionen: 1. Automatische Installation von Windows 2000,

XP, 2003, Vista und 2008 2. Automatische Softwareverteilung auf den

Clients 3. Hard- und Software-Inventarisierung Wie funktioniert opsi? 1. Automatische OS-Installation: 2. Vor dem Start der Installation wird ein PXE-

Image gestartet, das eine 3. Hardware-Inventarisierung durchführt und die

benötigten 4. Installationsdateien und Treiber vom opsi-

Server auf den Client kopiert. 5. Danach wird ein Windows Setup mit Unatten-

ded.txt ausgeführt. 6. Automatische Softwareverteilung: 7. Für die Softwareverteilung ist der opsi-

Preloginloader zuständig. Dieses 8. Programm verbindet sich bei jedem System-

start mit dem opsi-Server und 9. prüft, ob neue Pakete zur Installation bereit-

stehen. Falls ja, werden sie 10. vom Installationsprogramm wInst automatisch

installiert. Während der 11. ganzen Zeit bleibt die Oberfläche für den Be-

nutzer gesperrt. 12. Hard- und Software-Inventarisierung: 13. Die Inventarisierung basiert auf WMI. Die

Daten werden von speziellen 14. Softwarepaketen gesammelt in einer MySQL-

Datenbank gespeichert. Sie sind 15. über die Verwaltungsoberfläche von opsi ab-

rufbar. Ausgangslage

Der Client-Installationsprozess der Woertz AG ist umständlich und benötigt viel Zeit. Eine Softwareverteilung ist nicht vorhanden. Die Inventarisierung der Clients ist unvollständig und basiert auf VBScript und Textdateien. Woertz AG Desktop Management mit OPSI Web Summary Silvano Brugnoni Ziele

Mein Auftrag war, einen opsi-Server zu installie-ren und zu konfigurieren. Das

erwartete Resultat der IPA war ein funktionieren-der Server, über den sich Windows XP und die Standard-Softwarekonfiguration der Firma automatisiert auf den Clients installieren lassen. Zusätzlich sollte ich eine Systemdokumentation über den Server und ein Handbuch zum Thema Softwarepaketierung erstellen. Das Führen eines Arbeitsjournals wurde ebenfalls verlangt. Durchführung

Die Realisierung des Projekts habe ich in drei

Phasen aufgeteilt: � Phase 1: Konfiguration des opsi-Servers � OS installieren � Dienste konfigurieren � Phase 2: Windows-Installation � Installationspaket konfigurieren � Phase 3: Softwarepakete erstellen � Softwarepakete erstellen � Anleitung zu Paketierung mit opsi erstellen Die dritte Phase und die Dokumentation bildeten den Schwerpunkt der IPA. Für die erste und die zweite Phase habe ich nur jeweils einen Tag Arbeit geplant. Den Rest der Zeit verbrachte ich mit dem Erstellen und Scripten von Softwarepaketen. Fazit

Der opsi-Server wird der IT-Abteilung viele Vortei-le bringen. � Die Client-Installationsdauer wurde verkürzt � Software kann automatisiert verteilt werden � Das Inventar basiert auf einer MySQL-

Datenbank Zurückblickend war die IPA eine gute Erfahrung, bei der ich viel neues, vor allem auch praktische Erfahrungen über Zeitpla-nung und Projektmanagement, lernen konnte.

Silvano Brugnoni Woertz AG - EDV

19

Migration nach Microsoft Forefront Client Security

Summaryhead

Da die bestehende Anti-Viren-Lösung in der CTE nicht mehr zufriedenstellend ist und die Lizenz dieses Jahr abläuft, war es meine Aufgabe, ein neues System einzuführen. Als Microsoft Partner entschieden wir uns deswegen für Microsoft Fo-refront Client Security. Summarytext

Microsoft Forefront Client Security ist die hausei-gene Anti-Viren-Lösung von Microsoft. Sie vereint mehrere Anti-Viren-Engines unter einem Hut und soll so optimalen Schutz vor Malware liefern. Da-mit Forefront optimal in eine bestehende Infra-struktur integriert werden kann, stehen verschie-dene Topologien zur Verfügung. Durch diese To-pologien können verschiedene Komponenten ausgelagert werden, so zum Beispiel der Vertei-lungsserver oder die Berichtsdatenbank. Die To-pologie ist abhängig von der Infrastruktur, welche zur Verfügung steht. Da in der CTE bereits ein WSUS-Server für die Verteilung von Updates verwendet wird, entschied ich mich für eine „Zwei-Server-Topologie“. Dabei befinden sich die Ver-waltungs-, Auflistungs- und Berichtskomponenten auf dem gleichen Server. Die Verteilung von Up-dates und Definitionen wird auf den WSUS-Server ausgelagert.

Die Verwaltung von Clients geschieht über soge-nannte Richtlinien. Diese entsprechen im Hinter-grund einer gewöhnlichen Gruppenrichtlinie, wie man sie aus einer Active Directory-Umgebung kennt. In einer solchen Richtlinie werden sämtli-che Einstellungen für die Clients vorgenommen. Dazu gehören Beispielsweise die Zeitpläne für geplante Scans, der Umgang mit gefundener Malware und die Einstellungen für Warnmeldun-gen. Ist eine Richtlinie mit den gewünschten Ein-stellungen konfiguriert, kann diese für eine Orga-nisationseinheit bereitgestellt werden. Die Clients in dieser Organisationseinheit erhalten nun diese Richtlinie zugewiesen und ziehen sich den Agent und die neusten Definitions-Updates vom WSUS-Server. Die Berichterstattung geschieht über den Micro-soft Operations Manager 2005. Dieser stellt Be-richte mit sämtlichen Informationen zum Zustand der Infrastruktur zur Verfügung. Dazu gehören unter anderem Warnungen über gefundene Mal-ware, der Stand der Definitions-Updates auf den einzelnen Clients oder detaillierte Informationen zu verwalteten Computern. Ein zusammenfas-sender Bericht wird einmal im Monat an die Admi-nistratoren zugestellt. So erhalten sie einen Über-blick über den Zustand der gesamten Infrastruk-tur. Warnungen, welche dringende Informationen beinhalten, werden sofort per e-Mail an die Admi-nistratoren gesendet. So kann schnellstmöglich auf die Bedrohung reagiert werden. Während der IPA wurde der Agent auf drei unter-schiedlichen Systemen installiert. Dabei handelt es sich um einen Server, einen Computer und einen Laptop, welche aller unterschiedlichen Ein-stellungen benötigen. Laptops beispielsweise werden nicht vom WSUS-Server verwaltet, da diese meist nicht in der CTE sind. Dadurch müs-sen sie sich Definitions-Updates direkt von Micro-soft Updates herunterladen. Wenn das System nach der IPA weiterhin ein-wandfrei arbeitet, wird es in einen nächsten Schritt für die gesamte Infrastruktur bereit gestellt.

Roman Jeitzinger ControlTech Engineering

20

Entwicklung eines zentralen Ressource-Repositories für JEE Applikationen

Ausgangslage

Bei der Post IT verwenden verschiedenste Appli-kationen gleiche Ressourcen. Dies können Bilder, Cascading Style Sheets, URLs, Übersetzungstex-te oder auch Konfigurationsdateien sein. Diese Ressourcen werden beim Deployment einer Ap-plikation mitgeliefert. Um sie zu ändern, muss von der ganzen Applikation ein neues Release erstellt und ausgeliefert werden. Dadurch sind selbst kleine Änderungen sehr zeitaufwändig und kos-tenintensiv. Deployments im produktiven Umfeld können nicht von den Entwicklern selbst gemacht werden, weshalb noch eine weitere Abteilung in diese Arbeiten involviert ist. Da die betreffenden Ressourcen innerhalb des Post Netzwerkes als public gelten, dürfen sie von allen abgefragt wer-den. Lediglich das Ändern von Daten muss be-rechtigten Personen vorbehalten bleiben. Ziel

Das Ziel der Arbeit ist es, ein zentrales Ressour-cen Repository zu entwickeln in dem solche Res-sourcen abgelegt und zur Laufzeit geändert wer-den können, ohne eine Applikation neu deployen zu müssen.

Lösung

Die Applikation wurde in zwei Teilen entwickelt. Der Server Teil ist für das Speichern und Laden der Ressourcen zuständig. Er verwendet dazu JackRabbit, eine Open Source Implementierung der Java Content Repository Spezifikation. Um die Funktionalität gegen aussen zur Verfügung zu stellen wurde ein Webservice entwickelt. Der Ser-ver kann Ressourcen von mehreren Applikationen in verschiedenen Versionen verwalten. Somit können mehrere Applikationen in verschiedenen Versionen parallel laufen, dasselbe Repository verwenden und dennoch die korrekten Ressour-cen erhalten. Die gespeicherten Ressourcen kön-nen jeweils über einen Schlüssel identifiziert wer-den. Zusätzlich kann die Umgebung in der die Ressource verwendet wird (zum Beispiel Entwick-lung, Integration oder Produktion) sowie die zuge-hörige Sprache abgespeichert werden. Damit eine Applikation auf die Ressourcen zugrei-fen kann, wurde eine Client Komponente entwi-ckelt. Diese gibt Anfragen an den Webservice weiter und bietet einen Caching Mechanismus an. Dadurch wird sichergestellt, dass einmal angefor-derte Ressourcen auch noch zur Verfügung ste-hen wenn keine Verbindung zum Server mehr aufgebaut werden kann. Dies ist besonders wich-tig, da ansonsten Ausfälle des Servers die Arbeit von verschiedenen Applikationen verhindern. Zusätzlich wird durch ein Caching die Performan-ce verbessert. Über die Clientkomponente können ausserdem neue Ressourcen in das Repository eingefügt, verändert oder gelöscht werden. Diese Funktionalitäten sind geschützt und können nur von autorisierten Benutzern aufgerufen werden. Als weiterer Teil der individuellen Praxisarbeit wurde eine Beispielapplikation und ein Repository Editor entwickelt. Die Beispielapplikation zeigt einige Beispielressourcen aus dem Repository an, so zum Beispiel einen Übersetzungstext, einen HTML Link und ein GIF Bild, jeweils in drei Spra-chen. Der Repository Editor bietet die Möglichkeit, die im Repository abgespeicherten Ressourcen über ein graphisches Benutzerinterface zu verwal-ten.

Thomas Jost Die Schweizerische Post

21 Marc Luginbühl ALCAN Technology & Management AG, Neuhausen

Einbindung von Webapplikation(en) in einer DMZ

Umfeld

Unter dem Projektnamen "Rhytech" ALCAN zukünftig als Dienstleister auftreten und Dritt-Firmen ermöglichen, die vorhandene Infrastruktur (vornehmlich Laboreinrich-tungen) nutzen zu können. Damit diese optimal in unse-rer bestehenden Infrastruktur eingebunden werden können und auch IT Services nutzen können, muss das bestehende Netzwerk so aufgetrennt werden, dass gewisse Systeme beziehungsweise Applikationen ge-meinsam, jedoch interne Systeme nur von ALCAN-Mitarbeitern, genutzt werden können. Aufgabenstellung

• Es ist zu analysieren, welche vorhandenen Appli-kationen für die gemeinsame in Betracht gezogen werden müssen. Dabei müssen vor allem die not-wendigen Systemanforderungen und Schnittstellen untersucht werden.

• Bereits vorgegeben ist, dass SQL-basierte Web-anwendungen genutzt werden müssen. Für diese ist eine Testumgebung aufzubauen, in welcher ein-zelne Anwendungen von mehreren Kunden genutzt werden können, ohne dass diese in der heutigen ALCAN-Umgebung integriert sind. Der Zugriff soll über eine Firewall im Netzwerk geschützt werden und die benötigten Anwendungen sollen sich in ei-ner dafür eingerichteten DMZ befinden.

Resultat

Webapplikationen Ich begann mit einer Analyse der momentan im Einsatz stehenden Applikationen. Dazu teilte ich sie nach An-forderungen und erforderlichen Schnittstellen in Katego-rien ein, welche ich dann genauer betrachten konnte. Es stellte sich sich heraus, dass die Existenz der meis-ten Anwendungen vor allem durch das Fehlen der AL-CAN-eigenen Authentifizerungstrukturen und Daten-quellen massiv in Frage gestellt wird. Einer Portierung oder Duplikation einer Applikation in die DMZ wird also zuerst eine inhaltliche, sprich nichtfunktionale Betrach-tung vorausgehen. Weiterhin begnügen sich die meis-ten Applikationen neben dem benötigten Webserver mit einer SQL-Datenbank zur Ablage ihrer Daten. Es han-delt sich um ASP-Applikationen. Durch die geforderte Isolation der DMZ vom ALCAN-Netz blieb mir lediglich die Möglichkeit, die Infrastruktur für die kommenden Untersuchungen und Anpassungen zur Verfügung zu stellen, wobei vorerst mit lokalen Benutzern gearbeitet werden muss. Um die Funktionali-tät der Datenbankanbindung zu überprüfen habe ich auf dem Webserver neben einer blossen Homepage eine kleine autarke Umfrage-Applikation eingerichtet.

Server

Die Server sind nach dem Standard der ALCAN instal-liert und konfiguriert worden. Mit dem 'Internet Informa-tion Services 6.0' und dem 'SQL Server 2000' wurde die Basis für die DMZ-Testumgebung bereitgestellt. Ich habe die zwei Server in unserer virtuellen Umgebung (ESXi-Testsystem) angesiedelt. Dies bietet im Vergleich zu physischen Servern einige Vorteile in den Bereichen Funktionalität und Wartbarkeit. Um die bestehenden virtuellen ALCAN-Systeme netzwerkmässig von den DMZ-Servern zu trennen, musste im Hostsystem (Phy-sischer Server mit virtuellen Gastsystemen) eine zu-sätzliche, für die DMZ dedizierte Netzwerkkarte einge-baut werden. Die Authentifizierung auf die Webapplika-tionen wurde ausgeschaltet (anonymer Zugriff) und beim Datenbankserver wurde die Zugriffssicherheit aufgrund der beschriebenen Problematik mit lokalen Benutzern realisiert. Testumgebung

Die Testumgebung soll möglichst die bestehende LAN-Infrastruktur abbilden und besteht daher aus einem "Core-Switch" sowie zwei "Access-Switches", die je-weils über Glasfaser mit dem "Core-Switch" verbunden sind. Es wurden globale VLANs für ALCAN, DMZ, Fir-ma_A und Firma_B erstellt. So können die Netzwerk-zonen logisch vollständig getrennt werden. Auf den "Access-Switches" sind jeweils Ports für die ALCAN-Zone sowie für die (vorerst) zwei Dritt-Firmen zugeord-net. Am "Core-Switch" sind die Firewall und die DMZ-Server angeschlossen. Weiterhin wurde eine Verbindung zwi-schen der ALCAN-Zone der Testumgebung und der Produktivumgebung realisiert. So kann schon jetzt jeder ALCAN-Client, unter Angabe der Firewall als Router in die DMZ, auf die Server in der DMZ zugreifen. Später wird auf dem produktiven Core-Switch eine statische Route eingerichtet. An die Switches angeschlossen wurde pro Zone je ein Testclient. Die Netzwerkkonfigu-ration der drei Notebooks erfolgt automatisch, was den Realitätsbezug weiter erhöht. Die Notebooks können also zu Testzwecken an beliebigen Ports (Firewall-Zonen) eingesteckt werden. Firewall

Eine Grundkonfiguration der Firewall, vor allem die sicherheitsrelevanten Regeldefinitionen, wurde vorgän-gig mit Unterstützung der Swisscom vorbereitet. Auf-grund der in der Planung ausgewählten Variante muss-te ich die Firewall aber nochmals massiv umkonfigurie-ren, um sämtlichen Verkehr von und zur Firewall über ein einziges Kabel laufen lassen zu können. Dies war aus Gründen der Erweiterbarkeit notwendig, da vorher bereits sämtliche vier Ports belegt waren und so z.B. kein Raum mehr für einen allfälligen Internetanschluss wäre.

22

Etude de faisabilité pour la migration es serveurs Web

Environnement

Avec l’augmentation des besoins au niveau de l’infrastructure et des fonctionnalités, ainsi que dans le cadre de l’utilisation de nouvelles techno-logies, l’Ecole d’Ingénieurs et d’Architectes de Fribourg aimerait migrer ses applications Web. Actuellement les applicatifs sont basés sur le pro-duit Sun Java System Web Server. Le projet comprend plusieurs points spécifiques à réaliser tel que l’étude comparative des produits, l’installation et la configuration du serveur Glass-Fish, l’interconnexion avec les divers systèmes nécessaires tel que l’annuaire d’entreprise (LDAP - Lightweight Directory Access Protocol) ou le serveur de stockage de données en réseau (SAN - Storage Area Network). Objectif

L’objectif consiste à faire une étude de faisabilité puis de migrer vers le produit Sun Java System Application Server (Sun GlassFish Enterprise Server), y compris l’adaptation des applications WEB existantes afin de démontrer la faisabilité du déploiement de ces applications dans ce nouvel environ-nement d’exécution. Cette migration permettra de répondre aux beso-ins et exigences techniques en matière de dé-ploiement d’appli-cations Web basées sur le Framework Java Platform, Enterprise Edition (Java EE). L’évaluation des coûts en termes de temps et ressources nécessaires à l’accomplissement de cette tâche fait également partie de ce projet. Solution - Voie suivie

A. Etude comparative des fonctionnalités entre les produits Sun Java System Web Server et Sun GlassFish Enterprise Server : identifier les nouvelles fonctionnalités offertes et éventuel-lement celles manquantes.

B. Installation et configuration du produit Sun GlassFish Enterprise Server. Interconnexion avec l’annuaire d’entreprise LDAP et le serveur de stockage de données en réseau SAN. Etab-lir une documentation utilisateur technique qui servira de référence lors de la migration effec-tive des serveurs Web. Modification de la con-figuration de plusieurs applications Web exis-tantes et fonctionnelles puis déploiement

C. Evaluation de la migration des serveurs Web. Identification des possibles problèmes de portage des applications d’un serveur Web à l’autre. Principalement les problèmes entre les différentes versions des technologies se rap-portant au Framework Java EE, soit la compila-tion des fichiers sources, l’utilisation des librai-ries Java, et les spécification du fichier de con-figuration des applications Web (web.xml), etc.

D. Identification des problèmes de portage des applications d’un serveur Web à l’autre

E. Evaluation des coûts en termes de temps et ressources nécessaires à l’accomplissement de cette tâche.

Résultat / produit

L’objectif est atteint à 100%. Les trois applications du projet ont pu être implé-mentées sur le serveur GlassFish et elles fonc-tionnent toutes parfaitement. Une explication pour chaque site a été faite (page 39). Le système est actuellement en production.

Conclusion

Ce travail permettra à l’avenir de donner un fil conducteur à la migration des applications sur le nouveau serveur GlassFish. Tout au long de ces 3 semaines, j’ai pu me rendre compte de l’importance d’une bonne planification afin de pouvoir faire les étapes correctement et ainsi évoluer dans le projet. Je retiens une importance majeure qui m’a facilité également le travail, c’est la réalisation du cahier des charges qui était très précise. Ce projet m’apporte de grandes satisfactions sur le plan professionnel et personnel. J’ai pu dé-montrer mes compé-tences d’informaticien ainsi que de collaboration. Sur le plan technique je ressens beaucoup de fierté d’avoir pu tout réaliser dans les délais impartis et que tout fonctionne parfaitement.

Daniel Pauchard Arches Formations Lausanne

23

Integration BlackBerry in bestehende Infrastruktur eines Finanzdienstleisters

Summaryhead

Bisher synchronisierten Sourcag (Finanzdienst-leister) Mitarbeiter ihre Daten mit Hilfe indivi-ueller Lösungen direkt am Geschäftscmputer. Ziel der Facharbeit ist es, eine BlackBerry Server Umgebung und ein End-gerät im Umfeld der Sourcag einzurichten. Das Endgerät muss Inhalte (eMail, Kalender, Adressbuch, Notizen)

drahtlos mit dem bestehenden Exchange Server synchronisieren. Summarytext

Zur Realisierung der Aufgabe wurde ein BlackBer-ry Router in einer DMZ installiert. Dieser stellt die Verbindung zu den Servern des Betreibers von BlackBerry, der Firma Research in Motion (RIM), her. In einer anderen DMZ wurde ein BlackBerry En-terprise Server (BBES) eingerichtet. Dieser stellt eine Verbindung zum Exchange Server her und kann damit auf die Mailboxdaten zugreifen. Zu-dem regelt der BBES die Verschlüsselung und übernimmt das Handling mit Dateianhängen. Die Konfiguration speichert der BBES in einer Daten-bank ab. Dazu wird der bestehende Datenbank-server der Sourcag verwendet. Der BBES stellt eine Verbindung mit dem oben beschriebenen BlackBerry Router her. Die beiden Geräte werden standardmäßig über-wacht, ein Backup findet lediglich von der Daten-

bank statt, da auf den Systemen keine Daten gespeichert werden. Die Sicherheit wird mit Hilfe einer Verschlüsse-lung und vielen Policyeinstellungen gewährleistet. Die Verbindung wird vom BlackBerry Router über ein spezielles BlackBerry Protokoll hergestellt. Der Zugriff von aussen (vom Internet her) auf den BlackBerry Router ist nicht möglich. Die Endgeräte kommunizieren drahtlos über das Mobilfunknetz (z.B. Swisscom), die Benutzer müssen keine manuelle Synchronisierung vor-nehmen, die Daten sind, sofern eine Verbindung besteht, stets aktuell.

Philipp Stampfli Sourcag AG

24

FTP-Server für Datenaustausch mit Kunden der Trivadis AG

Umfeld und Aufgabenstellung

In meiner IPA ging es um die Installation einer Datenaustauschplattform für Consultants der Tri-vadis AG und ihren Kunden. In der Trivadis arbei-teten zu diesem Zeitpunkt an die 500 Consultants und es existierte noch keine Plattform über die schnell Daten mit den Kunden ausgetauscht wer-den konnten. Es wurde zu meiner Aufgabe ge-macht, eine solche Plattform zu erstellen. Im Vor-dergrund standen vor allem Funktionalität und Sicherheit. Im Bild ist die Netzwerkumgebung, welche am Ende der Arbeit aufgebaut war, zu sehen. Natür-lich ist diese nicht vollständig, über die Kernthe-men meiner IPA gibt sie jedoch weit genug Aus-kunft.

Lösung und Resultate

Ich hatte die Ziele meiner IPA vollumfänglich er-reicht. Die Dokumentation war gelungen und der Service war einsatzbereit. Der Lösungsweg, wel-cher gewählt wurde, um dies zu erreichen, schrieb die folgenden Arbeitsschritte vor: � Ausführliches Sicherheitskonzept schreiben � Sicherheitskonzept vom Sicherheitsbeauftrag-

ten und vom IT-Leiter abnehmen lassen � Netzwerk nach dem Sicherheitskonzept konfi-

gurieren lassen � Microsoft Windows Server 2003 R2 mit HP

SmartStart installieren � Betriebssystem gemäss dem Sicherheitskon-

zept konfigurieren � Betriebssystem abhärten und Sicherheitslü-

cken schließen � FileZilla installieren � FileZilla entsprechend dem Sicherheitskon-

zept konfigurieren � Ganze Umgebung testen

Simon Weber Trivadis AG, Glattbrugg

25

Support

26

Beste IPA 2009 der Schweiz: Support

Installation und in Betriebnahme eines Notebooks für Coca-Cola Techniker im Aussendienst

Installation und in Betriebnahme

Sie erhalten ein bereits imagiertes Notebook. Richten Sie dieses gemäss Coca-Cola Standard mit der üblichen SW für TES Techniker ein. Die Einbindung in die Domäne ist nicht möglich, ver-wenden sie anstelle dessen einen lokalen User mit den üblichen Rechten. Da der Mitarbeiter im Aussendienst arbeitet, erhält er eine Swisscom Unlimited Card mit SIM (CNA aufgeschaltet), Lo-tus Notes mit lokalem Mailfile-Replikat, den TES Datenbanken und den üblichen DBs. RAM Erweiterung: Tauschen Sie die eingebauten 256 MB RAM durch ein 1GB Modul aus. Reparatur eines Notebooks + Erweiterung nach Kundenwunsch

Herr Zero bringt ein Notebook bei Ihnen zur Repa-ratur. Am Notebook meldet er mehrere Probleme: � Sein Notebook hat nach dem Einschalten

manchmal kein Bild

� Sofern ein Bild erscheint, startet der PC nicht mehr von der Festplatte

� Bevor all dies passierte, funktionierte TwixTel nicht mehr.

� Auf dem Desktop befindet sich eine Datei Maus1.JPG und obwohl diese gelöscht wur-de, erscheint sie immer wieder.

Ausserdem möchte Herr Zero sein Notebook ger-ne durch mehr Festplattenspeicher aufrüsten. Aktuell hat er 20 GB und er hätte neu gerne 60 GB. Diese Festplatte kostet 100 Fr.- Seine aktuel-le Installation (Windows + Daten) darf nicht verlo-ren gehen, er hätte diese gerne 1:1 übernommen. Multimediales Anzeigesystem

Die Abteilung „Internal Communications“ der Co-ca-Cola Beverages AG hat das Bedürfnis zentral verwaltet und Lokationsübergreifend Informatio-nen elektronisch anzuzeigen. Als Beispiele seien genannt: Aktuelle Verkaufszahlen, aktuelle Video-spots, Wer ist zu Besuch? usw. Aus diesem Grund beauftragt „Internal Communi-cations“ die IT-Abteilung (sie) einen Vorschlag zu erarbeiten sowie Ihre Lösung zu offerieren.

Simon Hanselmann Coca-Cola Beverages AG

27

PC-Installationen, Reparaturen an PC’s

Installation und Inbetriebnahme

Installieren sie den neuen Rechner mit RAID 1 und aktuellstem System.

Installieren sie die bestellte Software und über-nehmen sie die Benutzerdaten inkl. E-Mails, Ad-ressen und diversen Einstellungen.

Aktualisieren sie auf dem Powermac G5 alle Soft-ware und prüfen sie das System.

Der Kunde will die Weiterarbeit gewährleistet ha-ben.

Kontroll- und Revisionsarbeiten

Herr Steffen bringt einen defekten iMac G5 20“ zur Reparatur. Er klagt über folgende Mängel:

� Startet nicht, nur LED leuchtet

� Kein Bild und kein Startton

Dieses Gerät hat keine Garantie mehr und der Kunde wünscht einen Kostenvoranschlag. Kos-tenvoranschlag muss vom Kunden bestätigt wer-den.

Geben Sie diesen dem Experten ab und reparie-ren Sie das Gerät dem KV entsprechend.

Frau Albrecht bringt ein defektes Macbook Pro zur Reparatur. Sie klagt über folgende Probleme:

� Das Laufwerk erkennt keine CDs/DVDs wirft sie nicht mehr aus(CD noch drin).

� Das Gerät kann nicht geladen werden (kein Strom)

Dieses Gerät steht unter der Apple-Hersteller-Garantie und kann somit sofort repariert werden. Finden Sie die richtigen Teile und reparieren Sie das Gerät nach Ihrer Diagnose.

Fachberatung und Instruktion

Es sollen 3 Arbeitsstationen eingerichtet und in-stalliert werden, wobei Herr Meier bereits einen PowerMac G5 inkl. eines 23“ Apple Cinema-Displays besitzt. 2 Arbeitsstationen werden hauptsächlich in der administrativen Umgebung tätig sein. Der 3. Arbeitsplatz sollte für Grafik, Animation und Layout ausgerichtet sein. Der Kunde wünscht als Grafikstation ganz klar eine starke Maschine, da diese ausgenutzt wer-den wird. (iMacs als „kleine“ Arbeitsstattionen (20“od24“) MacPro als Grafikstation). Herr Meier kann sich gut vorstellen auf den be-stehenden PowerMac G5 zu verzichten, wenn der nicht anderweitig eingesetzt werden kann (Beste-hender Rechner aufrüsten für GrafikStation). Zusätzlich benötigt die Firma einen Server, worauf die Daten gesichert werden können und auch das Backup sollte mitofferiert werden. Erstellen sie eine Offerte mit allfälligen Optionen oder Empfehlungen und tragen sie diese dem Kunden mündlich vor.

Remo Zemp Tomac Computer Concept AG

28

PC-Installation inkl. Netzanschluss, automatischem Backup, Erstellung Image

Installation und Inbetriebnahme

Bauen Sie gemäss der beiliegenden Stückliste ein Mastergerät zusammen und installieren dies. Der Kunde wünscht die Installation von Word, Excel und Outlook aus dem Office 2007 Packet. Auch die benutzerspezifischen Einstellungen sind vor-zunehmen. Alle Daten müssen auf einer separa-ten Partition gespeichert werden, alle Programme müssen dementsprechend eingerichtet werden.

Richten Sie ein E-Mail Konto ein. (Internetzugriff über Breitband).

Die Datensicherung erfolgt auf einer externen Festplatte. Alle geänderten Daten müssen täglich gesichert werden. Einmal in der Woche (Freitag) müssen alle relevanten Dateien gesichert werden. Verwenden Sie dazu eine Software Ihrer Wahl.

Installieren Sie die Microsoft Desktop Search 4.0 Funktion. Die Konfiguration soll nur das Outlook 2007 und das Daten-Verzeichnis enthalten. Erstellen Sie mit der beiliegenden Tools-CD ein Image Ihrer Installation. Installieren Sie im weite-ren einen Barcodescanner mit schweizer Tasta-tureinstellungen.

Kontroll- und Revisionsarbeiten

Frau Maier bringt einen defekten PC zur Repara-tur und wünscht gleichzeitig eine Aufrüstung des Systems. Der Arbeitsspeicher soll von 1GB auf 2GB aufgerüstet werden.

Erstellen Sie einen KV über die zu reparierenden Teile.

Symptome des PCs:

� Kein Bild

� DVD-ReWriter wird nicht immer erkannt

� DVDs lassen sich nicht sauber abspielen

� TV-Tuner bringt kein Bild

� aufnehmen von Sendungen nicht möglich

� kompletter Systemcheck durchführen

Zusätzlich zur Aufrüstung möchte Frau Maier noch einen WLAN-Router kaufen. Sie möchte aber, dass das Gerät vorkonfiguriert wird, damit Sie es zu Hause nur noch anschliessen muss. Alle Geräte müssen per WLAN angeschlossen werden, auch der PC. Die Kommunikation erfolgt über eine Sichere WLAN-Verbindung.

Richten Sie noch eine Datensicherung auf einem USB-Stick ein.

Fachberatung und Instruktion

Herr Meier (Experte) möchte in den nächsten Wochen sein Architektur-Büro (4 Administrative Mitarbeiter und 8 Architekten) mit einer neuen IT-Infrastruktur ausstatten. Dazu gehören leistungs-starke CAD-Workstations mit entsprechenden Monitoren und normale Systeme für Office-Anwendungen.

Des Weiteren werden noch diverse Arbeitsgrup-pen-Drucker und ein Plandrucker benötigt.

Alle Komponenten müssen unter dem Gesichts-punkt „Green IT“ ausgewählt werden.

Weiterhin benötigt Herr Meier einen Zentralen Datenspeicher mit Backuplösung. Die Mails der einzelnen Mitarbeiter sind Servergespeichert. Die Server sollen gegen Überspannung und Strom-ausfälle gesichert werden.

Der Internet-Zugang erfolgt zentral und muss durch einen Router mit Firewall gesichert werden. Für zukünftige Erweiterungen, Home-Office Ar-beitsplätze, muss der Router VPN unterstützen.

Erstellen Sie einen Netzwerkplan.

Präsentieren Sie dem Kunden Ihre Lösungen und erklären Sie die Unterschiede.

Philippe Pfiffner Jet Schweiz IT AG