D08-QM-2 Operative Planung und Durchführung von Reviews und Release-Updates

Größe: px
Ab Seite anzeigen:

Download "D08-QM-2 Operative Planung und Durchführung von Reviews und Release-Updates"

Transkript

1 D08-QM-2 Operative Planung und Durchführung von Reviews und Release-Updates (Fraunhofer SIT) Prüfung: Sven Wohlgemuth (TU Darmstadt/CASED) Typ: [TECHNISCHER BERICHT] Projekt: Version: 1.0 Datum: 25. Juni 2013 Status: [FREIGABE] Klasse: [ÖFFENTLICHKEIT] Datei: D08-QM-2 Operative Planung und Durchführung von Reviews und Release-Updates.docx Zusammenfassung In D08-QM Review-Konzept PersoApp wurden vier unterschiedliche Reviewtypen beschrieben, die im Verlauf von anzuwenden sind. Das vorliegende Dokument widmet sich der operativen Planung und Durchführung dieser unterschiedlichen Reviewtypen. Neben ausführlichen Beschreibungen liefert das Dokument Vorlagen und Checklisten, die zur Unterstützung der einzelnen Aktivitäten herangezogen werden können. Konsortialleitung: Prof. Dr. Ahmad-Reza Sadeghi und Dr. Sven Wohlgemuth System Security Lab, TU Darmstadt/CASED, Mornewegstr. 32, Darmstadt Tel.: Fax: Web: https://www.persoapp.de

2 Nutzungslizenz Die Nutzungslizenz dieses Dokumentes ist die Creative Commons Nutzungslizenz Attribution-ShareAlike 3.0 Unported 1. Mitglieder des Konsortiums 1. AGETO Service GmbH, Deutschland 2. Center for Advanced Security Research Darmstadt (CASED), Deutschland 3. Fraunhofer Institut für Sichere Informationstechnologie (SIT), Deutschland 4. Technische Universität (TU) Darmstadt, Deutschland Versionen Version Datum Beschreibung (Editor) Initiale Version (Fraunhofer SIT) Kapitel 5.2, 5.4 (Fraunhofer SIT) Kapitel 5 ergänzt (AGETO) Version zum Review durch TU Darmstadt (Fraunhofer SIT) Freigabe (Fraunhofer SIT) Autoren Autoren Philipp Holzinger (Fraunhofer SIT) Stefan Triller (Fraunhofer SIT) Beiträge Kapitel 5.5, Anhang A-E Kapitel 5.2, 5.3 Jens Kubieziel (AGETO) Kapitel 5.1, 5.2, Version Juni 2013 Seite 2/43

3 Inhaltsverzeichnis 1 Ziel und Zweck des Dokumentes Anwendungsbereich Abkürzungen und Begriffsdefinition Zuständigkeiten und Verantwortlichkeiten Operative Planung und Durchführung von Reviews und Release-Updates Der -Release-Zyklus Ablauf der Major-Release-Zyklen Ablauf des Einreichprozesses Verkürzter Release-Prozess Technisches Review Informelles Review Inspektion eines Major-Release-Update Management Review Interne und externe Anforderungen Mitgeltende Dokumente Anhang A Protokollvorlage für Reviewmeeting Anhang B Checkliste Management Review Anhang C Checkliste zur Sicherheitsarchitektur von Softwarereleases Security-relevant aspects of the software Outlining the software to develop Key properties High-level data flow diagram Historical information of security incidents Security incident history Quick assessment Creating security profiles for software components and other similar software projects Security profile for similar software projects Identify asset stakeholders Collect relevant assets Specify and rank security objectives for assets Version Juni 2013 Seite 3/43

4 1.7 List actors that interact with the software List intended role changes provided to the actors Classify processed data Identify technologies, platforms, and architectural paradigms Identify and prioritize threats Weaknesses identified using CWE Threats identified with STRIDE Attacker-motives assessment Threat prioritization Security architecture and design Outline Detailed data flow diagram Functional security design Security dependencies and trust relationships Secondary assets Security objectives for secondary assets Trusted actors and trusted environments Exposed entities Asset manifestations Generic data sinks Access path policy Security design tradeoffs Security priorities by role/task General considerations Security areas of concern Reference database filters Development action plan Secure programming guidance materials Secure coding plan Implementation constraints Component and platform versions Build action plan Release version build options Version Juni 2013 Seite 4/43

5 4.3.2 Build cleanup Secure default configuration Interactive security configuration Secure deployment requirements Testing action plan External testing requirements Security testing policy Entry points and exit points Attack success conditions Vulnerability rating model Documentation action plan Target operational environment(s) Components configuration constraints Security implications of configuration and deployment options User-dependent mechanism strength System administrator security tasks Anhang D Fragebogen zu externen Bibliotheken Anhang E Checkliste für die Programmierrichtlinie und Qualitätsmetriken Der Fragebogen aus Version Juni 2013 Seite 5/43

6 1 Ziel und Zweck des Dokumentes Die Entwicklung qualitativ hochwertiger Software bedarf der Anwendung bewährter Prozesse und Methoden, die die Erstellung und den Test von Komponenten begleiten. Um über den Projektverlauf eine planmäßige, nutzbringende, effiziente und erwartungsgemäße Anwendung von Methoden und Werkzeugen zu gewährleisten, bedarf es einer kontinuierlichen Begutachtung der Projektfortschritte und der Teilergebnisse. In D08-QM Review-Konzept PersoApp wurden vier unterschiedliche Reviewtypen beschrieben, die im Verlauf des PersoApp-Projekts anzuwenden sind. Das vorliegende Dokument widmet sich der operativen Planung und Durchführung dieser unterschiedlichen Reviewtypen. Neben ausführlichen Beschreibungen liefert das Dokument Vorlagen und Checklisten, die zur Unterstützung der einzelnen Aktivitäten herangezogen werden können. 2 Anwendungsbereich Die Festlegungen, die in diesem Dokument getroffen werden, sind über den gesamten Projektverlauf für jede Reviewdurchführung zu beachten. Zeitliche und organisatorische Einzelheiten werden im Folgenden für jeden Reviewtyp detailliert vorgestellt. Die Anwendung der beigefügten Vorlagen und Checklisten ist, sofern nicht anders angegeben, optional. Prozessbeschreibungen für die Durchführung von Code- und Dokumentations- Reviews zur kontinuierlichen Sicherstellung der Qualität sind dem mitgeltenden Dokument D08-QM-3 Prozessbeschreibung zur Durchführung von Code-Reviews und Sicherstellung der Dokumentationsqualität zu entnehmen. Version Juni 2013 Seite 6/43

7 3 Abkürzungen und Begriffsdefinition Begriff Abkürzung Definition IEEE Std Hierdurch wird die aktuelle Ausgabe des IEEE Standard for Software Reviews and Audits referenziert. Das Dokument beschreibt die folgenden fünf grundlegenden Typen: Management Review Technisches Review Inspektion Walk-Through Audit Einzelne Festlegungen, die das vorliegende Dokument trifft, erfolgen in Anlehnung an diesen Standard. 4 Zuständigkeiten und Verantwortlichkeiten Die Einhaltung der im Folgenden getroffenen Festlegungen obliegt jedem Projektteilnehmer, der direkt oder indirekt an einem Review beteiligt ist. Unter einer direkten Beteiligung wird hier die aktive Teilnahme an einem Review verstanden. Als indirekt beteiligt gilt hier ein Projektteilnehmer, dessen Projektarbeit in irgendeiner Weise durch ein Review beeinflusst wird, beispielsweise etwa, weil ihm die Nachbesserung eines Reviewgegenstandes obliegt. 5 Operative Planung und Durchführung von Reviews und Release-Updates 5.1 Der -Release-Zyklus Innerhalb des Projektes sind sechs Pre- oder Major Releases vorgesehen. Diese bestehen aus einem Pre-Release zu einem frühen Zeitpunkt und weiteren Major-Releases im weiteren Verlauf. Der Releasezyklus zwischen den Major- Releases wurde auf sechs Monate festgelegt. Der Ausgangspunkt (T 0 ) für die Releasezyklen wird durch die Bereitstellung einer lauffähigen Basisversion markiert. Dieses Pre-Release ist unter den gängigen Betriebssystemen Microsoft Windows, Mac OS X und GNU/Linux 2 lauffähig. Es benötigt eine grafische Oberfläche, da die Steuerung der Software über die systemeigene Taskbar erfolgt. Das Kernentwicklungsteam ist für diese Aufgabe hauptsächlich zuständig. Der Abschluss erfolgt drei Monate nach Projektbeginn. Danach beginnen die 2 Getestet unter Ubuntu, Debian, Fedora, OpenSUSE und Gentoo. Version Juni 2013 Seite 7/43

8 Major-Release-Phasen. Diese sind in den untenstehenden Abschnitten genauer beschrieben Ablauf der Major-Release-Zyklen Jeder Major-Release-Zyklus unterteilt sich in zwei aufeinanderfolgende Phasen: 1. Entwicklungsphase 2. Testphase Die erste Phase (Entwicklungsphase) erstreckt sich über fünf Monate. Der Hauptzweck dieser Phase ist es, in Zusammenarbeit mit der Community Fehler in der Software zu identifizieren und diese anschließend zu beheben. Hierzu treten die Mitglieder aus der Community über die Kommunikationskanäle in Verbindung und melden Fehler. Diese Rückmeldung sollte idealerweise über das Bug-Tracking-System von erfolgen. Dort werden die Fehler eingetragen und der Entwickler hat die Möglichkeit, systematisch an Verbesserungen zu arbeiten sowie über einen definierten Kanal mit dem Einreicher eines Fehlers in Kontakt zu treten. Es wird empfohlen, dass Meldungen über Fehler bzw. Verbesserungen der Software, welche nicht über das Bug-Tracking-System eingereicht werden, durch den Entwickler selbst nachzutragen. Damit bleibt für alle interessierten Anwender wie Entwickler ein eindeutiger, zentraler Kanal, wo existierende und behobene Vorfälle registriert sind. Neben reinen Kommentaren besteht natürlich ebenso die Möglichkeit, Verbesserungen in Form von Patches einzureichen. Dies sind meist kleine Dateien, die Änderungen am Quellcode vorschlagen. Hier ist es ebenso sinnvoll, dass alle Patches im Bug-Tracking-System registriert sind. Entweder der Einreicher hängt die Patches direkt an den Eintrag im Bug-Tracking-System an oder es verbleibt in der Verantwortung des Entwicklers. Dieser kann einen Patch ebenso an den Eintrag anfügen. Alternativ besteht die Möglichkeit, auf eine Version im Versionskontrollsystem zu verweisen. Diese Version sollte jedoch nur den einen Patch enthalten. Eine dritte Klasse von möglichen Änderungen im Laufe der Entwicklungsphase sind so genannte Feature Requests. Dies sind Vorschläge für neue Funktionen innerhalb der Software oder auch für Änderungen im existierenden Ablauf des Programms. Feature Requests werden ebenso im Bug-Tracking-System aufgenommen und dort zentral gesteuert. In allen Fällen ist es wichtig und sinnvoll, der einreichenden Person eine zeitnahe Rückmeldung zu geben. Erfahrungsgemäß erhält dies die Motivation, weiterhin am Projekt mitzuarbeiten und ggf. später weitere Meldungen einzureichen. Fehlende Rückmeldungen hingegen können leicht zu Frustration und zu weniger konstruktiver Mitarbeit führen. Über die Projektwebseite wird Anwendern wie Entwicklern eine Möglichkeit zur Abgabe von Fehlermeldungen, Verbesserungen etc. zur Verfügung gestellt. Nachdem die oben vorgestellten Meldungen über die Software eingegangen sind, wird ein Prozess zur Bewertung bzw. Review der Meldungen initiiert. Der Einreichprozess selbst wird unten näher beschrieben. Version Juni 2013 Seite 8/43

