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 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Security Planning Basics

Security Planning Basics Einführung in die Wirtschaftsinformatik VO WS 2009/2010 Security Planning Basics Gerald.Quirchmayr@univie.ac.at Textbook used as basis for these slides and recommended as reading: Whitman, M. E. & Mattord,

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

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

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

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

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

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

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

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

Capturing and Documentation of Decisions in Security Requirements Engineering through Heuristics

Capturing and Documentation of Decisions in Security Requirements Engineering through Heuristics Capturing and Documentation of Decisions in Security Requirements Engineering through Heuristics Stefan Gärtner, Tom-Michael Hesse, Kurt Schneider, Barbara Paech Fachgruppentreffen Requirements Engineering

Mehr

Frequently asked Questions for Kaercher Citrix (apps.kaercher.com)

Frequently asked Questions for Kaercher Citrix (apps.kaercher.com) Frequently asked Questions for Kaercher Citrix (apps.kaercher.com) Inhalt Content Citrix-Anmeldung Login to Citrix Was bedeutet PIN und Token (bei Anmeldungen aus dem Internet)? What does PIN and Token

Mehr

A central repository for gridded data in the MeteoSwiss Data Warehouse

A central repository for gridded data in the MeteoSwiss Data Warehouse A central repository for gridded data in the MeteoSwiss Data Warehouse, Zürich M2: Data Rescue management, quality and homogenization September 16th, 2010 Data Coordination, MeteoSwiss 1 Agenda Short introduction

Mehr

Sprint 1 -> 2 Bridge (20150108)

Sprint 1 -> 2 Bridge (20150108) Sprint 1 WK49-WK50 Prerequisites: MDM4 API documentation MDM4 business object model Eclipse tooling definitions (maven as build) Common Goals: Define MDM API as a valid component and its position MDM API

Mehr

In vier Schritten zum Titel. erfolgreichen Messeauftritt. Four steps to a successful trade fair. Hier beginnt Zukunft! The future starts here!

In vier Schritten zum Titel. erfolgreichen Messeauftritt. Four steps to a successful trade fair. Hier beginnt Zukunft! The future starts here! In vier Schritten zum Titel erfolgreichen Messeauftritt. Four steps to a successful trade fair. Hier beginnt Zukunft! The future starts here! Einleitung Intro Um Sie dabei zu unterstützen, Ihren Messeauftritt

Mehr

FAQ - Häufig gestellte Fragen zur PC Software iks AQUASSOFT FAQ Frequently asked questions regarding the software iks AQUASSOFT

FAQ - Häufig gestellte Fragen zur PC Software iks AQUASSOFT FAQ Frequently asked questions regarding the software iks AQUASSOFT FAQ - Häufig gestellte Fragen zur PC Software iks AQUASSOFT FAQ Frequently asked questions regarding the software iks AQUASSOFT Mit welchen Versionen des iks Computers funktioniert AQUASSOFT? An Hand der

Mehr

CHAMPIONS Communication and Dissemination

CHAMPIONS Communication and Dissemination CHAMPIONS Communication and Dissemination Europa Programm Center Im Freistaat Thüringen In Trägerschaft des TIAW e. V. 1 CENTRAL EUROPE PROGRAMME CENTRAL EUROPE PROGRAMME -ist als größtes Aufbauprogramm

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

Software Engineering und Projektmanagement 2.0 VO

Software Engineering und Projektmanagement 2.0 VO Software Engineering und Projektmanagement 2.0 VO Inhalte der Einheit Was ist Usability? Wieso ist Usability wichtig? Vorlesung 2009W Usability Engineering (Christoph Wimmer) Sicherheit in der Softwareentwicklung

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

MSDN Webcast: Team Foundation Server Mehr als nur eine Versionsverwaltung! Visual Studio Team System (Teil 1 von 10) Veröffentlicht: 20.

MSDN Webcast: Team Foundation Server Mehr als nur eine Versionsverwaltung! Visual Studio Team System (Teil 1 von 10) Veröffentlicht: 20. MSDN Webcast: Team Foundation Server Mehr als nur eine Versionsverwaltung! Visual Studio Team System (Teil 1 von 10) Veröffentlicht: 20. Februar 2008 Presenter: Neno Loje, MVP für Team System www.teamsystempro.de