9 Am Ende von Phase 1 steht ein so genannter Feature Freeze. Ab diesem Zeitpunkt werden keine Anfragen für neue Funktionalitäten (Features) angenommen. Der Feature Freeze ist gleichzeitig der Startpunkt von Phase 2, der Testphase. Die Phase 1 sollte sich über fünf Monate erstrecken, währenddessen die Phase 2 etwa einen Monat andauert. Im Dokument D09-QM-2 Release-Management von Software-Modulen und Dokumente der Open-Source ist der Testprozess dokumentiert. Innerhalb von Phase 2 werden weiterhin Patches akzeptiert. Diese dienen in der Regel der Behebung von Softwarefehlern und Sicherheitslücken. Damit leisten diese einen Beitrag zur Verbesserung der Qualität der Software. Dagegen werden keine neue Funktionalitäten (Features) akzeptiert. Die Entwicklung neuer Features wird für die nächste Entwicklungsphase zurückgestellt. Dies kann entweder über das Bug- Tracking-System geschehen. Alternativ kann der Entwickler im Vorfeld einen neuen Zweig innerhalb der Versionsverwaltungssoftware einrichten, wo Patches für neue Features eingepflegt werden. Der Einreicher eines Features ist ggf. von der späteren Aufnahme der Änderungen und dem Eintrag im Bug-Tracking-System zu informieren. Der Release Manager kann von der obigen Regel abweichen und trotzdem neue Features innerhalb des Feature Freeze implementieren. Dies kann sich bei sehr kleinen Neuerungen oder Spezialfällen anbieten. Innerhalb der Testphase kann eine Testversion der Community bereitgestellt werden. Dies ist kein offizielles Release, sondern dient externen Testpersonen, Neuerungen auszuprobieren und Fehler zu finden. Die Testphase wird durch ein Major Release abgeschlossen. Endanwendern wird empfohlen, die neu herausgegebene Version der PersoApp einzusetzen und darauf basierend Fehler zu melden. Diese Fehler werden innerhalb einer anschließenden Entwicklungsphase aufgenommen und es wird versucht, diese zu beheben. In der Regel erfolgt kein Backporting : Fehler, die in der aktuellen Variante der Software gefunden worden, werden nicht in alten Versionen behoben. Stattdessen sollten Endanwender immer das jeweils aktuellste Major Release einsetzen Ablauf des Einreichprozesses Die Software ist in ihrer internen Architektur in verschiedene Module zerlegt. Jedem Modul wird ein Entwickler zugeordnet. Dabei kann ein Entwickler mehrere Module betreuen. Wenn eine Meldung im Bug-Tracking-System eingeht, wird die Meldung dem Entwickler für das entsprechende Modul zugeordnet. Dieser muss entscheiden, ob dies wirklich seinem Aufgabengebiet obliegt. Gegebenenfalls erfolgt eine Neuzuordnung zu einem anderen Modul. Anschließend muss der verantwortliche Entwickler eine Bewertung vornehmen. Bei gemeldeten Fehlern in der Software ist zuerst zu prüfen, ob der Fehler nachvollziehbar ist. Gegebenenfalls muss der Entwickler mit dem Reporter des Fehlers Kontakt aufnehmen und weitere Informationen erfragen. Diese Kontaktaufnahme erfolgt über Version Juni 2013 Seite 9/43

10 das Bug-Tracking-System. Nachdem Erhalt aller wichtigen Informationen kann der verantwortliche Entwickler versuchen, den Fehler zu beheben bzw. andere versuchen, Lösungen zu finden. Im Allgemeinen kann nicht garantiert werden, dass alle innerhalb einer Entwicklungsphase gemeldeten Fehler auch in dieser Phase behoben werden. Die Behebung ist oft ein sehr zeit- und arbeitsaufwändiger Prozess. Fehler können auch nur unter bestimmten Konstellationen auftreten. Die Erfahrung mit anderen Projekten zeigt, dass gerade bei speziellen Fehlern die Lösung dieser Fehler lange Zeiträume (eine oder mehrere Jahre) beanspruchen kann. Im Falle von Patches, die von externer Seite eingereicht werden, wird ein Review- Prozess initiiert. Die Details des Prozesses sind im Dokument D08-QM-2 Operative Planung und Durchführung von Reviews und Release-Updates definiert. Eingehende Feature Requests werden vom verantwortlichen Entwickler ebenfalls bewertet und auf Umsetzbarkeit geprüft. Die Ergebnisse dieser Prüfung sind im Bug- Tracking-System zu dokumentieren. Das neu zu entwickelnde Feature kann vom Entwickler selbst oder von Dritten implementiert werden. Gegebenenfalls wird die Implementierung wieder einem Review-Prozess unterworfen Verkürzter Release-Prozess In Ausnahmefällen kann der Bedarf nach einem Release entstehen, der außerhalb der oben definierten Zeiträume liegt. Dies ist insbesondere der Fall, wenn schwere Fehler oder kritische Sicherheitslücken in der Software gefunden wurden. Dies macht es notwendig, schnell zu reagieren und Endanwender nicht unnötig längere Zeit Unannehmlichkeiten oder Gefahren auszusetzen. Nachdem die entsprechende Meldung eingegangen ist, ist diese wieder vom verantwortlichen Entwickler zu prüfen und bewerten. Sollte der Entwickler ebenfalls zu der Einschätzung gelangen, dass es sich um einen schweren Fehler oder eine kritische Sicherheitslücke handelt, so ist die Meldung im Bug-Tracking-System entsprechend einzustufen. Aufgrund der Natur des gemeldeten Fehlers liegt in der Behebung hohe Priorität und der verantwortliche Entwickler muss entsprechend handeln. Dies bedeutet zum einen, dass schnellstmöglich versucht wird, den Fehler zu beheben. Andererseits kann es sinnvoll sein, die Community über den Fehler zu informieren. Bei Meldungen über Sicherheitslücken wird meist ein Zeitraum vorgegeben, in dem der Fehler behoben sein muss oder eine Lösung gefunden werden muss (Responsible Disclosure). Seitens des Entwicklers ist darauf zu achten, dass der Zeitraum eingehalten wird oder gegebenenfalls Kontakt zum Einreicher aufgenommen wird. Für schwere Fehler kann es sinnvoll sein, einen zweiten, nicht öffentlichen Kanal zur Einreichung zu etablieren. Denn das unmittelbare Wissen über diesen Fehler kann Systeme der Endanwender in unnötiger Weise in Gefahr bringen. Die Basis für die Behebung schwerer Fehler oder kritischer Sicherheitslücken ist das letzte Major Release. Ausgehend von dieser Version wird eine Korrektur entwickelt. Dieses Vorgehen vermindert die Komplexität. Denn innerhalb der Entwicklungsphase werden unter Umständen neue Features entwickelt oder experimentelle Änderungen Version Juni 2013 Seite 10/43

11 gemacht. In der Regel sind diese nicht vollständig ausgetestet. Damit würde die Gefahr neuer Fehler oder Schwachstellen entstehen. Hingegen wurde das letzte Major Release getestet und die Anzahl weiterer möglicher Fehler oder Schwachstellen ist minimal. Nachdem die Entwicklung der Korrektur beendet ist, wird ein Review- und Test- Prozess nach den Dokumenten D09-QM-2 Release-Management von Software- Modulen und Dokumente der Open-Source und D08-QM-2 Operative Planung und Durchführung von Reviews und Release-Updates initiiert. Bei erfolgreicher Beendigung der obigen Prozesse wird die Software zum Download bereitgestellt. Spätestens an dieser Stelle ist darauf zu achten, dass die Endnutzer über das Release informiert werden. Diese Information sollte klar benennen, wo der Grund für den verkürzten Release-Prozess liegt und wo die möglichen Gefahren für den Endanwender liegen. Unter Umständen sollte die Downloadvariante der Vorversion der Software einen deutlichen Hinweis auf die aufgetretenen Probleme erhalten. Damit ist für zukünftige Nutzer klargestellt, dass die Benutzung dieses speziellen Release nicht angeraten wird. Von einer kompletten Entfernung der problematischen Vorversion ist abzuraten. Üblicherweise verteilt sich die Software im Laufe der Zeit an andere Stellen. Damit ist auch die problematische Version mit wenig Aufwand durch Dritte zu finden. Andererseits ist je nach dem spezifischen Vorgehen des Software-Entwicklers klar, wie sich diese Version zusammensetzt. Meist werden in der Versionsverwaltung Tags zur Markierungen spezieller Meilensteine benutzt. Auf diesem Wege könnte die Software-Version wiederhergestellt werden. Eine entsprechende Warnung zusammen mit der downloadbaren Version hat den Vorteil, dass dem Nutzer klar gemacht wird, dass dies ein Risiko darstellt. Bei den anderen Varianten ist dies nicht unbedingt der Fall. Nachdem die Software im Rahmen des verkürzten Release-Zyklus veröffentlicht wurde, beginnt eine neue Entwicklungsphase. Der verantwortliche Entwickler versucht, die Änderungen der vorigen Entwicklungsphase (Vor der verkürzten Release- Phase) neu in den Quellcode aufzunehmen. Dabei müssen unter Umständen Anpassungen der alten Änderungen vorgenommen werden. Je nach Schweregrad der Änderungen kann der Prozess im Bug-Tracking-System dokumentiert werden. Die weitere Entwicklung erfolgt schließlich nach den obigen Vorgaben mit der Entwicklungsund Testphase. 5.2 Technisches Review Für das Projekt wurden bereits im Vorfeld feste Termine für das Technische Review definiert. Demnach findet für die Major Releases in den Projektmonaten 13, 19, 25 und 31 jeweils ein (technischer) Review statt. Weiterhin kann ein Technischer Review jederzeit von den Projektteilnehmern initiiert und durchgeführt werden. Das Fraunhofer SIT hat zu diesem Technischen Review eine Sicherheits- Checkliste erstellt die als Anhang ( Checkliste zur Sicherheitsarchitektur von Softwarereleases ) zu diesem Dokument geliefert wird. Für die Einbindung externer Bib- Version Juni 2013 Seite 11/43

12 liotheken hat das Fraunhofer SIT den Anhang Fragebogen zu externen Bibliotheken erstellt. Wie im Dokument D08-QM Review-Konzept PersoApp festgelegt, ist die Grundlage für die Planung und Durchführung der Reviews der Standard IEEE Std In Anlehnung an dieses werden folgende Rollen für das Technische Review festgelegt: Entscheidungsträger Der Entscheidungsträger bewertet, ob die Reviewziele erreicht worden sind. Gegebenenfalls kann diese Rolle vom Initiator des Reviews eingenommen werden. Reviewleiter Der Reviewleiter plant und leitet das Reviewmeeting. Er unterstützt die Teilnehmer bei der Erreichung der Reviewziele und trägt die Verantwortung dafür, dass die Reviewergebnisse an die beteiligten Projektteilnehmer kommuniziert werden. Protokollant Der Protokollant dokumentiert die Reviewdurchführung, um sie für andere Projektteilnehmer nachvollziehbar und verständlich zu machen. Hierfür kann die Vorlage aus Anhang A Protokollvorlage für Reviewmeeting verwendet werden. Im Gegensatz zum Technischen Review ist eine solche Dokumentation jedoch nicht verpflichtend zu erstellen, daher ist auch die Besetzung dieser Rolle optional. Technischer Gutachter Der technische Gutachter bringt seine fachliche Kompetenz zur Bewertung des Reviewgegenstandes ein und leistet daher einen wesentlichen Beitrag zur Erreichung der Reviewziele. Hierbei ist zu beachten, dass eine Rolle auch von mehreren Personen besetzt werden kann, und eine Person auch mehrere Rollen einnehmen kann. Die Durchführung des Reviews erfordert, dass der Reviewleiter im Zuge der Vorbereitungen alle notwendigen Vorabinformationen an die Teilnehmer versendet (z.b. relevante Standards, Richtlinien, etc.) und den Reviewgegenstand (also z.b. das Dokument, den Quelltext, etc.) entsprechend verfügbar macht. Das Fraunhofer SIT hat zu diesem Technischen Review eine Sicherheits- Checkliste erstellt, die als Anhang ( Checkliste zur Sicherheitsarchitektur von Softwarereleases ) zu finden ist. Für die Einbindung externer Bibliotheken hat das Fraunhofer SIT den Anhang Fragebogen zu externen Bibliotheken erstellt. 5.3 Informelles Review Das Informelle Review, gemäß seiner allgemeinen Beschreibung in D08-QM Review-Konzept PersoApp, ist stark an der Vorgehensweise für die Durchführung eines Technischen Reviews angelehnt. Es ist nicht fest in den Entwicklungs-, Testund Release-Zyklus des -Projektes eingeplant und kann daher zu jeder Zeit von den Projektteilnehmern initiiert und durchgeführt werden. Version Juni 2013 Seite 12/43

13 Für die Durchführung gilt es mindestens ein, oder gegebenenfalls mehrere Reviewziele festzulegen. Dabei kann es sich beispielsweise um Folgendes handeln: Überprüfung der Konformität zu einer Richtlinie, einem Standard, etc. Sicherstellung der Benutzbarkeit einer Softwarekomponente Verständlichkeit, Vollständigkeit, etc. Des Weiteren gilt es die folgenden Rollen zu besetzen (angelehnt an IEEE Std ): Entscheidungsträger Der Entscheidungsträger bewertet, ob die Reviewziele erreicht worden sind. Gegebenenfalls kann diese Rolle vom Initiator des Reviews eingenommen werden. Reviewleiter Der Reviewleiter plant und leitet das Reviewmeeting. Er unterstützt die Teilnehmer bei der Erreichung der Reviewziele und trägt die Verantwortung dafür, dass die Reviewergebnisse an die beteiligten Projektteilnehmer kommuniziert werden. Protokollant Der Protokollant dokumentiert die Reviewdurchführung, um sie für andere Projektteilnehmer nachvollziehbar und verständlich zu machen. Hierfür kann die Vorlage aus Anhang A Protokollvorlage für Reviewmeeting verwendet werden. Im Gegensatz zum Technischen Review ist eine solche Dokumentation jedoch nicht verpflichtend zu erstellen, daher ist auch die Besetzung dieser Rolle optional. Technischer Gutachter Der technische Gutachter bringt seine fachliche Kompetenz zur Bewertung des Reviewgegenstandes ein und leistet daher einen wesentlichen Beitrag zur Erreichung der Reviewziele. Hierbei ist zu beachten, dass eine Rolle auch von mehreren Personen besetzt werden kann, und eine Person auch mehrere Rollen einnehmen kann. Die Durchführung des Reviews erfordert, dass der Reviewleiter im Zuge der Vorbereitungen alle notwendigen Vorabinformationen an die Teilnehmer versendet (z.b. relevante Standards, Richtlinien, etc.) und den Reviewgegenstand (also z.b. das Dokument, den Quelltext, etc.) entsprechend verfügbar macht. 5.4 Inspektion eines Major-Release-Update Der Bedarf für eine Inspektion der Major-Release-Updates wurde in der Projektplanung nicht separat definiert. Allerdings ergibt sich der Bedarf implizit aus den Anforderungen. Im Projekt sind fünf Major Releases geplant. Jedes Major- Release-Update sollte einer Inspektion unterzogen werden. Dies gilt auch dann, wenn es sich um einen verkürzten Releasezyklus wie im Dokument D08-QM-2 Operative Planung und Durchführung von Reviews und Release-Updates handelt. Inspektionen außerhalb von Major-Release-Updates sind nicht zu empfehlen. Version Juni 2013 Seite 13/43

14 Gemäß des Standards IEEE Std sind folgende Rollen bei Inspektionen von Major-Release-Updates zu definieren: Leiter der Inspektion Der Leiter der Inspektion plant und leitet die Inspektion. Er identifiziert alle wichtigen Dokumente sowie die Module der Software, die für die Inspektion hilfreich sind. In seiner Verantwortung liegen ferner die Planung und Vorbereitung der Inspektionssitzung. Er trägt dazu bei, dass die Ziele der Inspektion erreicht werden. Schließlich trägt er die Verantwortung dafür, dass die Reviewergebnisse an die beteiligten Projektteilnehmer kommuniziert werden. Protokollant Der Protokollant dokumentiert die Durchführung der Inspektion. Damit ist sie für andere Projektteilnehmer nachvollziehbar und verständlich. Für die Inspektion ist eine ausführliche Dokumentation sehr wichtig. Die gefundenen Anomalien und festgelegten Lösungsansätze müssen dokumentiert werden. Dies sichert, dass im Rahmen der eventuell durchzuführenden Prüfung alle Anomalien aus der ursprünglichen Inspektionssitzung beachtet werden. Lektor Die Aufgabe des Lektors ist es, die Teilnehmer der Inspektionssitzung durch die Software zu leiten. Er interpretiert die Arbeitsergebnisse und zeigt wichtige Aspekte für die Inspektion auf. Bei größerer Software ist es sinnvoll, den Arbeitsaufwand auf mehrere Lektoren zu verteilen. Diese bereiten jeweils nur ein oder wenige Module der Software auf. Entwickler Der Entwickler ist für die jeweilige Software oder das zu inspizierende Modul verantwortlich. In seiner Verantwortung liegt, dass die Software den Anforderungen aus dem Dokument D08-QM-2 Operative Planung und Durchführung von Reviews und Release-Updates, um für die Inspektion bereit zu sein. Gegebenenfalls obliegt ihm die Aufgabe, Überarbeitungen, die während der Inspektion festgelegt wurden, durchzuführen. Technischer Gutachter Der technische Gutachter bietet seine Fachkompetenz an, um das Management bei der Bewertung des Gegenstands für die Inspektion zu unterstützen. Die Besetzung einer Rolle kann durch mehrere Personen erfolgen, auch kann eine Person mehrere Rollen zugleich einnehmen. Die Festlegung der Rollenbesetzung obliegt dem Leiter der Inspektion. Des Weiteren liegt es in seiner/ihrer Verantwortung, dass im Zuge der Vorbereitungen alle notwendigen Vorabinformationen an die Teilnehmer versendet (z.b. Kennzahlen, Projektdokumentationen, etc.) und der Gegenstand der Inspektion entsprechend verfügbar gemacht wird. 5.5 Management Review Das Management Review wird von der Projektleitung initiiert und mindestens einmal jährlich durchgeführt. Darüber hinaus können bei Bedarf zu jedem Zeitpunkt im Version Juni 2013 Seite 14/43

15 Entwicklungs-, Test- und Release-Zyklus außerplanmäßige Management Reviews initiiert werden. In jedem Fall ist die Durchführung jedoch identisch. Zunächst gilt es auch hier ein, oder gegebenenfalls mehrere Reviewziele festzulegen. Dies sind beispielsweise: Bewertung des Projektfortschritts Bewertung der Ressourcenplanung Bewertung der Projektziele Zum anderen gilt es die folgenden Rollen zu besetzen (angelehnt an IEEE Std ): Entscheidungsträger Der Entscheidungsträger bewertet, ob die Reviewziele erreicht worden sind. Gegebenenfalls kann diese Rolle vom Reviewleiter, oder von der Projektleitung übernommen werden. Reviewleiter Der Reviewleiter plant und leitet das Reviewmeeting. Er unterstützt die Teilnehmer bei der Erreichung der Reviewziele und trägt die Verantwortung dafür, dass die Reviewergebnisse an die beteiligten Projektteilnehmer kommuniziert werden. Protokollant Der Protokollant dokumentiert die Reviewdurchführung, um sie für andere Projektteilnehmer nachvollziehbar und verständlich zu machen. Hierfür kann die Vorlage aus Anhang A Protokollvorlage für Reviewmeeting verwendet werden. Im Gegensatz zum Informellen Review ist hier eine ausführliche Dokumentation obligatorisch, daher ist die Besetzung dieser Rolle nicht optional. Management Diese Rolle ist beispielsweise durch Projektleiter, Teilprojektleiter und Modulverantwortliche zu besetzen. Sie bringen ihre Fachkompetenz zur Bewertung des Reviewgegenstandes ein und leisten daher einen wesentlichen Beitrag zur Erreichung der Reviewziele. Technischer Gutachter Der technische Gutachter bietet seine Fachkompetenz an, um das Management bei der Bewertung des Reviewgegenstandes zu unterstützen. Die Besetzung einer Rolle kann durch mehrere Personen erfolgen, auch kann eine Person mehrere Rollen zugleich einnehmen. Die Festlegung der Rollenbesetzung obliegt dem Reviewleiter. Des Weiteren liegt es in seiner/ihrer Verantwortung, dass im Zuge der Vorbereitungen alle notwendigen Vorabinformationen an die Teilnehmer versendet (z.b. Kennzahlen, Projektdokumentationen, etc.) und der Reviewgegenstand (also z.b. das Dokument, die Prozessbeschreibung, etc.) entsprechend verfügbar gemacht wird. Handlungsleitend und unterstützend für die Planung und Durchführung eines Management Reviews ist Anhang B Checkliste Management Review. Version Juni 2013 Seite 15/43