Mehr

Challenges in Systems Engineering and a Pragmatic Solution Approach

Challenges in Systems Engineering and a Pragmatic Solution Approach Pure Passion. Systems Engineering and a Pragmatic Solution Approach HELVETING Dr. Thomas Stöckli Director Business Unit Systems Engineering Dr. Daniel Hösli Member of the Executive Board 1 Agenda Different

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

Sicherheit dank Durchblick. Thomas Fleischmann Sales Engineer, Central Europe

Sicherheit dank Durchblick. Thomas Fleischmann Sales Engineer, Central Europe Sicherheit dank Durchblick Thomas Fleischmann Sales Engineer, Central Europe Threat Landscape Immer wieder neue Schlagzeilen Cybercrime ist profitabel Wachsende Branche 2013: 9 Zero Day Vulnerabilities

Mehr

Mobile Time Recording SAP PPM HTML5 App

Mobile Time Recording SAP PPM HTML5 App Mobile Time Recording SAP PPM HTML5 App A PLM Consulting Solution Public The SAP PPM Mobile Time Recording App offers a straight forward way to record times for PPM projects. Project members can easily

Mehr

Labour law and Consumer protection principles usage in non-state pension system

Labour law and Consumer protection principles usage in non-state pension system Labour law and Consumer protection principles usage in non-state pension system by Prof. Dr. Heinz-Dietrich Steinmeyer General Remarks In private non state pensions systems usually three actors Employer

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

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

Cloud for Customer Learning Resources. Customer

Cloud for Customer Learning Resources. Customer Cloud for Customer Learning Resources Customer Business Center Logon to Business Center for Cloud Solutions from SAP & choose Cloud for Customer https://www.sme.sap.com/irj/sme/ 2013 SAP AG or an SAP affiliate

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

Neuerungen und Anpassungen rund um ISO/IEC 27001:2013

Neuerungen und Anpassungen rund um ISO/IEC 27001:2013 Neuerungen und Anpassungen rund um ISO/IEC 27001:2013 Erfahrungsbericht eines Auditors Uwe Rühl 1 Uwe Rühl Kurz zu meiner Person Externer Client Manager (Lead Auditor) für ISO/IEC 27001, ISO 22301 und

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

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

Disclaimer & Legal Notice. Haftungsausschluss & Impressum

Disclaimer & Legal Notice. Haftungsausschluss & Impressum Disclaimer & Legal Notice Haftungsausschluss & Impressum 1. Disclaimer Limitation of liability for internal content The content of our website has been compiled with meticulous care and to the best of

Mehr

Projektrisikomanagement im Corporate Risk Management

Projektrisikomanagement im Corporate Risk Management VERTRAULICH Projektrisikomanagement im Corporate Risk Management Stefan Friesenecker 24. März 2009 Inhaltsverzeichnis Risikokategorien Projekt-Klassifizierung Gestaltungsdimensionen des Projektrisikomanagementes

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

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

Algorithms for graph visualization

Algorithms for graph visualization Algorithms for graph visualization Project - Orthogonal Grid Layout with Small Area W INTER SEMESTER 2013/2014 Martin No llenburg KIT Universita t des Landes Baden-Wu rttemberg und nationales Forschungszentrum

Mehr

XV1100K(C)/XV1100SK(C)

XV1100K(C)/XV1100SK(C) Lexware Financial Office Premium Handwerk XV1100K(C)/XV1100SK(C) All rights reserverd. Any reprinting or unauthorized use wihout the written permission of Lexware Financial Office Premium Handwerk Corporation,

Mehr

Software Development Process - Overview