16 6 Interne und externe Anforderungen In diesem Kontext betreffen interne Anforderungen insbesondere die Einhaltung zeitlicher Festlegungen. Zum einen gilt es alle Aktivitäten zur Planung und Durchführung von Reviews in Übereinstimmung mit den Festlegungen in diesem Dokument zu erledigen. Zum anderen gilt es die Nachbesserungsarbeiten an Reviewgegenständen zeitnah abzuschließen und die Action Items im Rahmen der zeitlichen Vorgaben abzuarbeiten. Externe Anforderungen ergeben sich durch etwaige Standards, Richtlinien und andere Projektvorgaben, deren Einhaltung verbindlich ist, und somit im Zuge der Reviewdurchführung für eine Bewertung zu berücksichtigen sind. 7 Mitgeltende Dokumente D03-QM Entwurfs- und Entwicklungsprozess von sicheren Open-Source- Softwaremodulen der PersoApp D04-QM Programmierrichtlinien zur Erstellung von - Softwaremodulen D08-QM Review-Konzept D08-QM-3 Prozessbeschreibung zur Durchführung von Code-Reviews und Sicherstellung der Dokumentationsqualität Version Juni 2013 Seite 16/43

17 Anhang A Protokollvorlage für Reviewmeeting Allgemeines Datum und Uhrzeit Ort Teilnehmer Reviewgegenstand Vorabinformationen Ziele Wesentliche Diskussionspunkte Inhalte und Ergebnisse Beschlüsse Action Items Bearbeiter Status (offen, erledigt) Enddatum Gutachter Funde Version Juni 2013 Seite 17/43

18 Anhang B Checkliste Management Review Nummer Prüfpunkt Status 1 Zielfestlegung getroffen 2 Verantwortliche Mitarbeiter festgelegt 3 Terminfestlegung getroffen 4 Einladungen versendet 5 Teilnahmebestätigungen eingeholt 6 Vorabinformationen versendet 7 Reviewgegenstand verfügbar gemacht 8 Reviewmeeting durchgeführt 9 Protokoll erstellt 10 Protokoll den Teilnehmern zur Verfügung gestellt 11 Funde an die Bearbeiter des Reviewgegenstandes kommuniziert 12 Bearbeitung aller Funde und Action Items abgeschlossen Version Juni 2013 Seite 18/43

19 Anhang C Checkliste zur Sicherheitsarchitektur von Softwarereleases Anmerkung: Die nachfolgende Checkliste ist sehr umfangreich. Gegebenenfalls sind einzelne Aktivitäten (temporär) im Kontext des -Projektes nicht anwendbar, In diesem Fall kann die betreffende Aktivität ausgelassen werden. 1 Security-relevant aspects of the software 1.1 Outlining the software to develop Key properties Fill the following table with key information about the software to develop Name Version and Release Application Domain Purpose e.g. CRM with social networking integration e.g. Manage customer information; Enable interaction with customers via popular social networking services; Keep track of interaction history over- Architecture view High-level data flow diagram Add high-level data flow diagrams to this section 1.2 Historical information of security incidents Security incident history If the software has previous versions, describe the security history of the software in the following table. Version Type of Incident Source URL/ID Notes e.g. 0.9 e.g. CWE-ID URL or ID of incident, e.g. CVE-ID If information is available elsewhere, replace table with a reference. Does this incident need to be considered specially or not at all for the software under development. and if so, why? Quick assessment If the software has previous versions, provide details about the software s security history by answering the following questionnaire. Are there unresolved vulnerabilities? Version Juni 2013 Seite 19/43

20 List vulnerabilities, impact, type of weakness and other noteworthy information Regarding the history of security incidents, are there peculiarities, like reoccurring vulnerabilities and types of weaknesses? List noteworthy observations of previous software versions Are the vulnerabilities caused by the software itself or by its integrated and open source components? Describe the source of the vulnerabilities Is the security documentation up-to-date and complete? Analyze the security documentation and describe the state of completeness and actuality Are there any special remarks from previous versions, that need to be investigated, e.g. special handling for an integrated or open source component or special configuration/deployment notes? Analyze previous versions of the threat model and other relevant documentation for special remarks and other hints 1.3 Creating security profiles for software components and other similar software projects For each software component create the following table and answer the questionnaire. ID Name Project URL ID for the component Project name of the component URL of the project s main website Version under investigation Date of investigation Investigated version Add when the investigation has been done Organizational measures: Does the project website contain a security section? Yes/No Add further comments if necessary Is there a list of known vulnerabilities and security advisories on the project website? Yes/No Add further comments if necessary Is there a contact point and process for reporting vulnerabilities? Yes/No Add further comments if necessary Does the project have an actively used bug tracking system? Yes/No Add further comments if necessary Vulnerability handling: Are there vulnerability reports present in public vulnerability databases or in the project bug tracking system? Yes/No Add further comments if necessary Version Juni 2013 Seite 20/43

21 If so, what was the impact of those vulnerabilities, e.g. CVSS score? List and comment the impact of the vulnerabilities (at least for the vulnerabilities for software version under investigation); Use standard metrics, such as CVSS, where available. Else describe impact in own words Are the vulnerabilities caused by the software itself or its components? Comment on the sources of the vulnerabilities; how many from components? How many from the core? Was the impact bigger/smaller/equal for vulnerabilities caused by source vs, components Are there peculiarities, like constantly reoccurring vulnerabilities and types of weaknesses? Describe any observation made during the investigation of the software Quickly evaluate how complicated the vulnerabilities were, e.g. simple errors that could have been prevented by secure coding practices or are they more complex? Evaluate why the vulnerabilities occurred in the first place; Where they caused by simple errors, false assumptions, unconsidered use of components, bad component selection? How is the quality of the vulnerability handling of the project? How long did it take to fix the vulnerability? Are vulnerabilities from public vulnerability databases also present in the projects bug tracking system? Have the fixes been adequately documented in either changelogs or the projects security documentation? Analyze and comment on the vulnerability handling of the software project Quality of code: Is the code well-structured? Yes/No Add further comments if necessary Is the code well-commented? Are all or most classes/files commented or just the core? Are the comments in general easily understandable or is expert knowledge needed? Yes/No Add further comments if necessary Are there many "TODO" or "FIXME" comments? Yes/No Add further comments if necessary, such as number of TODOs, and FIXMEs, number of files the comments occurred,other hints on possible project immaturity or incompleteness Are check-ins to the revision control system of the software well-commented and describe accurately what a check-in was about? Yes/No Add further comments if necessary Deployment: Is the default deployment of the software secure? Are there any default passwords, ports which need to be firewalled, etc.? Yes/No Add further comments if necessary Which user's rights are needed to run the software and is it possible to run the software in restricted (hardened) environments, e.g. chroot or jails in Unix/Linux? Yes/No Add further comments if necessary Version Juni 2013 Seite 21/43

22 Security documentation: Is there security documentation available for the end-user? Yes/No Add further comments if necessary Is the security documentation up-to-date and comprehensive? Yes/No Add further comments if necessary Is the documentation focusing solely on the software or does it, e.g., consider different usage environments of the software? Quickly analyze the security documentation of the software and comment on its completeness regarding usage environments, special configurations, etc Has the product undergone a security assessment and if so, are the results publicly available? Yes/No Add further comments if necessary If the product provides security features, is the security architecture welldocumented? Yes/No Add further comments if necessary If the product provides security features, are those features based on industry best practices and standards, e.g. use of well-known and tested cryptographic algorithms and implementations, support for enforcement of password policies if applicable? Yes/No Add further comments if necessary If a full security assessment of the component is available, replace the questionnaire with a reference to the full assessment. If the architect has doubts in the security level of the component, he should commission a full security assessment for the component to security expert Security profile for similar software projects Identify similar software projects. For each similar software, create the following table and answer the questionnaire. ID ID for the component Name Project name of the component Vendor Vendor name Project URL Add url to projects main site Version under investigation Investigated Version Date of investigation Add when the investigation has been done Are there vulnerability reports present in public vulnerability databases or in the project bug tracking system? Yes/No Add further comments if necessary If so, what was the impact of those vulnerabilities, e.g. CVSS score? List and comment the impact of the vulnerabilities (at least for the vulnerabilities for software version under investigation); Use standard metrics, such as CVSS, where available. Else describe impact in own words Are the vulnerabilities caused by the software itself or its components? Comment on the sources of the vulnerabilities; how many from components? How many from the core? Was the impact bigger/smaller/equal for vulnerabilities caused by source vs, components Version Juni 2013 Seite 22/43

23 Are there peculiarities, like constantly reoccurring vulnerabilities and types of weaknesses? Describe any observation made during the investigation of the software Are there common vulnerabilities to the software project under development? Compare the vulnerabilities of the software under development with those of the software under investigation; Are there similarities? Are there vulnerabilities caused by components that are also used in the software project under development? Analyze whether vulnerable components of the software under investigation are also used in the software under development; If so, are the vulnerabilities relevant for the software under development or is there some sort of mitigation? Are there solutions or mitigations to software and component vulnerabilities that are useful for the software project under development? If the software under investigation has or has had similar security problems as the software under development, analyze the solutioner s from the 3rd party and comment on quality and applicability for the software under development 1.4 Identify asset stakeholders In the following table, describe the asset stakeholder for the software to develop. ID Asset Stakeholder Optional comment or description S1 Add first asset stakeholder Add comment or description, if necessary S2 Add second asset stakeholder Add comment or description, if necessary S3 Add third asset stakeholder Add comment or description, if necessary SN Add further asset stakeholder Add comment or description, if necessary 1.5 Collect relevant assets Collect assets security measures shall protect and identify the related asset stakeholders. ID Asset Asset Stakeholders A1 Add first asset Add reference to stakeholder (e.g., S1 ) A2 Add second asset Add reference to stakeholder (e.g., S1, S2 ) A3 Add third asset Add reference to stakeholder AN Add further assets Add further references to stakeholders 1.6 Specify and rank security objectives for assets Create the following table for each security objective ID Short Name Security Objective O1: Add the considered security objective ( e.g., here Confidentiality of health records ) Version Juni 2013 Seite 23/43