Software Development Process - Overview - Overview Requirements Specification (Feasibility Study) (Prototype) Reviews / Modifications Version Definition Design Build 1 Version Definition - Example July 03 Plan April 04 for Pilots Plan July `04

Mehr

Prof. Dr. Margit Scholl, Mr. RD Guldner Mr. Coskun, Mr. Yigitbas. Mr. Niemczik, Mr. Koppatz (SuDiLe GbR)

Prof. Dr. Margit Scholl, Mr. RD Guldner Mr. Coskun, Mr. Yigitbas. Mr. Niemczik, Mr. Koppatz (SuDiLe GbR) Prof. Dr. Margit Scholl, Mr. RD Guldner Mr. Coskun, Mr. Yigitbas in cooperation with Mr. Niemczik, Mr. Koppatz (SuDiLe GbR) Our idea: Fachbereich Wirtschaft, Verwaltung und Recht Simple strategies of lifelong

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

H. Enke, Sprecher des AK Forschungsdaten der WGL

H. Enke, Sprecher des AK Forschungsdaten der WGL https://escience.aip.de/ak-forschungsdaten H. Enke, Sprecher des AK Forschungsdaten der WGL 20.01.2015 / Forschungsdaten - DataCite Workshop 1 AK Forschungsdaten der WGL 2009 gegründet - Arbeit für die

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

Highlights versiondog 3.1

Highlights versiondog 3.1 Highlights versiondog 3.1 Release June 2014 Smart Import for supplier Wizard for receiving supplier in the versiondog system Tool for automated import, versioning and Check-In of files edited externally

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

Aber genau deshalb möchte ich Ihre Aufmehrsamkeit darauf lenken und Sie dazu animieren, der Eventualität durch geeignete Gegenmaßnahmen zu begegnen.

Aber genau deshalb möchte ich Ihre Aufmehrsamkeit darauf lenken und Sie dazu animieren, der Eventualität durch geeignete Gegenmaßnahmen zu begegnen. NetWorker - Allgemein Tip 618, Seite 1/5 Das Desaster Recovery (mmrecov) ist evtl. nicht mehr möglich, wenn der Boostrap Save Set auf einem AFTD Volume auf einem (Data Domain) CIFS Share gespeichert ist!

Mehr

Distributed testing. Demo Video

Distributed testing. Demo Video distributed testing Das intunify Team An der Entwicklung der Testsystem-Software arbeiten wir als Team von Software-Spezialisten und Designern der soft2tec GmbH in Kooperation mit der Universität Osnabrück.

Mehr

Ingest von Fachverfahren. Werkzeuge des Landesarchivs Baden-Württemberg

Ingest von Fachverfahren. Werkzeuge des Landesarchivs Baden-Württemberg Ingest von Fachverfahren. Werkzeuge des Landesarchivs Baden-Württemberg 13. Tagung des AK Archivierung von Unterlagen aus digitalen Systemen 27.4.2009, St. Gallen Dr. Christian Keitel und Rolf Lang Übersicht

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

Smart Import for supplier projects

Smart Import for supplier projects Release July 2014 Smart Import for supplier Wizard for receiving supplier in the versiondog system Tool for automated import, versioning and Check-In of files edited externally Enhanced user New-look overview

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

1.1 Media Gateway - SIP-Sicherheit verbessert

1.1 Media Gateway - SIP-Sicherheit verbessert Deutsch Read Me System Software 7.10.6 PATCH 2 Diese Version unserer Systemsoftware ist für die Gateways der Rxxx2- und der RTxxx2-Serie verfügbar. Beachten Sie, dass ggf. nicht alle hier beschriebenen

Mehr

1.1 IPSec - Sporadische Panic

1.1 IPSec - Sporadische Panic Read Me System Software 9.1.2 Patch 2 Deutsch Version 9.1.2 Patch 2 unserer Systemsoftware ist für alle aktuellen Geräte der bintec- und elmeg-serien verfügbar. Folgende Änderungen sind vorgenommen worden:

Mehr

Softwareprojekt Mobilkommunikation Abschlusspräsentation. SP Mobilkommunikation (SS09) - Abschlusspräsentation 16.7.2009 1

Softwareprojekt Mobilkommunikation Abschlusspräsentation. SP Mobilkommunikation (SS09) - Abschlusspräsentation 16.7.2009 1 Softwareprojekt Mobilkommunikation Abschlusspräsentation SP Mobilkommunikation (SS09) - Abschlusspräsentation 16.7.2009 1 Overview Introduction / Background (by L. AiQuan) Mobile Phones, Android, Use Cases,...

Mehr

Aufbau eines IT-Servicekataloges am Fallbeispiel einer Schweizer Bank

Aufbau eines IT-Servicekataloges am Fallbeispiel einer Schweizer Bank SwissICT 2011 am Fallbeispiel einer Schweizer Bank Fritz Kleiner, fritz.kleiner@futureways.ch future ways Agenda Begriffsklärung Funktionen und Aspekte eines IT-Servicekataloges Fallbeispiel eines IT-Servicekataloges

Mehr

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

Exercise (Part I) Anastasia Mochalova, Lehrstuhl für ABWL und Wirtschaftsinformatik, Kath. Universität Eichstätt-Ingolstadt 1 Exercise (Part I) 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

Methoden und Werkzeuge des Konfigurationsmanagements

Methoden und Werkzeuge des Konfigurationsmanagements Methoden und Werkzeuge des Konfigurationsmanagements Zunächst ein paar Fragen:! Was ist euer Bild des Konfigurationsmanagements?! Welche Aufgaben hat eurer Meinung nach das Konfigurationsmanagement?! Wer

Mehr

LOG AND SECURITY INTELLIGENCE PLATFORM

LOG AND SECURITY INTELLIGENCE PLATFORM TIBCO LOGLOGIC LOG AND SECURITY INTELLIGENCE PLATFORM Security Information Management Logmanagement Data-Analytics Matthias Maier Solution Architect Central Europe, Eastern Europe, BeNeLux MMaier@Tibco.com

Mehr

A Practical Approach for Reliable Pre-Project Effort Estimation

A Practical Approach for Reliable Pre-Project Effort Estimation A Practical Approach for Reliable Pre-Project Effort Estimation Carl Friedrich Kreß 1, Oliver Hummel 2, Mahmudul Huq 1 1 Cost Xpert AG, Augsburg, Germany {Carl.Friedrich.Kress,Mahmudul.Huq}@CostXpert.de

Mehr

Delivering services in a user-focussed way - The new DFN-CERT Portal -

Delivering services in a user-focussed way - The new DFN-CERT Portal - Delivering services in a user-focussed way - The new DFN-CERT Portal - 29th TF-CSIRT Meeting in Hamburg 25. January 2010 Marcus Pattloch (cert@dfn.de) How do we deal with the ever growing workload? 29th

Mehr

DVMD Tagung Hannover 2011

DVMD Tagung Hannover 2011 DVMD Tagung Hannover 2011 Vorstellung der Bachelorarbeit mit dem Thema Schwerwiegende Verstöße gegen GCP und das Studienprotokoll in klinischen Studien - Eine vergleichende Analyse der Regularien der EU-Mitgliedsstaaten

Mehr

IDRT: Unlocking Research Data Sources with ETL for use in a Structured Research Database

IDRT: Unlocking Research Data Sources with ETL for use in a Structured Research Database First European i2b2 Academic User Meeting IDRT: Unlocking Research Data Sources with ETL for use in a Structured Research Database The IDRT Team (in alphabetical order): Christian Bauer (presenter), Benjamin

Mehr

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

ITIL in 60 Minuten. Jörn Clausen. joernc@gmail.com. Captain Barbossa: And thirdly, the code is more what you d call guidelines than actual rules. ITIL in 60 Minuten 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

Mehr

Seminar in Requirements Engineering

Seminar in Requirements Engineering Seminar in Requirements Engineering Vorbesprechung Frühjahrssemester 2010 22. Februar 2010 Prof. Dr. Martin Glinz Dr. Samuel Fricker Eya Ben Charrada Inhalt und Lernziele Software Produktmanagement Ziele,

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

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

TMF projects on IT infrastructure for clinical research

TMF projects on IT infrastructure for clinical research Welcome! TMF projects on IT infrastructure for clinical research R. Speer Telematikplattform für Medizinische Forschungsnetze (TMF) e.v. Berlin Telematikplattform für Medizinische Forschungsnetze (TMF)

Mehr