24 Asset A1 Add the affected asset Stakeholder S1 Add the affected asset stakeholder Specification Provide more specific information on the security objective Ranking of security objective (condition under which a violation of the security objective would be considered negligible, marginal, critical, or catastrophic.) Negligible Marginal Critical Catastrophic Describe negligible impact scenarios Describe marginal impact scenarios Describe critical impact scenarios Describe catastrophic impact scenarios 1.7 List actors that interact with the software List all actors that interact with the software in the following table, describe them briefly, list their privileges and explain how an actor can become another actor through which mechanisms. ID Actor Description/Privileges AC1 Anonymous/Public (Note that for security considerations there always exist an anonymous/public actor ) Describe the actor and her privileges ACn Add further actors, each row one actor Describe the further actors and their privileges 1.8 List intended role changes provided to the actors List all possible changes in roles the software allows ID Source Actor Destination Actor Procedure RC1 Anonymous/Public (Note that for security considerations there always exist an anonymous/public actor ) Describe the destination actor the source actor can change to Describe how the procedure provided by the software allowing the change of roles RCn Add further change procedures the software shall provide, each row one pair source actor- destination actor and one procedure Add further destination actors Add further procedures 1.9 Classify processed data Identify and classify data the software will process once it is deployed. Also identify all representations of these data and create an access matrix for each data representation. The matrices should contain all actors that are identified in the previous step and marks indicating granted permissions. You can use the following tables as a starting point: Data class and representation ID: DC1 Add description of the data class and its representation considered in this table Actor Create Read Update Delete Version Juni 2013 Seite 24/43

25 Anonymous/Public Add x if privilege granted Add x if privilege granted Add x if privilege granted Add x if privilege granted Add further actors Add x if privilege granted Add x if privilege granted Add x if privilege granted Add x if privilege granted ID Data type Addressed In-transit In-process DR1 Add data type Describe storage locations Describe transfer channels List modules where this data type is processed 1.10 Identify technologies, platforms, and architectural paradigms List technologies used by the software and explain briefly why they are used. ID Technology Why it is used TE1 Added first technology used by the software Describe briefly why the technology is used TEN Added further technologies used by the software Add further descriptions List platforms supported by the software and explain briefly why these platforms are supported. ID Platform Why it is supported P1 Added first platform supported by the software Describe briefly why the platform is supported PN Added further platforms supported by the software Add further descriptions List architectural paradigms, applied by the software. Explain briefly why particular paradigms have been applied. ID Architectural Paradigm Why it is used AR1 Added first architectural paradigm applied by the software Describe briefly why the paradigm has been applied ARN Added further architectural paradigms applied by the software Add further descriptions 2 Identify and prioritize threats 2.1 Weaknesses identified using CWE Collect the weaknesses identified with the CWE in the following table. Add y for yes, or n for no in the columns Verified?, Applicable?, Requires Actions?, and Mitigated? CWE- ID Add CW-ID, e.g. 259 Name Affected Component/Function Add weakness name, e.g., Use of Hardcoded Password Describe the possibly affected components, e.g,, Default.conf configuration file Affected Security Objectives Reference the affect security objective, e.g., O5 Verified? Applicable? Requires Action? y or n y or n y or n Mitigated? y or n Add further CWE- Add further weaknesses Describe the possibly affected components Reference the affect y or n y or n y or n y or n Version Juni 2013 Seite 25/43

26 IDs security objective 2.2 Threats identified with STRIDE DFD entities In the following table list the entities identified in the data flow diagram. The table contains some example, to show the IDs for different entity types. ID Entity Type Description DF0 Data Flow Entity Name and short description of its function DFN Data Flow Entity Name and short description of its function DS0 Data Storage Entity Name and short description of its function DSN Data Storage Entity Name and short description of its function P0 Process Entity Name and short description of its function PN Process Entity Name and short description of its function EE0 External Entity Entity Name and short description of its function EEN External Entity Entity Name and short description of its function Threats Collect the threats identified with the STRIDE methodology. ID T0 TN Threat Against DFD Entry ID, e.g. DF0 PN Type Description Mitigation Note Either Spoofing, Tampering, Information Disclosure, DoS, or Elevation of Privilege Shortly describe how an exploit might look like and which assets and stakeholders are involved Describe a mitigation if available Comment, if for example, a threat is not relevant or especially relevant 2.3 Attacker-motives assessment Asses for each adversary type the possible benefits of an attack and attack costs. On the basis of this information decide whether the adversary type is relevant for the software at hand. Type of adversary Attack benefits Can an attack on the software serve the adversaries motives? Attack costs How difficulty is an attack? How easy can an attacker get in contact with the system? Are there cheaper ways to achieve the same goal without attacking the software? Adversary class relevant? Decision and rationale Regular users Describe how an attacker from this adversary class could benefit from an attack. Describe the effort required to perform an attack and alternative ways of achieving the same goal. Decide whether attackers of this adversary class are likely to attack the software. Justify the Version Juni 2013 Seite 26/43

Titelbild1 ANSYS. Customer Portal LogIn

Titelbild1 ANSYS. Customer Portal LogIn Titelbild1 ANSYS Customer Portal LogIn 1 Neuanmeldung Neuanmeldung: Bitte Not yet a member anklicken Adressen-Check Adressdaten eintragen Customer No. ist hier bereits erforderlich HERE - Button Hier nochmal

Mehr

D08-QM Review-Konzept PersoApp

D08-QM Review-Konzept PersoApp D08-QM Review-Konzept (Fraunhofer SIT) Prüfung: Sven Wohlgemuth (TU Darmstadt/CASED) Typ: [TECHNISCHER BERICHT] Projekt: Version: 1.0 Datum: 24. Juni 2013 Status: [FREIGABE] Klasse: [ÖFFENTLICHKEIT] Datei:

Mehr

p^db=`oj===pìééçêíáåñçêã~íáçå=

p^db=`oj===pìééçêíáåñçêã~íáçå= p^db=`oj===pìééçêíáåñçêã~íáçå= Error: "Could not connect to the SQL Server Instance" or "Failed to open a connection to the database." When you attempt to launch ACT! by Sage or ACT by Sage Premium for

Mehr

ISO 15504 Reference Model

ISO 15504 Reference Model Process flow Remarks Role Documents, data, tools input, output Start Define purpose and scope Define process overview Define process details Define roles no Define metrics Pre-review Review yes Release

Mehr

p^db=`oj===pìééçêíáåñçêã~íáçå=

p^db=`oj===pìééçêíáåñçêã~íáçå= p^db=`oj===pìééçêíáåñçêã~íáçå= How to Disable User Account Control (UAC) in Windows Vista You are attempting to install or uninstall ACT! when Windows does not allow you access to needed files or folders.

Mehr

HIR Method & Tools for Fit Gap analysis

HIR Method & Tools for Fit Gap analysis HIR Method & Tools for Fit Gap analysis Based on a Powermax APML example 1 Base for all: The Processes HIR-Method for Template Checks, Fit Gap-Analysis, Change-, Quality- & Risk- Management etc. Main processes

Mehr

ISO 15504 Reference Model

ISO 15504 Reference Model Prozess Dimension von SPICE/ISO 15504 Process flow Remarks Role Documents, data, tools input, output Start Define purpose and scope Define process overview Define process details Define roles no Define

Mehr

Exercise (Part II) Anastasia Mochalova, Lehrstuhl für ABWL und Wirtschaftsinformatik, Kath. Universität Eichstätt-Ingolstadt 1

Exercise (Part II) Anastasia Mochalova, Lehrstuhl für ABWL und Wirtschaftsinformatik, Kath. Universität Eichstätt-Ingolstadt 1 Exercise (Part II) Notes: The exercise is based on Microsoft Dynamics CRM Online. For all screenshots: Copyright Microsoft Corporation. The sign ## is you personal number to be used in all exercises. All

Mehr

Darstellung und Anwendung der Assessmentergebnisse

Darstellung und Anwendung der Assessmentergebnisse Process flow Remarks Role Documents, data, tool input, output Important: Involve as many PZU as possible PZO Start Use appropriate templates for the process documentation Define purpose and scope Define

Mehr

KURZANLEITUNG. Firmware-Upgrade: Wie geht das eigentlich?

KURZANLEITUNG. Firmware-Upgrade: Wie geht das eigentlich? KURZANLEITUNG Firmware-Upgrade: Wie geht das eigentlich? Die Firmware ist eine Software, die auf der IP-Kamera installiert ist und alle Funktionen des Gerätes steuert. Nach dem Firmware-Update stehen Ihnen

Mehr

SAP PPM Enhanced Field and Tab Control

SAP PPM Enhanced Field and Tab Control SAP PPM Enhanced Field and Tab Control A PPM Consulting Solution Public Enhanced Field and Tab Control Enhanced Field and Tab Control gives you the opportunity to control your fields of items and decision

Mehr

XML Template Transfer Transfer project templates easily between systems

XML Template Transfer Transfer project templates easily between systems Transfer project templates easily between systems A PLM Consulting Solution Public The consulting solution XML Template Transfer enables you to easily reuse existing project templates in different PPM

Mehr

Mitglied der Leibniz-Gemeinschaft

Mitglied der Leibniz-Gemeinschaft Methods of research into dictionary use: online questionnaires Annette Klosa (Institut für Deutsche Sprache, Mannheim) 5. Arbeitstreffen Netzwerk Internetlexikografie, Leiden, 25./26. März 2013 Content

Mehr

ReadMe zur Installation der BRICKware for Windows, Version 6.1.2. ReadMe on Installing BRICKware for Windows, Version 6.1.2

ReadMe zur Installation der BRICKware for Windows, Version 6.1.2. ReadMe on Installing BRICKware for Windows, Version 6.1.2 ReadMe zur Installation der BRICKware for Windows, Version 6.1.2 Seiten 2-4 ReadMe on Installing BRICKware for Windows, Version 6.1.2 Pages 5/6 BRICKware for Windows ReadMe 1 1 BRICKware for Windows, Version

Mehr

How-To-Do. Communication to Siemens OPC Server via Ethernet

How-To-Do. Communication to Siemens OPC Server via Ethernet How-To-Do Communication to Siemens OPC Server via Content 1 General... 2 1.1 Information... 2 1.2 Reference... 2 2 Configuration of the PC Station... 3 2.1 Create a new Project... 3 2.2 Insert the PC Station...

Mehr

D08-QM-3 Prozessbeschreibung zur Durchführung von Code-Reviews und Sicherstellung der Dokumentationsqualität

D08-QM-3 Prozessbeschreibung zur Durchführung von Code-Reviews und Sicherstellung der Dokumentationsqualität D08-QM-3 Prozessbeschreibung zur Durchführung von Code-Reviews und Sicherstellung der Dokumentationsqualität (Fraunhofer SIT) Prüfung: Sven Wohlgemuth (TU Darmstadt/CASED) Typ: [Technischer Bericht] Projekt:

Mehr

Eclipse User Interface Guidelines

Eclipse User Interface Guidelines SS 2009 Softwarequalität 06.05.2009 C. M. Bopda, S. Vaupel {kaymic/vaupel84}@mathematik.uni-marburg.de Motivation (Problem) Motivation (Problem) Eclipse is a universal tool platform - an open, extensible

Mehr

Cloud Architektur Workshop

Cloud Architektur Workshop Cloud Architektur Workshop Ein Angebot von IBM Software Services for Cloud & Smarter Infrastructure Agenda 1. Überblick Cloud Architektur Workshop 2. In 12 Schritten bis zur Cloud 3. Workshop Vorgehensmodell

Mehr

ELBA2 ILIAS TOOLS AS SINGLE APPLICATIONS

ELBA2 ILIAS TOOLS AS SINGLE APPLICATIONS ELBA2 ILIAS TOOLS AS SINGLE APPLICATIONS An AAA/Switch cooperative project run by LET, ETH Zurich, and ilub, University of Bern Martin Studer, ilub, University of Bern Julia Kehl, LET, ETH Zurich 1 Contents

Mehr

Einsatz einer Dokumentenverwaltungslösung zur Optimierung der unternehmensübergreifenden Kommunikation

Einsatz einer Dokumentenverwaltungslösung zur Optimierung der unternehmensübergreifenden Kommunikation Einsatz einer Dokumentenverwaltungslösung zur Optimierung der unternehmensübergreifenden Kommunikation Eine Betrachtung im Kontext der Ausgliederung von Chrysler Daniel Rheinbay Abstract Betriebliche Informationssysteme

Mehr

Security Patterns. Benny Clauss. Sicherheit in der Softwareentwicklung WS 07/08

Security Patterns. Benny Clauss. Sicherheit in der Softwareentwicklung WS 07/08 Security Patterns Benny Clauss Sicherheit in der Softwareentwicklung WS 07/08 Gliederung Pattern Was ist das? Warum Security Pattern? Security Pattern Aufbau Security Pattern Alternative Beispiel Patternsysteme

Mehr

Softwareschnittstellen

Softwareschnittstellen P4.1. Gliederung Rechnerpraktikum zu Kapitel 4 Softwareschnittstellen Einleitung, Component Object Model (COM) Zugriff auf Microsoft Excel Zugriff auf MATLAB Zugriff auf CATIA Folie 1 P4.2. Einleitung

Mehr

Supplier Questionnaire

Supplier Questionnaire Supplier Questionnaire Dear madam, dear sir, We would like to add your company to our list of suppliers. Our company serves the defence industry and fills orders for replacement parts, including orders

Mehr

Customer-specific software for autonomous driving and driver assistance (ADAS)

Customer-specific software for autonomous driving and driver assistance (ADAS) This press release is approved for publication. Press Release Chemnitz, February 6 th, 2014 Customer-specific software for autonomous driving and driver assistance (ADAS) With the new product line Baselabs

Mehr

Ingenics Project Portal

Ingenics Project Portal Version: 00; Status: E Seite: 1/6 This document is drawn to show the functions of the project portal developed by Ingenics AG. To use the portal enter the following URL in your Browser: https://projectportal.ingenics.de

Mehr

Notice: All mentioned inventors have to sign the Report of Invention (see page 3)!!!

Notice: All mentioned inventors have to sign the Report of Invention (see page 3)!!! REPORT OF INVENTION Please send a copy to An die Abteilung Technologietransfer der Universität/Hochschule An die Technologie-Lizenz-Büro (TLB) der Baden-Württembergischen Hochschulen GmbH Ettlinger Straße

Mehr

Test Plan. Test Plan. Version <1.0> 1.Introduction. 2.Evaluation Mission and Test Motivation

<JASK Gaming> <!Everybodys Perfect> <Iteration/ Master> Test Plan. Test Plan. Version <1.0> 1.Introduction. 2.Evaluation Mission and Test Motivation Test Plan Version Test Plan 1.Introduction 1.1.Purpose The purpose of the Iteration Test Plan is to gather all of the information necessary to plan and control

Mehr

How-To-Do. Hardware Configuration of the CC03 via SIMATIC Manager from Siemens

How-To-Do. Hardware Configuration of the CC03 via SIMATIC Manager from Siemens How-To-Do Hardware Configuration of the CC03 via SIMATIC Manager from Siemens Content Hardware Configuration of the CC03 via SIMATIC Manager from Siemens... 1 1 General... 2 1.1 Information... 2 1.2 Reference...

Mehr

GIPS 2010 Gesamtüberblick. Dr. Stefan J. Illmer Credit Suisse. Seminar der SBVg "GIPS Aperitif" 15. April 2010 Referat von Stefan Illmer

GIPS 2010 Gesamtüberblick. Dr. Stefan J. Illmer Credit Suisse. Seminar der SBVg GIPS Aperitif 15. April 2010 Referat von Stefan Illmer GIPS 2010 Gesamtüberblick Dr. Stefan J. Illmer Credit Suisse Agenda Ein bisschen Historie - GIPS 2010 Fundamentals of Compliance Compliance Statement Seite 3 15.04.2010 Agenda Ein bisschen Historie - GIPS

Mehr

SAP Simple Service Request. Add-on for SAP Solution Manager by SAP Consulting SAP Deutschland SE & Co. KG

SAP Simple Service Request. Add-on for SAP Solution Manager by SAP Consulting SAP Deutschland SE & Co. KG SAP Simple Service Request Add-on for SAP Solution Manager by SAP Consulting SAP Deutschland SE & Co. KG IT Service Management with SAP Solution Manager SAP Solution Manager covers all processes of IT

Mehr

Group and Session Management for Collaborative Applications

Group and Session Management for Collaborative Applications Diss. ETH No. 12075 Group and Session Management for Collaborative Applications A dissertation submitted to the SWISS FEDERAL INSTITUTE OF TECHNOLOGY ZÜRICH for the degree of Doctor of Technical Seiences

Mehr

Advanced Availability Transfer Transfer absences from HR to PPM

Advanced Availability Transfer Transfer absences from HR to PPM Advanced Availability Transfer Transfer absences from HR to PPM A PLM Consulting Solution Public Advanced Availability Transfer With this solution you can include individual absences and attendances from

Mehr

Instruktionen Mozilla Thunderbird Seite 1

Instruktionen Mozilla Thunderbird Seite 1 Instruktionen Mozilla Thunderbird Seite 1 Instruktionen Mozilla Thunderbird Dieses Handbuch wird für Benutzer geschrieben, die bereits ein E-Mail-Konto zusammenbauen lassen im Mozilla Thunderbird und wird

Mehr

Exercise (Part VIII) Anastasia Mochalova, Lehrstuhl für ABWL und Wirtschaftsinformatik, Kath. Universität Eichstätt-Ingolstadt 1

Exercise (Part VIII) Anastasia Mochalova, Lehrstuhl für ABWL und Wirtschaftsinformatik, Kath. Universität Eichstätt-Ingolstadt 1 Exercise (Part VIII) Notes: The exercise is based on Microsoft Dynamics CRM Online. For all screenshots: Copyright Microsoft Corporation. The sign ## is you personal number to be used in all exercises.

Mehr

NEWSLETTER. FileDirector Version 2.5 Novelties. Filing system designer. Filing system in WinClient

NEWSLETTER. FileDirector Version 2.5 Novelties. Filing system designer. Filing system in WinClient Filing system designer FileDirector Version 2.5 Novelties FileDirector offers an easy way to design the filing system in WinClient. The filing system provides an Explorer-like structure in WinClient. The

Mehr

EEX Kundeninformation 2007-09-05

EEX Kundeninformation 2007-09-05 EEX Eurex Release 10.0: Dokumentation Windows Server 2003 auf Workstations; Windows Server 2003 Service Pack 2: Information bezüglich Support Sehr geehrte Handelsteilnehmer, Im Rahmen von Eurex Release

Mehr

Total Security Intelligence. Die nächste Generation von Log Management and SIEM. Markus Auer Sales Director Q1 Labs.

Total Security Intelligence. Die nächste Generation von Log Management and SIEM. Markus Auer Sales Director Q1 Labs. Total Security Intelligence Die nächste Generation von Log Management and SIEM Markus Auer Sales Director Q1 Labs IBM Deutschland 1 2012 IBM Corporation Gezielte Angriffe auf Unternehmen und Regierungen

Mehr

Wählen Sie das MySQL Symbol und erstellen Sie eine Datenbank und einen dazugehörigen User.

Wählen Sie das MySQL Symbol und erstellen Sie eine Datenbank und einen dazugehörigen User. 1 English Description on Page 5! German: Viele Dank für den Kauf dieses Produktes. Im nachfolgenden wird ausführlich die Einrichtung des Produktes beschrieben. Für weitere Fragen bitte IM an Hotmausi Congrejo.

Mehr

Bayerisches Landesamt für Statistik und Datenverarbeitung Rechenzentrum Süd. z/os Requirements 95. z/os Guide in Lahnstein 13.

Bayerisches Landesamt für Statistik und Datenverarbeitung Rechenzentrum Süd. z/os Requirements 95. z/os Guide in Lahnstein 13. z/os Requirements 95. z/os Guide in Lahnstein 13. März 2009 0 1) LOGROTATE in z/os USS 2) KERBEROS (KRB5) in DFS/SMB 3) GSE Requirements System 1 Requirement Details Description Benefit Time Limit Impact

Mehr

Software development with continuous integration

Software development with continuous integration Software development with continuous integration (FESG/MPIfR) ettl@fs.wettzell.de (FESG) neidhardt@fs.wettzell.de 1 A critical view on scientific software Tendency to become complex and unstructured Highly

Mehr

Praktikum Entwicklung Mediensysteme (für Master)

Praktikum Entwicklung Mediensysteme (für Master) Praktikum Entwicklung Mediensysteme (für Master) Organisatorisches Today Schedule Organizational Stuff Introduction to Android Exercise 1 2 Schedule Phase 1 Individual Phase: Introduction to basics about

Mehr

Invitation - Benutzerhandbuch. User Manual. User Manual. I. Deutsch 2. 1. Produktübersicht 2. 1.1. Beschreibung... 2

Invitation - Benutzerhandbuch. User Manual. User Manual. I. Deutsch 2. 1. Produktübersicht 2. 1.1. Beschreibung... 2 Invitation - Inhaltsverzeichnis I. Deutsch 2 1. Produktübersicht 2 1.1. Beschreibung......................................... 2 2. Installation und Konfiguration 2 2.1. Installation...........................................

Mehr

Phasen. Gliederung. Rational Unified Process

Phasen. Gliederung. Rational Unified Process Rational Unified Process Version 4.0 Version 4.1 Version 5.1 Version 5.5 Version 2000 Version 2001 1996 1997 1998 1999 2000 2001 Rational Approach Objectory Process OMT Booch SQA Test Process Requirements

Mehr

Symbio system requirements. Version 5.1

Symbio system requirements. Version 5.1 Symbio system requirements Version 5.1 From: January 2016 2016 Ploetz + Zeller GmbH Symbio system requirements 2 Content 1 Symbio Web... 3 1.1 Overview... 3 1.1.1 Single server installation... 3 1.1.2

Mehr

Praktikum Entwicklung von Mediensystemen mit ios

Praktikum Entwicklung von Mediensystemen mit ios Praktikum Entwicklung von Mediensystemen mit ios WS 2011 Prof. Dr. Michael Rohs michael.rohs@ifi.lmu.de MHCI Lab, LMU München Today Heuristische Evaluation vorstellen Aktuellen Stand Software Prototyp

Mehr

Exercise (Part XI) Anastasia Mochalova, Lehrstuhl für ABWL und Wirtschaftsinformatik, Kath. Universität Eichstätt-Ingolstadt 1

Exercise (Part XI) Anastasia Mochalova, Lehrstuhl für ABWL und Wirtschaftsinformatik, Kath. Universität Eichstätt-Ingolstadt 1 Exercise (Part XI) Notes: The exercise is based on Microsoft Dynamics CRM Online. For all screenshots: Copyright Microsoft Corporation. The sign ## is you personal number to be used in all exercises. All

Mehr

3A03 Security Löcher schnell und effizient schließen mit HP OpenView Radia

3A03 Security Löcher schnell und effizient schließen mit HP OpenView Radia 3A03 Security Löcher schnell und effizient schließen mit HP OpenView Radia Alexander Meisel HP OpenView 2004 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change

Mehr

IDS Lizenzierung für IDS und HDR. Primärserver IDS Lizenz HDR Lizenz

IDS Lizenzierung für IDS und HDR. Primärserver IDS Lizenz HDR Lizenz IDS Lizenzierung für IDS und HDR Primärserver IDS Lizenz HDR Lizenz Workgroup V7.3x oder V9.x Required Not Available Primärserver Express V10.0 Workgroup V10.0 Enterprise V7.3x, V9.x or V10.0 IDS Lizenz

Mehr

OEDIV SSL-VPN Portal Access for externals

OEDIV SSL-VPN Portal Access for externals OEDIV SSL-VPN Portal Access for externals Abteilung Serverbetreuung Andre Landwehr Date 31.07.2013 Version 1.2 Seite 1 von 9 Versionshistorie Version Datum Autor Bemerkung 1.0 06.08.2011 A. Landwehr Initial

Mehr

Infrastructure as a Service (IaaS) Solutions for Online Game Service Provision

Infrastructure as a Service (IaaS) Solutions for Online Game Service Provision Infrastructure as a Service (IaaS) Solutions for Online Game Service Provision Zielsetzung: System Verwendung von Cloud-Systemen für das Hosting von online Spielen (IaaS) Reservieren/Buchen von Resources

Mehr

Gliederung. Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung

Gliederung. Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung Peter Forbrig RUP 1 Gliederung Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung Peter Forbrig RUP 2 Rational Unified

Mehr

Anforderungen, KEFs und Nutzen der Software- Prozessverbesserung

Anforderungen, KEFs und Nutzen der Software- Prozessverbesserung Process flow Remarks Role Documents, data, tool input, output Important: Involve as many PZU as possible PZO Start Use appropriate templates for the process documentation Define purpose and scope Define

Mehr

WP2. Communication and Dissemination. Wirtschafts- und Wissenschaftsförderung im Freistaat Thüringen

WP2. Communication and Dissemination. Wirtschafts- und Wissenschaftsförderung im Freistaat Thüringen WP2 Communication and Dissemination Europa Programm Center Im Freistaat Thüringen In Trägerschaft des TIAW e. V. 1 GOALS for WP2: Knowledge information about CHAMPIONS and its content Direct communication

Mehr

Isabel Arnold CICS Technical Sales Germany Isabel.arnold@de.ibm.com. z/os Explorer. 2014 IBM Corporation

Isabel Arnold CICS Technical Sales Germany Isabel.arnold@de.ibm.com. z/os Explorer. 2014 IBM Corporation Isabel Arnold CICS Technical Sales Germany Isabel.arnold@de.ibm.com z/os Explorer Agenda Introduction and Background Why do you want z/os Explorer? What does z/os Explorer do? z/os Resource Management

Mehr

Stefan Mieth, AIT GmbH & Co. KG

Stefan Mieth, AIT GmbH & Co. KG Stefan Mieth, AIT GmbH & Co KG As a requirements engineer I want to use the TFS 12032015; 16:30 17:30 Requirements Engineering ist neben Testing wohl der Dauerbrenner, wenn es um gerne vernachlässigte

Mehr

NVR Mobile Viewer for iphone/ipad/ipod Touch

NVR Mobile Viewer for iphone/ipad/ipod Touch NVR Mobile Viewer for iphone/ipad/ipod Touch Quick Installation Guide DN-16111 DN-16112 DN16113 2 DN-16111, DN-16112, DN-16113 for Mobile ios Quick Guide Table of Contents Download and Install the App...

Mehr

IBM Security Lab Services für QRadar

IBM Security Lab Services für QRadar IBM Security Lab Services für QRadar Serviceangebote für ein QRadar SIEM Deployment in 10 bzw. 15 Tagen 28.01.2015 12015 IBM Corporation Agenda 1 Inhalt der angebotenen Leistungen Allgemeines Erbrachte

Mehr

Support Technologies based on Bi-Modal Network Analysis. H. Ulrich Hoppe. Virtuelles Arbeiten und Lernen in projektartigen Netzwerken

Support Technologies based on Bi-Modal Network Analysis. H. Ulrich Hoppe. Virtuelles Arbeiten und Lernen in projektartigen Netzwerken Support Technologies based on Bi-Modal Network Analysis H. Agenda 1. Network analysis short introduction 2. Supporting the development of virtual organizations 3. Supporting the development of compentences

Mehr

Markus BöhmB Account Technology Architect Microsoft Schweiz GmbH

Markus BöhmB Account Technology Architect Microsoft Schweiz GmbH Markus BöhmB Account Technology Architect Microsoft Schweiz GmbH What is a GEVER??? Office Strategy OXBA How we used SharePoint Geschäft Verwaltung Case Management Manage Dossiers Create and Manage Activities

Mehr

Transparenz 2.0. Passive Nachverfolgung und Filterung von WebApps auf dem Prüfstand

Transparenz 2.0. Passive Nachverfolgung und Filterung von WebApps auf dem Prüfstand Matthias Seul IBM Research & Development GmbH BSI-Sicherheitskongress 2013 Transparenz 2.0 Passive Nachverfolgung und Filterung von WebApps auf dem Prüfstand R1 Rechtliche Hinweise IBM Corporation 2013.

Mehr

D01-QM Organisation und Rollenverteilung

D01-QM Organisation und Rollenverteilung D01-QM Organisation und Rollenverteilung (TU Darmstadt/CASED) Prüfung: André Gutwirth (AGETO) und Siniša Dukanovic (Fraunhofer SIT) Typ: [MANAGEMENTBERICHT] Projekt: Version: 1.0 Datum: 12. Juni 2013 Status:

Mehr

Addressing the Location in Spontaneous Networks

Addressing the Location in Spontaneous Networks Addressing the Location in Spontaneous Networks Enabling BOTH: Privacy and E-Commerce Design by Moritz Strasser 1 Disappearing computers Trends Mobility and Spontaneous Networks (MANET = Mobile Ad hoc

Mehr

SELF-STUDY DIARY (or Lerntagebuch) GER102

SELF-STUDY DIARY (or Lerntagebuch) GER102 SELF-STUDY DIARY (or Lerntagebuch) GER102 This diary has several aims: To show evidence of your independent work by using an electronic Portfolio (i.e. the Mahara e-portfolio) To motivate you to work regularly

Mehr

Efficient Design Space Exploration for Embedded Systems

Efficient Design Space Exploration for Embedded Systems Diss. ETH No. 16589 Efficient Design Space Exploration for Embedded Systems A dissertation submitted to the SWISS FEDERAL INSTITUTE OF TECHNOLOGY ZURICH for the degree of Doctor of Sciences presented by

Mehr

H Mcast Future Internet made in Hamburg?

H Mcast Future Internet made in Hamburg? H Mcast Future Internet made in Hamburg? Thomas Schmidt (HAW Hamburg) schmidt@informatik.haw-hamburg.de Forschungsschwerpunkt: IMS Interagierende Multimediale Systeme 1 Prof. Dr. Thomas Schmidt http://www.haw-hamburg.de/inet

Mehr

How to develop and improve the functioning of the audit committee The Auditor s View

How to develop and improve the functioning of the audit committee The Auditor s View How to develop and improve the functioning of the audit committee The Auditor s View May 22, 2013 Helmut Kerschbaumer KPMG Austria Audit Committees in Austria Introduced in 2008, applied since 2009 Audit

Mehr

Änderungen ISO 27001: 2013

Änderungen ISO 27001: 2013 Änderungen ISO 27001: 2013 Loomans & Matz AG August-Horch-Str. 6a, 55129 Mainz Deutschland Tel. +496131-3277 877; www.loomans-matz.de, info@loomans-matz.de Die neue Version ist seit Oktober 2013 verfügbar

Mehr

Leadership in komplexen Projekten. SAP PM-Network, 7. Mai 2014 Armin Singler, SAP (Schweiz) AG

Leadership in komplexen Projekten. SAP PM-Network, 7. Mai 2014 Armin Singler, SAP (Schweiz) AG Leadership in komplexen Projekten SAP PM-Network, 7. Mai 2014 Armin Singler, SAP (Schweiz) AG Kurzvorstellung Armin Singler Principal Project Manager Profil: Armin Singler arbeitet seit 16 Jahren im SAP-Umfeld.

Mehr

RailMaster New Version 7.00.p26.01 / 01.08.2014

RailMaster New Version 7.00.p26.01 / 01.08.2014 RailMaster New Version 7.00.p26.01 / 01.08.2014 English Version Bahnbuchungen so einfach und effizient wie noch nie! Copyright Copyright 2014 Travelport und/oder Tochtergesellschaften. Alle Rechte vorbehalten.

Mehr

Mit Legacy-Systemen in die Zukunft. adviion. in die Zukunft. Dr. Roland Schätzle

Mit Legacy-Systemen in die Zukunft. adviion. in die Zukunft. Dr. Roland Schätzle Mit Legacy-Systemen in die Zukunft Dr. Roland Schätzle Der Weg zur Entscheidung 2 Situation Geschäftliche und softwaretechnische Qualität der aktuellen Lösung? Lohnen sich weitere Investitionen? Migration??

Mehr

CeBIT 17.03.2015. CARMAO GmbH 2014 1

CeBIT 17.03.2015. CARMAO GmbH 2014 1 CeBIT 17.03.2015 CARMAO GmbH 2014 1 HERZLICH WILLKOMMEN Applikationssicherheit beginnt lange bevor auch nur eine Zeile Code geschrieben wurde Ulrich Heun Geschäftsführender Gesellschafter der CARMAO GmbH

Mehr

Administering Microsoft Exchange Server 2016 MOC 20345-1

Administering Microsoft Exchange Server 2016 MOC 20345-1 Administering Microsoft Exchange Server 2016 MOC 20345-1 In diesem 5-tägigen Kurs lernen Sie, wie Sie Exchange Server 2012 administrieren und supporten. Sie erfahren, wie Sie den Exchange Server 2016 installieren

Mehr

Rollen im Participant Portal

Rollen im Participant Portal Rollen im Participant Portal Stand Februar 2011 Inhaltsverzeichnis 1 Welche Aufteilung existiert grundsätzlich im PP?...3 1.1 Organisation Roles:...3 1.2 Project Roles:...4 1.2.1 1st level: Coordinator

Mehr

1. General information... 2 2. Login... 2 3. Home... 3 4. Current applications... 3

1. General information... 2 2. Login... 2 3. Home... 3 4. Current applications... 3 User Manual for Marketing Authorisation and Lifecycle Management of Medicines Inhalt: User Manual for Marketing Authorisation and Lifecycle Management of Medicines... 1 1. General information... 2 2. Login...

Mehr

eurex rundschreiben 094/10

eurex rundschreiben 094/10 eurex rundschreiben 094/10 Datum: Frankfurt, 21. Mai 2010 Empfänger: Alle Handelsteilnehmer der Eurex Deutschland und Eurex Zürich sowie Vendoren Autorisiert von: Jürg Spillmann Weitere Informationen zur

Mehr

How to access licensed products from providers who are already operating productively in. General Information... 2. Shibboleth login...

How to access licensed products from providers who are already operating productively in. General Information... 2. Shibboleth login... Shibboleth Tutorial How to access licensed products from providers who are already operating productively in the SWITCHaai federation. General Information... 2 Shibboleth login... 2 Separate registration

Mehr

German English Firmware translation for T-Sinus 154 Access Point

German English Firmware translation for T-Sinus 154 Access Point German English Firmware translation for T-Sinus 154 Access Point Konfigurationsprogramm Configuration program (english translation italic type) Dieses Programm ermöglicht Ihnen Einstellungen in Ihrem Wireless

Mehr

Employment and Salary Verification in the Internet (PA-PA-US)

Employment and Salary Verification in the Internet (PA-PA-US) Employment and Salary Verification in the Internet (PA-PA-US) HELP.PYUS Release 4.6C Employment and Salary Verification in the Internet (PA-PA-US SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten.

Mehr

TPI NEXT applied for medical. AQSF Fachgruppe Medizintechnik

TPI NEXT applied for medical. AQSF Fachgruppe Medizintechnik TPI NEXT applied for medical AQSF Fachgruppe Medizintechnik About b-quality 2 Ziele und Anforderungen von Testprozessen Testprozesse (sollen) - Fehler finden - Schwachstellen aufdecken Anforderungen an

Mehr

Sicherheit / Sicherung - unterschiedliche Begriffsbestimmung, gemeinsame Fachaspekte

Sicherheit / Sicherung - unterschiedliche Begriffsbestimmung, gemeinsame Fachaspekte Sicherheit / Sicherung - unterschiedliche Begriffsbestimmung, gemeinsame Fachaspekte F. Seidel, BfS Salzgitter (Juli 2002) 1) Begriffsbestimmung (Vergleich unter Nutzung nationaler und internationaler

Mehr

ITILin60Minuten. Jörn Clausen joernc@gmail.com. Captain Barbossa: And thirdly, the code is more what you d call guidelines than actual rules.

ITILin60Minuten. Jörn Clausen joernc@gmail.com. Captain Barbossa: And thirdly, the code is more what you d call guidelines than actual rules. ITILin60Minuten Jörn Clausen joernc@gmail.com Captain Barbossa: And thirdly, the code is more what you d call guidelines than actual rules. Elizabeth Swann: Hang the code, and hang the rules. They re more

Mehr

Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering,

Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering, Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering, Manfred Broy Lehrstuhl für Software & Systems Engineering Technische Universität München Institut für Informatik ISO 26262 Functional

Mehr

The process runs automatically and the user is guided through it. Data acquisition and the evaluation are done automatically.

The process runs automatically and the user is guided through it. Data acquisition and the evaluation are done automatically. Q-App: UserCal Advanced Benutzerdefinierte Kalibrierroutine mit Auswertung über HTML (Q-Web) User defined calibration routine with evaluation over HTML (Q-Web) Beschreibung Der Workflow hat 2 Ebenen eine

Mehr

Klausur Verteilte Systeme

Klausur Verteilte Systeme Klausur Verteilte Systeme SS 2005 by Prof. Walter Kriha Klausur Verteilte Systeme: SS 2005 by Prof. Walter Kriha Note Bitte ausfüllen (Fill in please): Vorname: Nachname: Matrikelnummer: Studiengang: Table

Mehr

HP Service Manager 7 mit ITSM Implementation Accelerator (IIA) ITIL V3 out of the box?

HP Service Manager 7 mit ITSM Implementation Accelerator (IIA) ITIL V3 out of the box? HP Service Manager 7 mit ITSM Implementation Accelerator (IIA) ITIL V3 out of the box? 04. November 2008 ITC GmbH 2008 Agenda Was bringt der HP Service Manager 7? Überblick SM7 Module Neue / zusätzliche

Mehr

EEX Kundeninformation 2002-09-11

EEX Kundeninformation 2002-09-11 EEX Kundeninformation 2002-09-11 Terminmarkt Bereitstellung eines Simulations-Hotfixes für Eurex Release 6.0 Aufgrund eines Fehlers in den Release 6.0 Simulations-Kits lässt sich die neue Broadcast-Split-

Mehr

Microsoft Azure Fundamentals MOC 10979

Microsoft Azure Fundamentals MOC 10979 Microsoft Azure Fundamentals MOC 10979 In dem Kurs Microsoft Azure Fundamentals (MOC 10979) erhalten Sie praktische Anleitungen und Praxiserfahrung in der Implementierung von Microsoft Azure. Ihnen werden

Mehr

Challenges for the future between extern and intern evaluation

Challenges for the future between extern and intern evaluation Evaluation of schools in switzerland Challenges for the future between extern and intern evaluation Michael Frais Schulentwicklung in the Kanton Zürich between internal evaluation and external evaluation

Mehr

EXPERT SURVEY OF THE NEWS MEDIA

EXPERT SURVEY OF THE NEWS MEDIA EXPERT SURVEY OF THE NEWS MEDIA THE SHORENSTEIN CENTER ON THE PRESS, POLITICS & PUBLIC POLICY JOHN F. KENNEDY SCHOOL OF GOVERNMENT, HARVARD UNIVERSITY, CAMBRIDGE, MA 0238 PIPPA_NORRIS@HARVARD.EDU. FAX:

Mehr

Cameraserver mini. commissioning. Ihre Vision ist unsere Aufgabe

Cameraserver mini. commissioning. Ihre Vision ist unsere Aufgabe Cameraserver mini commissioning Page 1 Cameraserver - commissioning Contents 1. Plug IN... 3 2. Turn ON... 3 3. Network configuration... 4 4. Client-Installation... 6 4.1 Desktop Client... 6 4.2 Silverlight

Mehr

GURUCAD - IT DIVISION CATIA V5 PLM EXPRESS CONFIGURATIONS Hamburg, 16th February 2010, Version 1.0

GURUCAD - IT DIVISION CATIA V5 PLM EXPRESS CONFIGURATIONS Hamburg, 16th February 2010, Version 1.0 Engineering & IT Consulting GURUCAD - IT DIVISION CATIA V5 PLM EXPRESS CONFIGURATIONS Hamburg, 16th February 2010, Version 1.0 IT DIVISION CATIA V5 DEPARTMENT Mobile: +49(0)176 68 33 66 48 Tel.: +49(0)40

Mehr

Mash-Up Personal Learning Environments. Dr. Hendrik Drachsler

Mash-Up Personal Learning Environments. Dr. Hendrik Drachsler Decision Support for Learners in Mash-Up Personal Learning Environments Dr. Hendrik Drachsler Personal Nowadays Environments Blog Reader More Information Providers Social Bookmarking Various Communities

Mehr

How-To-Do. Hardware Configuration of the CPU 317NET with external CPs on the SPEED Bus by SIMATIC Manager from Siemens

How-To-Do. Hardware Configuration of the CPU 317NET with external CPs on the SPEED Bus by SIMATIC Manager from Siemens How-To-Do Hardware Configuration of the CPU 317NET with external CPs on the SPEED Bus by SIMATIC Manager from Siemens Content Hardware Configuration of the CPU 317NET with external CPs on the SPEED Bus

Mehr

Prozesse als strategischer Treiber einer SOA - Ein Bericht aus der Praxis

Prozesse als strategischer Treiber einer SOA - Ein Bericht aus der Praxis E-Gov Fokus Geschäftsprozesse und SOA 31. August 2007 Prozesse als strategischer Treiber einer SOA - Ein Bericht aus der Praxis Der Vortrag zeigt anhand von Fallbeispielen auf, wie sich SOA durch die Kombination

Mehr

Product Lifecycle Manager

Product Lifecycle Manager Product Lifecycle Manager ATLAS9000 GmbH Landauer Str. - 1 D-68766 Hockenheim +49(0)6205 / 202730 Product Lifecycle Management ATLAS PLM is powerful, economical and based on standard technologies. Directory

Mehr

www.pwc.com FATCA implementieren in der Schweiz vom Projekt bis zum operativen Prozess SVV Präsentation 4. April 2013

www.pwc.com FATCA implementieren in der Schweiz vom Projekt bis zum operativen Prozess SVV Präsentation 4. April 2013 www.pwc.com FATCA implementieren in der Schweiz vom Projekt bis zum operativen Prozess Präsentation 4. Agenda 1. Einführung 2. FATCA-Hauptaufgaben 3. Versicherer in der Schweiz und FATCA 4. Implementierungsaspekte

Mehr

Level 1 German, 2015

Level 1 German, 2015 90886 908860 1SUPERVISOR S Level 1 German, 2015 90886 Demonstrate understanding of a variety of German texts on areas of most immediate relevance 2.00 p.m. Thursday 26 November 2015 Credits: Five Achievement

Mehr

J RG IMMENDORFF STANDORT F R KRITIK MALEREI UND INSPIRATION ERSCHEINT ZUR AUSSTELLUNG IM MUSEUM LU

J RG IMMENDORFF STANDORT F R KRITIK MALEREI UND INSPIRATION ERSCHEINT ZUR AUSSTELLUNG IM MUSEUM LU J RG IMMENDORFF STANDORT F R KRITIK MALEREI UND INSPIRATION ERSCHEINT ZUR AUSSTELLUNG IM MUSEUM LU 8 Feb, 2016 JRISFRKMUIEZAIMLAPOM-PDF33-0 File 4,455 KB 96 Page If you want to possess a one-stop search

Mehr

Der Adapter Z250I / Z270I lässt sich auf folgenden Betriebssystemen installieren:

Der Adapter Z250I / Z270I lässt sich auf folgenden Betriebssystemen installieren: Installationshinweise Z250I / Z270I Adapter IR USB Installation hints Z250I / Z270I Adapter IR USB 06/07 (Laden Sie den Treiber vom WEB, entpacken Sie ihn in ein leeres Verzeichnis und geben Sie dieses

Mehr

ColdFusion 8 PDF-Integration

ColdFusion 8 PDF-Integration ColdFusion 8 PDF-Integration Sven Ramuschkat SRamuschkat@herrlich-ramuschkat.de München & Zürich, März 2009 PDF Funktionalitäten 1. Auslesen und Befüllen von PDF-Formularen 2. Umwandlung von HTML-Seiten

Mehr