Projekthandbuch

Größe: px
Ab Seite anzeigen:

Download " Projekthandbuch"

Transkript

1 Bundesamt für Informationsmanagement und Informationstechnik in der Bundeswehr Projektbereich XY <Planung und Steuerung> Projektbezeichnung: ToSA Datum: Vorhabennummer: < Vorhabennummer > Version: 1.7 Az: < Aktenzeichen >

2 Das V-Modell XT ist urheberrechtlich geschützt. Copyright 2006 V-Modell XT Autoren und andere. Alle Rechte vorbehalten. Das V-Modell XT ist unter der Apache License Version 2.0 freigegeben. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. Zuletzt geändert: :58 2/22

3 Projektleiter Hr. Odysseus Verantwortlich Projektleiter Erstellt am Zuletzt geändert Bearbeitungszustand in Bearbeitung vorgelegt X fertig gestellt Dokumentablage ToSA\..\Anforderungen und Analysen\.rtf V-Modell-XT Version Version 1.2bw Weitere Produktinformationen Mitwirkend [nicht beteiligt] Systemarchitekt Hr. Dr. Aristoteles Projektmanager Hr. Dr. Sokrates Systemsicherheitsbeauftragter Hr. Hermes Ausschreibungsverantwortlicher [nicht beteiligt] KM-Verantwortlicher Hr. Odysseus Projektkaufmann Erzeugung Initial Änderungsverzeichnis Änderung Nr. Datum Version Geänderte Kapitel Beschreibung der Änderung Autor Zustand Alle Initiale Produkterstellung Mk i.b Alle Produktbearbeitung Mk i.b Alle Fehlanalyse Mk i.b Alle Integration des aktualisierten Durchführungsplans und des aktualisierten Anwendungsprofils Mk i.b Vorlegen zur Prüfung Mk Vg Alle Review durchgeführt und kommentiert Tt i.b Alle Review eingearbeitet Mk i.b Alle Inhaltliche Bearbeitung Mk Vg Produkt fertig gestellt Tt f.g. Zuletzt geändert: :58 3/22

4 Prüfverzeichnis <Geheimhaltungsgrad> Die folgende Tabelle zeigt einen Überblick über alle Prüfungen sowohl Eigenprüfungen wie auch Prüfungen durch eigenständige Qualitätssicherung des vorliegenden Dokumentes. Datum Geprüfte Version Anmerkungen Prüfer Neuer Produktzustand Anmerkungen sind im Dokument hinterlegt Tt i.b Produkt nach Prüfung fertig gestellt Tt f.g. Zuletzt geändert: :58 4/22

5 Inhalt 1 Einleitung Projektüberblick, Projektziele und Erfolgsfaktoren Einführung Zielsetzung Projektspezifisches V-Modell Kriterienfestlegung Abweichungen vom V-Modell Projektdurchführungsplan Organisation und Vorgaben zum Projektmanagement Organisation und Vorgaben zum Risikomanagement Organisation und Vorgaben zum Problem- und Änderungsmanagement Vorgaben und Verfahren Zustände von Änderungsanträgen Organisation und Vorgaben zum Konfigurationsmanagement Organisation und Vorgaben zum Anforderungsmanagement Organisation und Vorgaben zur Systemsicherheit Berichtswesen und Kommunikationswege Abkürzungsverzeichnis Formblatt Änderungsantrag Zuletzt geändert: :58 5/22

6 1 Einleitung Das V-Modell ist ein generischer Vorgehensstandard, der für ein konkretes Projekt angepasst und konkretisiert werden muss. Das legt die für Management und Entwicklung notwendigen Anpassungen und Ausgestaltungen fest. Somit dokumentiert es Art und Umfang der Anwendung des V-Modells im Projekt und ist Informationsquelle und Richtlinie für alle Projektbeteiligten. Das beinhaltet eine Kurzbeschreibung des Projekts, die Beschreibung des Tailoring-Ergebnisses, den grundlegenden Projektdurchführungsplan, die notwendige und vereinbarte Unterstützung des Auftraggebers sowie Organisation und Vorgaben für die Planung und Durchführung des Projekts und die anstehenden Entwicklungsaufgaben. Der Projektleiter muss dieses zentrale Produkt in Abstimmung mit den Schlüsselpersonen des Projekts erarbeiten. Dabei werden im auch insbesondere Häufigkeit und Notwendigkeit der Erzeugung weiterführender Produkte, die für die Planung und Durchführung des Projekts, für das Ausschreibungs- und Vertragswesen sowie für die Prozessverbesserung notwendig sind, festgelegt, zum Beispiel Projektstatusberichte, Risikolisten, Verträge und Bewertungen von Vorgehensmodellen. 2 Projektüberblick, Projektziele und Erfolgsfaktoren 2.1 Einführung Die Bundesrepublik Deutschland erkennt die Notwendigkeit der Bereitstellung von Ressourcen für nationale Krisensituationen, wie Naturkatastrophen. Insbesondere Einsätze der Bundeswehr zur Krisenbewältigung sowie im Rahmen von Rettungs-, Hilfs- oder Evakuierungsoperationen sind inzwischen praktizierte Realität geworden. Hierfür wird eine Unterstützung der in Frage kommenden Streitkräfte benötigt, die im gesamten Aufgabenspektrum (z.b. gezielte Truppenverlegungen, gezielte Bereitstellung von Hilfsgütern) verwendbar, für den Einsatz optimal vorbereitet (z.b. aufbereitetes, aktuelles Kartenmaterial von betroffenen Regionen, wie Positionen von Dämmen usw.) und hoch verfügbar ist. Eine sinnvolle Koordination der Einsatztruppen erfordert ein Militärisches Informationswesen, das sowohl Vorbereitung als auch die Durchführung von Einsätzen wirkungsvoll unterstützt. Das System für die Koordination für die Auftragserfüllung im nationalen Krisenfall (ToSA), realisiert das zur Auftragserfüllung des Militärischen Informationswesens der Bundeswehr (MilInfoWBw) notwendige nationale FüInfoSys zum koordinierten Einsatz der Bundeswehr im Falle einer Naturkatastrophe. Es leistet die informationstechnische Unterstützung zur Planung und Anwendung von Hilfestellungen und zur Unterstützung von Zivilbehörden. 2.2 Zielsetzung Das Projekt ToSA realisiert das nationale FüInfoSys MilInfoWBw für die Katastrophenbewältigung. Die Erfüllung dieser Aufgabe im streitkräfteübergreifenden Kontext verlangt von To- SA, in das vorhandene FüInfoSys mittelfristig zu migrieren und dort die Zusammenführung eingehender Krisenmeldungen aufzubereiten, darzustellen und den sich vor Ort im Einsatz befindenden Truppen zur Verfügung zu stellen. Der MilInfoW-spezifische Anteil von ToSA wird als integrierter Bestandteil in einem Streitkräftegemeinsamen FüInfoSys der Bundeswehr integriert. Gemeinsam genutzte Funktionen (E- Mail, Message Handling, Web-Services usw.) werden durch die Common Support Services (CSS) gestellt, soweit diese nicht vom Kommunikationssystem der Bundeswehr realisiert werden. Zuletzt geändert: :58 6/22

7 3 Projektspezifisches V-Modell 3.1 Kriterienfestlegung Das Projekt ToSA wird in diesem Stadium in der Analysephase des CPM durchgeführt. Für die Projektdurchführung wurden daher beim Tailoring folgende Vorgehensbausteine ausgewählt/festgelegt. Eine explizite Belegung von Projektmerkmalen ist (mit Ausnahme der bestimmenden Merkmale) nicht erfolgt. Projekttyp: Systementwicklungsprojekt (AG) Anwendungsprofil: Projektgegenstand: Komplexes System. Projektrolle: AG in der Bundeswehr. Systemlebenszyklusausschnitt: Keine Angabe. Kaufmännisches Projektmanagement: Keine Angabe. Quantitative Projektkennzahlen: Keine Angabe. Fertigprodukte: Keine Angabe. Benutzerschnittstelle: Keine Angabe. Safety und Security: Keine Angabe. Hohe Realisierungsrisiken: Keine Angabe. Ausgewählte Vorgehensbausteine: Projektmanagement Qualitätssicherung Konfigurationsmanagement Problem- und Änderungsmanagement Lieferung und Abnahme (AG) Vertragsschluss (AG) Anforderungsfestlegung Multi-Projektmanagement Bedarfsermittlung und Bedarfsdeckung in der Bundeswehr (CPM) Ausgewählte Projektdurchführungsstrategien: Vergabe und Durchführung von Systementwicklungsprojekten mit CPM (Analysephase) 4 Abweichungen vom V-Modell Aufgrund der Anlage dieses Projekt ist damit zu rechnen, dass Produkte nach V-Modell 97 (AU-250) erstellt werden. Dieses Projekt weicht insofern vom V-Modell XT ab, dass diese Umstände berücksichtigt werden müssen. Als Konsequenz wird in folgenden Bereichen abgewichen und anstelle des V-Modell XT der etablierte Pro-zess des IT-AmtBw adaptiert: Projektplanung: Erfolgt durch AZF Plan in Kombination mit VOCON QS: Erfolgt anhand der Phasendokumente und der im IT-AmtBw üblichen Mitzeichnung verantwortlicher Organisationseinheiten Berichtswesen: Erfolgt anhand der etablierten Vorgehensweisen im ItT-AmtBw Zuletzt geändert: :58 7/22

8 Auf die Abweichungen vom V-Modell XT wird im Rahmen dieses Dokuments und im QS-Handbuch an geeigneter Stelle detailliert eingegangen. 5 Projektdurchführungsplan Dieses Thema befasst sich mit der Darstellung des Meilensteinplans, der aus dem Tailoring des V-Modell XT hergeleitet wurde. Dieser versteht sich als initiale, grobe Darstellung, die als Richtlinie für das Projekt gilt. Die lebende Planung erfolgt mithilfe des Durchführungsplans in MS Project. Meilensteine: SFF unterzeichnet (CPM) ( ) Projekt definiert ( ) Anforderungen festgelegt ( ) Projekt ausgeschrieben ( ) Projekt beauftragt ( ) Iteration geplant - Iteration 1 (Konzept) ( ) Projektfortschritt überprüft ( ) Projektfortschritt überprüft ( ) Projektfortschritt überprüft ( ) Machbarkeit nachgewiesen (CPM) ( ) Iteration geplant - Iteration 2 (Technik) ( ) Projektfortschritt überprüft ( ) Projektfortschritt überprüft ( ) Machbarkeit nachgewiesen (CPM) ( ) AF unterzeichnet (CPM) ( ) Projekt abgeschlossen ( ) Die Meilensteine Projektfortschritt überprüft sind in Ihrer Planung noch nicht fixiert. Lediglich die Mindestanzahl ist an dieser Stelle festgelegt, d.h. dass in der ersten Iteration (mindestens) 3 und in der zweiten Iteration (mindestens) 2 Fortschrittsprüfungen durchgeführt werden müssen. Die konkrete Anzahl sowie die genaue Terminierung obliegen dem durchführenden Verantwortlichen. Der Meilenstein Projekt abgeschlossen steht für den formalen Abschluss des V-Modell XT konformen Durchführungsrahmens. Dieser Abschluss ist gleichzeitig mit der Unterzeichnung der AF anzustreben, kann jedoch auch nachlaufend erfolgen, sofern die Ausplanung evtl. folgender Projekte/Projektphasen nicht beeinträchtigt wird. Zuletzt geändert: :58 8/22

9 6 Organisation und Vorgaben zum Projektmanagement Die Angaben dieses Abschnitts beziehen sich auf organisatorische Aspekte des Projekts. Dabei werden unter anderem die Rollen und deren Besetzungen festgeschrieben. Weiterhin werden die Projektmanagementinfrastruktur sowie Vorgaben zur Planung und Erstellung von Arbeitsaufträgen gemacht. Auch das Konfliktmanagement wird in geeigneter Weise betrachtet. Rollen und deren Besetzung Rolle Änderungsverantwortlicher Anforderungsanalytiker (AG) Anwender Mitarbeiter Hr. Odysseus Ausschreibungsverantwortlicher Hr. Hermes Einkäufer KM-Verantwortlicher Lenkungsausschuss (erst nach SFF/CPM) Projektkaufmann Projektleiter (CPM) Wird durch IAGFA gebildet N.N. zu benennen durch zuständige Org.-Einheit(en) Hr. Hermes N.N. zu benennen durch zuständige Org.-Einheit Hr. Odysseus, Hr. Dr. Aristoteles, Hr. Dr. Platon, Hr. Dr. Sokrates, Hr. Hermes Hr. Odysseus Hr. Dr. Aristoteles Projektleiter (nach V-Modell XT) Hr. Odysseus Prüfer QS-Verantwortlicher Qualitätsmanager Systemsicherheitsbeauftragter N.N. zu benennen durch zuständige Org.-Einheit(en) Hr. Prometheus Hr. Dr. Platon Hr. Dr. Sokrates Softwareinfrastruktur für die Projektdurchführung Als Projektmanagementinfrastruktur werden für die initialen Arbeiten am V-Modell der V- Modell XT Projektassistent und ggf. der V-Modell XT Editor (soweit erforderlich) verwendet. Die Infrastruktur für die Projektdurchführung besteht aus: Microsoft Project (Planung) Office-Paket (z.b. Microsoft Office, Open Office) für die Erstellung von Dokumenten -Client (z.b. Outlook, Thunderbird) für den Austausch elektronischer Nachrichten sonst. Management-unterstützende Softwarelösungen Die entsprechenden Softwarepakte müssen allen Beteiligten zur Verfügung gestellt werden. Eine gemeinsame Dokumentenablage ist einzurichten (z.b. CVS, Shared Folders) und allen Beteiligten zugänglich zu machen. Die Projektplanung wird mit MS-Project - ggf. auf der Grundlage des sich aus dem Tailoring ergebenden Durchführungsplans - erstellt und fortgeführt. Diese Grobpausplanung, die bereits alle Entscheidungspunkten beinhaltet, wird um eine Detailplanung der einzelnen Aktivitäten, die jeweils zum Erreichen eines Entscheidungspunkts notwendig sind, ergänzt. Weitere Detailplanungen erfolgen immer rechtzeitig zur Haushaltsverhandlung Anfang des Jahres und bei Projektverzögerungen mit Auswirkung auf die AZF-Planung. Zuletzt geändert: :58 9/22

10 Aufwandschätzungen werden im Projektplan dokumentiert. Es wird kein Projekttagebuch geführt. Die Dokumentation von Projektmanagemententscheidungen geschieht über VOCON, IVF/SPV und die Protokolle der Lenkungsausschusssitzungen. Protokolle etc. sind so zu gestalten, dass der Projektverlauf reproduzierbar dokumentiert wird. Vergabe von Arbeitsaufträgen Projektintern werden Arbeitsaufträge mittels einer Action-Item -Liste vergeben und verfolgt (Beispiel siehe folgende Tabelle). Die AI-Liste wird bei jeder Projektsitzung durchgegangen und aktualisiert. Lfd. Nr Datum Action Item Status Bearbeiter Termin Bemerkung/ Referenz Es folgt eine Erläuterung der einzelnen Spalten der AI-Liste: Lfd. Nr. (#): Eindeutige Nummer die jedem AI zur Identifikation zugewiesen wird. Datum: Erstellungsdatum des Eintrags Action Item: Beschreibung der durchzuführenden Aktivität. Status: Kann die Werte verzögert, offen oder erledigt annehmen. Wird bei Kontrolle der AI-Liste der Zieltermin für die Aktivität überschritten, dann ist der Zieltermin anzupassen und der Status auf verzögert zu setzen (vgl. Spalte Termin) Bearbeiter: Verantwortlicher für die Aufgabe. Termin: Geplanter Fertigstellungstermin für die Aktivität. Bemerkung/Referenz: Optionale Bemerkungen, z.b. bei Verzögerungen. Feststellung des Projektfortschritts Der aktuelle Projektfortschritt wird im Rahmen von Projektbesprechungen, die fortlaufend stattfinden, ermittelt. Der Projektstatus wird in Form eines Projektstatusberichts festgehalten, der bereits in der üblichen Form des IT-AmtBw (den etablierten Richtlinien und Dokumenten des CPM folgend) erstellt wird. 7 Organisation und Vorgaben zum Risikomanagement Damit die Einschätzungen der Risiken innerhalb des Projekts nach denselben Maßstäben erfolgen, wird das im V-Modell bereits vorgesehene Risikomanagement in diesem Kapitel ausgestaltet und konkretisiert. Dabei ist die generelle Entscheidung zu treffen, ob neben Risiken auch Chancen betrachtet werden sollen. Für Chancen wird das gleiche Verfahren wie für Risiken angewendet, deshalb wird im Folgenden nicht mehr zwischen den Begriffen Chance und Risiko unterschieden. Als Risiko definieren wir ein potentielles Problem, dass materiellen Schaden für das Projekt zur Folge hat. Dies können beispielsweise personelle Defizite, hohe Komplexität des Projektes oder unrealistische Terminvorgaben sein. Tritt ein Risiko ein, für das noch keine Gegenmaßnahmen ergriffen wurden, so wird es analog zum Problem- und Änderungsmanagement behandelt. Führen einer Risikoliste Es wird eine Risikoliste geführt. Die Risikoliste wird bei jeder Projektbesprechung und zu den Entscheidungspunkten besprochen und überarbeitet. Dazu werden die einzelnen Risiken Zuletzt geändert: :58 10/22

11 jeweils neu bewertet. Neu erkannte Risiken werden hinzugefügt. Jedes Risiko wird mittels Risikoanalyse analysiert und klassifiziert. Zwischen folgenden Klassifikationen wird unterschieden: Tolerierbar: kein monetärer Schaden bzw. kaum Einfluss auf den zeitlichen Projektablauf. Maßnahmen sind zu treffen, falls der Aufwand gerechtfertigt ist. Unerwünscht: Schaden bis Maßnahmen müssen geplant werden. Kritisch: Maßnahmen müssen geplant und eine Entscheidung herbeigeführt werden. Katastrophal: Es besteht die Gefahr eines Projektabbruchs. Maßnahmen müssen geplant werden. Zu jedem Risiko gibt es einen Maßnahmenkatalog der auch Teil der Risikoliste ist. Dort wird beschrieben wie mit den Risiken zu verfahren ist. Maßnahmen, die definiert werden, müssen in die Projektplanung einfließen. Der Abschluss einer solchen Maßnahme ist mit einem Meilenstein zu kennzeichnen. Erfassung von Risiken im Projekt Die Infrastruktur zur Erfassung und Verwaltung von Risiken wird durch eine Excel-Liste realisiert. Die Excel-Liste wird, für jeden Projektmitarbeiter zugreifbar, im Konfigurationsmanagementsystem abgelegt. Die folgende Tabelle zeigt den beispielhaften Aufbau einer Risikoliste wie sie im Projekt, beispielsweise durch eine Excel-Tabelle umgesetzt werden kann. Erstellungsdatum Beschreibung Status Eingereicht durch (Geschätzter) Schaden Wahrscheinlichkeit Klassifizierung Maßnahmen Auswirkungen Erläuterung der Spalten der Risikoliste: Erstellungsdatum: Datum der Aufnahme des Risikos in die Liste Beschreibung: Erläuterung des Risikos Status: Offen : Risiko wurde eingetragen. Es sind jedoch noch keine Maßnahmen geplant. Akzeptiert : Das Eintreten des Risikos wird toleriert. Es werden keine Gegenmaßnahmen geplant. Geplant : Maßnahmen wurden geplant und sind in Arbeit. Erledigt : Risiko wurde durch Maßnahme beseitigt. Eingereicht durch: Person die das Risiko einreicht. (Geschätzter) Schaden (in ): Der durch Risikoanalyse geschätzte Schaden für das Projekt. Wahrscheinlichkeit: Ist die geschätzte Wahrscheinlichkeit mit der das Risiko eintreten wird. Gering : Kleiner 25% Mittel : Zwischen 25% und 75% Hoch : Größer 75% Zuletzt geändert: :58 11/22

12 Eingetreten Klassifizierung: Tolerierbar Unerwünscht Kritisch Katastrophal <Geheimhaltungsgrad> Maßnahmen: Beschreibung der geplanten Maßnahmen. Auswirkungen: Beschreibung der Auswirkungen der Maßnahmen (z.b. Auswirkung auf die Erstellung anderer Arbeitspakete und die Projektplanung). 8 Organisation und Vorgaben zum Problem- und Änderungsmanagement 8.1 Vorgaben und Verfahren Jede im Projekt beteiligte Person kann Änderungswünsche, wie z.b. Verbesserungsvorschläge, technische Änderungen, funktionale Erweiterungen etc. über einen Änderungsantrag schriftlich beantragen. Hierfür wird ein einheitliches Formular (Change Request Formular) benutzt *. Der Antragsteller füllt die lfd. Nr. 1 des Formulars aus. Ein Verweis auf ergänzende Anlagen ist möglich. Unter Kurzbezeichnung sollte der Änderungswunsch mit wenigen Begriffen beschrieben werden. Die Wichtigkeit der gewünschten Änderung für den Projektverlauf (sowohl aus terminlicher als auch aus funktionaler Sicht) kann durch Angabe der Dringlichkeit gekennzeichnet werden. In der lfd. Nr. 1 wird durch Unterschrift des Auftraggebers der Antrag bestätigt. Der KM-Verantwortliche des Auftragnehmers überprüft den Antrag formal, vergibt eine eindeutige Antrags-Nr., dokumentiert durch seine Unterschrift den formalen Eingang und stellt diesen Antrag fortan unter KM-Kontrolle. Der Projektleiter des Auftragnehmers reicht diesen Antrag zur weiteren Beurteilung/Analyse und zur Erarbeitung von Änderungs-/Realisierungsvorschlägen an die betreffende Stelle weiter. Dabei werden auch die Auswirkungen auf Kosten und Termine bewertet. Die Ergebnisse werden in der lfd. Nr. 2 des Formulars (Lösungskonzept) dokumentiert. Bei Bedarf erfolgt eine Erläuterung/Begründung zum Lösungskonzept auf ergänzenden Anlagen. Beträgt der Analyseaufwand für einen vom Auftraggeber eingereichten Änderungsantrag mehr als 1 Manntag, ermittelt der Auftragnehmer erst den genauen Analyseaufwand kostenfrei und legt diesen dem Auftraggeber zur weiteren Entscheidung vor. Erst nach Bestätigung der Kostenübernahme des Analyseaufwands durch den Auftraggeber wird mit der Analyse dieser Änderungsanträge begonnen. Die Analyse von Änderungsanträgen, die vom Auftragnehmer eingereicht werden, ist für den Auftraggeber kostenfrei. Im Change-Control-Board (CCB) wird über das Änderungsvorgehen entschieden. Das CCB setzt sich zusammen aus den folgenden Stimmberechtigten: Projektdurchführungsverantwortlicher ToSA Vertreter Vertragsreferat (bei Bedarf) Projektleiter AN Kaufm. Vertreter AN Der Änderungsantrag kann entweder verworfen werden, * Diese Aussagen beziehen sich auf das im IT-AmtBw verwendete V-Modell 97 kompatible CR- Formular. Ein Muster des Formulars ist dem beizulegen! Das hier referenzierte Beispiel befindet sich im Anhang Kapitel 14. Zuletzt geändert: :58 12/22

13 mit Aufnahme in den Anforderungskatalog zurückgestellt werden oder die Einleitung der Änderung beschlossen werden. Das Ergebnis des CCB wird in der lfd. Nr. 3 des Formulars entsprechend dokumentiert. Bei Beschluss über die Einleitung der Änderung werden die Projektleiter die erforderlichen Schritte zur Umsetzung durchführen. Bei vertragsrelevanten Änderungen, die seitens des AN zu Mehrkosten führen, ist ein schriftlicher Auftrag (Änderungsvertrag) des AG (lfd. Nr. 4) erforderlich. 8.2 Zustände von Änderungsanträgen Der KM-Verantwortliche des AN verwaltet den jeweils aktuellen Bearbeitungsstatus. Folgende Zustände sind vorgesehen: Zustand erfasst Bewertung Vorlage beauftragt Realisierung abgeschlossen zur Abnahme/Review bereitgestellt abgenommen abgelehnt zurückgestellt Beschreibung der Änderungsantrag ist unter KM erfasst der Änderungsantrag wird analysiert und bewertet das Ergebnis der Bewertung (Entscheidungsvorlage) liegt vor die Durchführung der Änderung ist beauftragt die Durchführung der Änderung ist in der Realisierung die Durchführung der Änderung ist (aus Sicht des Bearbeiters) abgeschlossen die Änderung wurde übergeben und steht zur Abnahme/Review bereit die Änderung wurde vom AG/BT abgenommen das CCB hat dem Änderungsantrag nicht zugestimmt; d. h. es erfolgt keine weitere Bearbeitung der Antrag wurde zurückgestellt, eine spätere Wiederaufnahme des Vorgangs ist möglich Zuletzt geändert: :58 13/22

14 9 Organisation und Vorgaben zum Konfigurationsmanagement Dieses Thema beschreibt das Konfigurationsmanagement des Vorhabens ToSA. Hier werden die Vereinbarungen bez.: Produktbibliothek Identifikation Zugriffsrechten in der Produktbibliothek Bearbeitungszustände der Produkte Produktprüfung und QS Dateiablagestruktur und Namenskonventionen Speicherung von Konventionen und Datensicherung und Archivierung getroffen. Produktbibliothek Die Produktbibliothek wird zentral geführt. Die Ablage von Produkten erfolgt analog zur Ablage von Dateien im Dateisystem hierarchisch in einer Verzeichnisstruktur. Die Ablage der Dateien unterscheidet dabei CPM und V-Modell XT Dokumente. Die folgenden Aussagen beziehen sich auf die V-Modell XT Dokumente. Die Versionen werden auf den Deckblättern der (Haupt-)Produkte im Abschnitt Änderungsverzeichnis mit den Änderungsnotizen angezeigt. Im Projekt werden alle anfallenden Produkte in die Produktbibliothek eingestellt und unterliegen einer Versionsverwaltung. Sofern die Dokumente nur in Papierform vorliegen (z.b. externe Dokumente), werden diese eingescannt und in elektronischer Form abgelegt. Verwendbare Dateiformate Dateien dürfen nur in folgenden Formaten vorgehalten und ausgetauscht werden. als *.doc Word 2000-Datei oder als rtf-datei im Austauschformat Rich Text Format als *.xls Excel 2000-Datei als *.ppt Powerpoint 2000-Datei als *.mpp Project2000-Datei als *.vsd Visio2000-Datei als *.pdf PDF-Datei als *.gif, *.jpg Graphik-Datei Weitere Dateitypen dürfen nur im Ausnahmefall verwendet werden. In diesen Fällen ist in jedem Fall ein gleichartig benanntes Textdokument (*.txt) beizulegen, in dem Informationen zum verwendeten Programm und der Version sowie zum Autor verfügbar sind. Identifikation von Dokumenten in der Ablagestruktur Die Identifikation der Dokumente erfolgt über ihren Ablagepfad in der Hierarchie der Produktbibliothek. Eine zusätzliche Vergabe numerischer Dokumenten-IDs ist nicht vorgesehen. Der Ablagepfad enthält die Informationen über das Verzeichnis und den Dateinamen des Produktes innerhalb der Produktbibliothek, Zuletzt geändert: :58 14/22

15 z. B. bezeichnet <Geheimhaltungsgrad> ToSA\...\Planung und Steuerung\.doc das vorliegende. Der Ablagepfad wird auf dem Mantel (Innenseite) jedes Produktes ausgewiesen. Namenskonventionen nach ISO Für alle Produkte, die zu einem bestimmten Datum erstellt wurden und nicht mehr fortgeschrieben, werden gilt die Konvention: ISO-Datum Produktbezeichnung (Wobei das ISO- Datum durch das jeweilige Erstellungsdatum zu ersetzen ist). Ein Protokoll eines Arbeitstreffens wird damit beispielsweise unter dem Namen Protokoll Arbeitstreffen.doc abgelegt. Analog gilt diese Regelung für Verzeichnisse, deren Inhalte zu einem bestimmten Zeitpunkt erstellt und nicht mehr geändert werden. Laufend fortgeschriebene Produkte, wie z.b. das, werden unter Angabe der Versionsnummer hinter dem jeweiligen Namen gespeichert (z.b V1.6.doc ). Für fortzuschreibende Dokumente, die keine Versionsnummer enthalten, ist an das Erstellungsdatum eine fortlaufende 2-stellige Zahl, getrennt durch einen Bindestrich, einzufügen. Bsp.: DATEINAME.doc Bearbeitungszustände und Zustandsübergänge Die Abbildung des V-Modell XT Produktzustandsmodells, insbesondere die Zustandsänderungen, auf die Zeichnungspflicht im IT-AmtBW erfolgt in folgender Weise: In Bearbeitung: Das Dokument wird bearbeitet. In Bearbeitung Vorgelegt: Das betreffende Dokument wird zur Zeichnung durch die zuständigen Organisationseinheiten vorbereitet. Der bearbeitende Mitarbeiter ist für das Setzen des Zustands auf vorgelegt verantwortlich. Das Dokument bleibt solange im Zustand vorgelegt, bis die letzte notwendige Zeichnung erfolgt ist. Vorgelegt Fertig gestellt: Hat ein Dokument im Status vorgelegt erfolgreich alle Zeichnungen durchlaufen, wird es in den Zustand fertig gestellt überführt, bevor es in der Produktbibliothek archiviert wird. Die Prüfung des korrekten Zustands aller Dokumente muss regelmäßig im Rahmen der Meetings unter Aufsicht des Projektleiters erfolgen. Integration der V-Modell XT Produktbibliothek Für die Verwaltung von Dokumenten ist in allen Bereichen in der Regel eine einheitliche Struktur vorgesehen. Diese Struktur sollte nicht (auch nicht in Teilen) gelöscht werden. Jedoch kann sie erweitert werden. Für die Aufstellung eines Konfigurationsmanagementsystems (KM-System) gelten hierbei (insbesondere bei NATO-Projekten) die Richtlinien der STANAG 4159, 4427 sowie die ACMP 7. Das vorgeschlagene Schema des Dokuments "Bundeswehrspezifische Ergänzungen des V- Modell XT", Kapitel wird hierfür empfohlen. Es definiert die beispielhafte Integration der V-Modell XT Produktbibliothek in die CPM-Ablagestruktur eines Projektmanagements. In eine etablierte Ablagestruktur erweiternd und um eine saubere Trennung zwischen den V- Modell-Ergebnissen und den Dokumenten des CPM zu erhalten werden auf oberster Ebene der Ordnerstruktur drei neue Verzeichnisse hinzugefügt: 15 VMXT-Management 16 VMXT-Entwicklung 17 VMXT-Einführung Unter den Verzeichnissen mit der Nummerierung 15 und 16 wird die Produktstruktur des V- Modells eingeordnet. Die V-Modell-Struktur wird um die Trennung zwischen Management Zuletzt geändert: :58 15/22

16 und Entwicklung erweitert, um die Abbildung von Rechten auf die Verzeichnisstruktur leichter umzusetzen. <Projektbezeichnung> 01 Schriftverkehr 02 Personal 03 Besprechungen 04 Verhandlungen Legende: Produktgruppen Planung und Steuerung Berichtswesen Ausschreibungs- und Vertragswe- Anforderungen und Analysen 05 Gremien 06 Symposien 07 Berichte 08 Präsentation 09 Entscheidungs-Doku 10 Management-Doku 11 Vertrags-Doku 12 Technische-Doku 13 Projekt-Doku 14 - Produktinformationen 15 VMXT-Management Ausschreibungs- und Vertragswesen Berichtswesen Konfigurations- und Änderungsmanagement Planung und Steuerung Prüfung 16 VMXT-Entwicklung Anforderungen und Analysen 17 VMXT-Einführung Beispielprojekte und Dokumentation Zuletzt geändert: :58 16/22

17 Erstellen von Produktkonfigurationen <Geheimhaltungsgrad> Mit Erreichen jedes Entscheidungspunktes wird eine Konfiguration aller aktuellen Produkte in der CPM- und V-Modell XT Produktbibliothek gebildet (Ziehen einer Baseline). Diese Baselines werden in der Historie des obersten Hierarchieelementes aufgelistet und können zu einem späteren Zeitpunkt wieder aus der Produktbibliothek entnommen werden. Die Projektstruktur wird dabei wieder auf eine korrespondierende Verzeichnisstruktur abgebildet. Vorgehen zur Datensicherung und -archivierung im ITZBw Die gesamte Produktstruktur unterliegt dem dienststellenbezogenen IT-Sicherheitskonzept des IT-AmtBw bezüglich Datensicherung. Alle Server werden durch Backup auf Bänder täglich über Nacht gesichert. Daten stehen selbst nach dem Löschen aus dem Filesystem oder dem irrtümlichen Überschreiben kurzfristig, maximal innerhalb 1 Stunde zur Verfügung und können tagesgenau ab dem Vortag wiederhergestellt werden. Folgende Einstellungen werden für die Datensicherung verwendet: (1) Version Data Exists Neben der gültigen Version einer Datei werden noch bis zu 5 ältere Versionen verfügbar / wiederherstellbar gehalten. (2) Version Data Deleted Wird eine Datei gelöscht, hält das System noch bis zu 5 Versionen der gelöschten Datei verfügbar / wiederherstellbar. (3) Retain Extra Versions Die in (1) aufgeführten bis zu 5 extra Versionen einer Datei werden 50 Tage verfügbar gehalten. Hiernach werden die extra Versionen gelöscht, die gültige Version weiterhin verfügbar gehalten. (4) retain Only Version Die in (2) aufgeführten bis zu 5 Versionen einer bereits gelöschten Datei werden 50 Tage Verfügbar gehalten, hiernach gelöscht. Das Wiederherstellen erfolgt nach Beauftragung durch den Nutzerservice durch die Administratoren des ITZBw. Zum Abschluss des Projektes ist eine Gesamtarchivierung des Filesystems vorzunehmen. Die Archivierung erfolgt auf Bändern. Die Abschlussarchivierung ist durch den KM- Verantwortlichen einzuleiten. 10 Organisation und Vorgaben zum Anforderungsmanagement Es erfolgt die Festlegung, wann und welche Produkte für das Anforderungsmanagement zu verwenden sind, nach welchen Methoden, Richtlinien und Standards diese zu erstellen sind und mit welchen Werkzeugen beziehungsweise Bestandteilen der Projektmanagement- Infrastruktur sie zu bearbeiten sind. Vorgaben Die Erfassung und Änderung von Anforderungen erfolgt über eine MS-Access-Datenbank durch den Änderungsverantwortlichen. Die MS-Access-Datei ist abgelegt unter: To- SA\...\ Anforderungen ToSA.mdb. Derzeit besteht uneingeschränkter Zugriff auf die Datenbank. Künftig soll der Zugriff auf die Rolle des Systemanalytikers beschränkt wer- Zuletzt geändert: :58 17/22

18 den. Die einzelnen Anforderungen können entweder im Zustand geplant, in Bearbeitung, vorgelegt, abgelehnt oder akzeptiert sein. Die in der Datenbank abgelegten Anforderungen werden manuell in das Lastenheft übertragen. Es enthält alle Anforderungen an die zu erstellende Software. Diese werden im Rahmen der Anforderungsermittlung getrennt nach funktionalen und nicht funktionalen Anforderungen klassifiziert. Anforderungsbewertung Eine schriftliche Anforderungsbewertung, d. h. eine eingehende Bewertung der Anforderungen (Lastenheft) hinsichtlich technischer Machbarkeit, Finanzierbarkeit, Wirtschaftlichkeit und Wichtigkeit, wird durch mehrere Reviews und eine QS-Prüfung abgedeckt. Eine gesonderte schriftliche Anforderungsbewertung erfolgt nicht. Beteiligte am Anforderungsprozess Die Anforderungen wurden bereits im Vorfeld erstellt. Beteiligte waren sowohl die Anforderungsanalytiker als auch die Anwender. Die zusammengestellten Anforderungen wurden durch die IAGFA zur Kenntnis genommen und im V-Modell XT Produkt Anforderungen (Lastenheft) zusammengefasst. Die Verfolgung der Anforderungen (Traceability) liegt beim Projektleiter sowohl in der Projektierungs- als auch in der Einführungsphase. 11 Organisation und Vorgaben zur Systemsicherheit Dieses Thema befasst sich mit den Richtlinien zur Systemsicherheit. Als Referenz hierzu wird auf folgende Bezugsdokumente verwiesen: 1. ZDv 2/30 Sicherheit in der Bundeswehr 2. ZDv 54/110 VS-NfD Behandlung und Einsatz von Kryptomitteln 3. ZDv 54/100 VS-NfD IT-Sicherheit in der Bundeswehr 4. TDv 5820/ Betriebsvorgabengeräte VHF 5. Bauliche Absicherung in der Bundeswehr Nr. 158 GMIF BabsichBw 6. BMVg Sts/Fü S V 5 Az /VS-NfD v Für die Zulassung der VS-Auftragnehmer sind ggf. die Richtlinien des BSI und der ZDv 54/100 heranzuziehen. 12 Berichtswesen und Kommunikationswege Die folgenden Berichts- und Kommunikationswege dienen als Vorgabe in diesem Projekt. E- Mail ist das wichtigste Kommunikationsmedium im Projekt. -Verteiler existieren derzeit noch nicht. Alle Berichte müssen in schriftlicher Form erfolgen. Produkt VM Von Nach Wann Projektstatusbericht X AN-PL AG-PM, AG- Monatlich (AN) PL Projektabschlussbericht X AN-PL AG-PL Projektende QS-Bericht X QS PL Teil des Projektstatusbericht Änderungsantrag X Alle PL, PM Ereignis Änderungsstatusliste X Änderungsverantwortlicher Lenkungsausschuss Entscheidung / Problem / Ereignis Zuletzt geändert: :58 18/22

19 Produkt VM Von Nach Wann Arbeitsauftrag X PL, PM AG-alle Ereignis Agenda X Protokollant AG-alle Mind. 1 Werktag vor Besprechung Protokoll X Protokollant AG-alle Max. 2 Werktage nach Besprechung Prüfbericht X AN AG Nach der Prüfung wird durch AG genehmigt Projektfortschrittsentscheidung X Lenkungsausschuss PL Zu jedem Entscheidungspunkt Interner Projektbericht Anforderungsingenieur (AG), QS PL unregelmäßig, jedoch mindestens am Ende jedes Projektabschnittes Zuletzt geändert: :58 19/22

20 13 Abkürzungsverzeichnis <Geheimhaltungsgrad> Abkürzung AECMA AFSBw AFTO AL AMSC AN AnlBlAAN ATP AutoFüFmNLw AW BGS BITE BMVg BT BTK BV Bw BWB CALS COMSEC COTS CRC DGzRS DIN DV EBMat EFG EvakOp FlPl F ü L Fü M Fü S GenInspBw GIK HFmInstWerk HHJ HHM HW IR-Verträge IVS KdB KRK KSK Lfz LwA - PALw - LwFüKdo LWL LwMatDp LwUKdo LwWerft MatALw MarArs MatPlBegriff MatPlNr MBF Erklärung Association Européenne des Constructeurs de Matériel Aérospatial Amt für Flugsicherung der Bundeswehr Air Force Technical Order Artikelliste Allied Military Security Code System Auftragnehmer Anlagenblatt-Ausstattungsanweisung Air Tactical Publication Automatisches Führungsfernmeldenetz der Luftwaffe Arbeitsanweisung Bundes-Grenz-Schutz Built-in-Test-Equipment Bundesministerium der Verteidigung Bedienteil Bebildeter Teilekatalog Bauvorschrift Bundeswehr Bundesamt für Wehrtechnik und Beschaffung Continuous Acquisition and Life Cycle Support Communications Security (Abhörsicherheit Sprache) Commercial of the Shelf (handelsübliches Produkt) Control and Reporting Centre Deutsche Gesellschaft zur Rettung Schiffbrüchiger Deutsches Institut für Normung e.v. Datenverarbeitung Entwicklung, Beschaffung Wehrmaterial Einführungsgenehmigung militärische Evakuierungsoperationen Flugplatz Führungsstab der Luftwaffe Führungsstab der Marine Führungsstab der Streitkräfte Generalinspekteur der Bundeswehr Geräteinstandsetzungskonzept Heeresfernmeldeinstandsetzungswerk Haushaltjahr Haushaltmittel Hardware Instandsetzungs Rahmenverträge Informations Verteiler System Konzeption der Bundeswehr Krisenreaktionskräfte Kommando Spezialkräfte Luftfahrzeug Luftwaffenamt Abteilung Personal und Ausbildung der Luftwaffe Luftwaffenführungskommando Lichtwellenleiter Luftwaffenmaterialdepot Luftwaffenunterstützungskommando Luftwaffenwerft Materialamt der Luftwaffe Marinearsenal Materialplanungsbegriff Materialplanungsnummer Materialbeschaffungsforderung Zuletzt geändert: :58 20/22

QS-Handbuch

<Geheimhaltungsgrad> <Planung und Steuerung> QS-Handbuch Bundesamt für Informationsmanagement und Informationstechnik in der Bundeswehr Projektbereich XY Projektbezeichnung: ToSA Datum: 28.05.2006 Vorhabennummer: < Vorhabennummer > Version:

Mehr

Projektstatusbericht für WiBe 4.0 Projekt definiert. Version: 1.3

Projektstatusbericht für WiBe 4.0 Projekt definiert. Version: 1.3 -Berichtswesen: Projektstatusbericht- Projektstatusbericht für WiBe 4.0 Projekt definiert Version: 1.3 Projektbezeichnung Projektleiter Verantwortlich Erstellt am 10.02.2005 Zuletzt geändert 18.05.2005

Mehr

6 Vorgehensbausteine.

6 Vorgehensbausteine. <Datum> <Organisation> <Veranstaltungsort> <Vortragender> <Organisation> Bundesamt für Informationsmanagement und Informationstechnik der Bundeswehr 6 Vorgehensbausteine 1.2.1 Copyright V-Modell XT Das

Mehr

TelData. Version: A-Muster

TelData. Version: A-Muster -Prüfung: Prüfprotokoll Systemelement- TelData Version: A-Muster Projektbezeichnung Artio Neues Projekt Projektleiter Herr Karlapp Verantwortlich Hr. Deynet Prüfer Erstellt am 21.07.2005 Zuletzt geändert

Mehr

XT Bundesrepublik Deutschland, 2004, Alle Rechte vorbehalten

XT Bundesrepublik Deutschland, 2004, Alle Rechte vorbehalten XT Bundesrepublik Deutschland, 2004, Alle Rechte vorbehalten -Planung und Steuerung: Projektfortschrittsentscheidung- Projektfortschrittsentscheidung für InfoMaPa Projekt genehmigt Version: 1.1 Projektbezeichnung

Mehr

Anforderungen (Lastenheft)

<Geheimhaltungsgrad> <Anforderungen und Analysen> Anforderungen (Lastenheft) Bundesamt für Informationsmanagement und Informationstechnik in der Bundeswehr Projektbereich XY Projektbezeichnung: ToSA Datum: 28.05.2006 Vorhabennummer: < Vorhabennummer

Mehr

Projektfortschrittsentscheidung für InfoMaPa Projekt genehmigt

Projektfortschrittsentscheidung für InfoMaPa Projekt genehmigt -Planung und Steuerung: Projektfortschrittsentscheidung- Projektfortschrittsentscheidung für InfoMaPa Projekt genehmigt Version: 1.1 Projektbezeichnung InfoMaPa 1 Projektleiter Dr. Odysseus Verantwortlich

Mehr

Prüfspezifikation für Anforderungen (Lastenheft) für WiBe 4.0. Version: 1.3

Prüfspezifikation für Anforderungen (Lastenheft) für WiBe 4.0. Version: 1.3 -Prüfung: Prüfspezifikation Dokument- Prüfspezifikation für Anforderungen (Lastenheft) für WiBe 4.0 Version: 1.3 Projektbezeichnung Projektleiter Verantwortlich Erstellt am 11.03.2005 Zuletzt geändert

Mehr

Projekthandbuch für InfoMaPa 1. Version: 1.7

Projekthandbuch für InfoMaPa 1. Version: 1.7 -Planung und Steuerung: Projekthandbuch- Projekthandbuch für InfoMaPa 1 Version: 1.7 Projektbezeichnung InfoMaPa 1 Projektleiter Dr. Odysseus Verantwortlich Dr. Odysseus Erstellt am 13.04.2005 Zuletzt

Mehr

-Planung und Steuerung- Projektplan

-Planung und Steuerung- Projektplan -Planung und Steuerung- Projektplan Projektbezeichnung InfoMaPa I Projektleiter Dr. Odysseus Verantwortlich Projektleiter [Dr. Odysseus] Erstellt am 12.05.2001 Zuletzt geändert 12.05.2001 Zustand X in

Mehr

Software Engineering. 2. V-Modell XT

Software Engineering. 2. V-Modell XT Software Engineering 2. V-Modell XT Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz Implementierung Konfigurationsmanagement

Mehr

-Planung und Steuerung- Projekthandbuch

-Planung und Steuerung- Projekthandbuch -Planung und Steuerung- Projekthandbuch Projektbezeichnung InfoMaPa I Projektleiter Dr. Odysseus Verantwortlich Projektleiter [Dr. Odysseus] Erstellt am 09.05.2001 Zuletzt geändert 20.05.2001 Zustand X

Mehr

3 Projektumfeld WEIT*

3 Projektumfeld WEIT* Bundesamt für Informationsmanagement und Informationstechnik der Bundeswehr 3 Projektumfeld WEIT* * Weiterentwicklung des V-Modells

Mehr

2 Einführung in das V-Modell XT

2 Einführung in das V-Modell XT Bundesamt für Informationsmanagement und Informationstechnik der Bundeswehr 2 Einführung in das V-Modell XT V-Modell XT Anwendung im Projekt

Mehr

- Planung und Steuerung - Projekthandbuch

- Planung und Steuerung - Projekthandbuch - Planung und Steuerung - Projekthandbuch Projektbezeichnung WiBe 4.0 Musterprojekt Projektleiter Odysseus Verantwortlich Odysseus Erstellt am 10.02.2005 13:19 Zuletzt geändert 27.06.2005 16:23 Zustand

Mehr

Übung Einführung in die Softwaretechnik

Übung Einführung in die Softwaretechnik Lehrstuhl für Informatik 3 RWTH Aachen Übung Einführung in die Softwaretechnik Lösungshinweise zum Übungsblatt 3 Aufgabe 6a) Welche Projekttypen gibt es, und wie ist deren Zusammenhang? Systementwicklung

Mehr

Projektmanagement V-Modell XT-konform gestalten

Projektmanagement V-Modell XT-konform gestalten Projektmanagement V-Modell XT-konform gestalten PMI Munich Chapter Meeting 20. März 2007 Dr. Marc Sihling 2007 4Soft GmbH Agenda Überblick V-Modell XT Projektinitialisierung Tailoring Rollenbelegung Projektplanung

Mehr

9 Werkzeugunterstützung

9 Werkzeugunterstützung Bundesamt für Informationsmanagement und Informationstechnik der Bundeswehr 9 Werkzeugunterstützung Copyright V-Modell XT Das V-Modell

Mehr

7 Projektplanung. V-Modell XT Anwendung im Projekt.

7 Projektplanung. V-Modell XT Anwendung im Projekt. <Datum> <Organisation> <Veranstaltungsort> <Vortragender> <Organisation> Bundesamt für Informationsmanagement und Informationstechnik der Bundeswehr 7 Projektplanung V-Modell XT Anwendung im Projekt Überblick

Mehr

Projekthandbuch für WiBe 4.0. Version: 1.6

Projekthandbuch für WiBe 4.0. Version: 1.6 -Planung und Steuerung: Projekthandbuch- Projekthandbuch für WiBe 4.0 Version: 1.6 Projektbezeichnung WiBe 4.0 Musterprojekt Projektleiter Odysseus Verantwortlich Odysseus Erstellt am 10.02.2005 Zuletzt

Mehr

TelApi. Version: A-Muster

TelApi. Version: A-Muster -Systemspezifikationen: SW-Spezifikation- TelApi Version: A-Muster Projektbezeichnung Artio Projektleiter Herr Karlapp Verantwortlich Herr Deynet SW-Architekt Erstellt am Zuletzt geändert 20.02.2008 12:16

Mehr

Einführung V-Modell XT. Das neue V-Modell XT Release 1.2 - Der Entwicklungsstandard für IT Systeme des Bundes

Einführung V-Modell XT. Das neue V-Modell XT Release 1.2 - Der Entwicklungsstandard für IT Systeme des Bundes Einführung V-Modell XT Das neue V-Modell XT Release 1.2 - Der Entwicklungsstandard für IT Systeme des Bundes 1 Inhalt RAN Motivation Herkunft und Ziele des V-Modell XT Struktur und Aufbau des V-Modell

Mehr

3 Angebotsphase. V-Modell XT Anwendung im Projekt.

3 Angebotsphase. V-Modell XT Anwendung im Projekt. <Datum> <Organisation> <Veranstaltungsort> <Vortragender> <Organisation> Bundesamt für Informationsmanagement und Informationstechnik der Bundeswehr 3 Angebotsphase V-Modell XT Anwendung im Projekt Inhalt

Mehr

5 Grundkonzepte.

5 Grundkonzepte. <Datum> <Organisation> <Veranstaltungsort> <Vortragender> <Organisation> Bundesamt für Informationsmanagement und Informationstechnik der Bundeswehr 5 Grundkonzepte Copyright V-Modell XT Copyright Reserved,

Mehr

Das V-Modell XT in kleinen Projekten Möglichkeiten und Grenzen

Das V-Modell XT in kleinen Projekten Möglichkeiten und Grenzen Das V-Modell XT in kleinen Projekten Möglichkeiten und Grenzen Erfahrungen aus einem sehr kleinen Projekt Dr. Ralf Kneuper Prof. Dr. Matthias Knoll 1 Ralf Kneuper Dipl.-Mathematiker, Univ. Bonn PhD Computing

Mehr

V-Modell. Dipl. Wirtsch. Ing. Alexander Werth 11-1

V-Modell. Dipl. Wirtsch. Ing. Alexander Werth 11-1 V-Modell Dipl. Wirtsch. Ing. Alexander Werth Software Engineering 11-1 Was ist das V-Modell? Das V im V-Modell steht für Vorgehensmodell. Umfangreiches Dokument. Softwaretool zur Unterstützung. Vorgabe

Mehr

PRINCE2 TAG 2011. PRINCE2 in Projekten der Bundesbehörden und der Bundeswehr. Peter Morwinski, Leiter Technologie Center

PRINCE2 TAG 2011. PRINCE2 in Projekten der Bundesbehörden und der Bundeswehr. Peter Morwinski, Leiter Technologie Center Ihr starker IT-Partner. Heute und morgen PRINCE2 in Projekten der Bundesbehörden und der Bundeswehr PRINCE2 TAG 2011 Peter Morwinski, Leiter Technologie Center INHALT PRINCE2 und V-Modell XT Einleitung

Mehr

Professionelles Projektmanagement mit dem V - Modell XT

Professionelles Projektmanagement mit dem V - Modell XT Professionelles Projektmanagement mit dem V - Modell T Dr. Ingo Zank / IKMT (VT, 04/2007) V-Modell Release 1.2 Ein Seminar des IKMT - Institut für kreatives Management und Training Postfach 330145 14171

Mehr

Ausschreibungskonzept für WiBe 4.0. Version: 1.4

Ausschreibungskonzept für WiBe 4.0. Version: 1.4 -Ausschreibungs- und Vertragswesen: Ausschreibungskonzept- Ausschreibungskonzept für WiBe 4.0 Version: 1.4 Projektbezeichnung Projektleiter Verantwortlich Erstellt am 15.03.2005 Zuletzt geändert 18.05.2005

Mehr

Das neue V-Modell 200x ein modulares Vorgehensmodell

Das neue V-Modell 200x ein modulares Vorgehensmodell Das neue V-Modell 200x ein modulares Vorgehensmodell 28. April 2004 Perlen der Weisheit Ulrike Hammerschall Ausgangssituation und Zielsetzung Ausgangssituation des V-Modells Verbreitete Richtschnur für

Mehr

- Planung und Steuerung: Risikoliste - Code-Generator für die Erstellung einer Lebenslaufakte. Version: 1.0. Nicole Scheeren

- Planung und Steuerung: Risikoliste - Code-Generator für die Erstellung einer Lebenslaufakte. Version: 1.0. Nicole Scheeren - Planung und Steuerung: Risikoliste - Code-Generator für die Erstellung einer Lebenslaufakte Version: 1.0 Projektbezeichnung Projektleiter Verantwortlich Erstellung einer Lebenslaufakte Nicole Scheeren

Mehr

Geschäftsmann 2.0 http://www.geschaeftsmann20.com

Geschäftsmann 2.0 http://www.geschaeftsmann20.com Geschäftsmann 2.0 http://www.geschaeftsmann20.com Inhaltsverzeichnis 1 Projektbeschreibung... 2 2 Szenario mit Phasen und Meilensteinen... 2 3 Organisation... 2 4 Projektergebnisstrukturplan... 2 5 Szenario

Mehr

m.e.d. concept methode erfolg datenverarbeitung V-Modell XT im Überblick 2 V-Modell XT Einführung - Analyse und Roadmap 3

m.e.d. concept methode erfolg datenverarbeitung V-Modell XT im Überblick 2 V-Modell XT Einführung - Analyse und Roadmap 3 Projektmanagement Kompetenztraining V-Modell XT Das V-Modell XT ist urheberrechtlich geschützt, Bundesrepublik Deutschland, 2004, Alle Rechte vorbehalten m.e.d. concept methode erfolg datenverarbeitung

Mehr

Vorlesung Software-Wartung Änderungs- und Konfigurationsmanagement

Vorlesung Software-Wartung Änderungs- und Konfigurationsmanagement Vorlesung Software-Wartung Änderungs- und Konfigurationsmanagement Dr. Markus Pizka Technische Universität München Institut für Informatik pizka@in.tum.de 3.3 Änderungsmanagement (CM) Evolution der Software

Mehr

Di 7.2. Sprinten mit dem V-Modell XT. Olaf Lewitz. January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich

Di 7.2. Sprinten mit dem V-Modell XT. Olaf Lewitz. January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich Di 7.2 January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich Sprinten mit dem V-Modell XT Olaf Lewitz Sprinten mit dem V-Modell XT Olaf Lewitz microtool GmbH, Berlin Konkurrenz

Mehr

V-Modell XT. Teil 5: V-Modell-Referenz Produkte

V-Modell XT. Teil 5: V-Modell-Referenz Produkte V-Modell XT Teil 5: V-Modell-Referenz Produkte DAS V-MODELL XT IST URHEBERRECHTLICH GESCHÜTZT. BUNDESREPUBLIK DEUTSCHLAND 2004. ALLE RECHTE VORBEHALTEN COPYRIGHT RESERVED BUNDESREPUBLIK DEUTSCHLAND 2004.

Mehr

Gesamtsystem. Version: A-Muster

Gesamtsystem. Version: A-Muster -Systementwurf: Systemarchitektur- Gesamtsystem Version: A-Muster Projektbezeichnung Artio Projektleiter Herr Karlapp Verantwortlich Herr Deynet Systemarchitekt Erstellt am Zuletzt geändert 10.08.2006

Mehr

Dokumentinformationen

Dokumentinformationen Dokumentinformationen Art des Dokuments Autoren Organisation Status Dr. Olaf Heimbürger Bundesamt für Kartographie und Geodäsie (BKG), Betrieb GDI-DE abgestimmt Version 1.0 erstellt am 16.02.2015 zuletzt

Mehr

Standardprojektvorgehen Projektidee. Formular: Projektidee

Standardprojektvorgehen Projektidee. Formular: Projektidee Prof. Dr.-Ing. Ulrich Samberg - FH Kiel - FB I+E - Institut für Angewandte Informatik Ereignis Org.- Einheit Syntax Datenbank Verknüpfungsoperatoren Standardprojektvorgehen Projektidee Funktion weiterführender

Mehr

Softwareentwicklung mit dem V-Modell XT. Erfahrungen, Einschätzungen, Empfehlungen

Softwareentwicklung mit dem V-Modell XT. Erfahrungen, Einschätzungen, Empfehlungen Softwareentwicklung mit dem V-Modell XT Erfahrungen, Einschätzungen, Empfehlungen Arne Schneikart - ZIVIT - 12.04.2006 Zentrum für Informationsverarbeitung und Informationstechnik Seit 1.1.2006: IT-Dienstleister

Mehr

Inhaltsverzeichnis. Seite 1 von 9

Inhaltsverzeichnis. Seite 1 von 9 Inhaltsverzeichnis Inhaltsverzeichnis... 1 1. Einführung... 2 1.1. Verwendungsarten... 2 1.2. Struktur des V-Modells... 3 2. Submodelle... 4 2.1. Projektmanagement (PM)... 4 2.2. Systemerstellung (SE)...

Mehr

- Prüfung - Prüfprotokoll für Anforderungen (Lastenheft)

- Prüfung - Prüfprotokoll für Anforderungen (Lastenheft) - Prüfung - Prüfprotokoll für Anforderungen (Lastenheft) Projektbezeichnung Projektleiter Verantwortlich WiBe 4.0 Beispielprojekt Odysseus pollon Erstellt am 11.03.2005 10:11 Zuletzt geändert 18.05.2005

Mehr

1 Phase «Initialisierung»

1 Phase «Initialisierung» 1.1 Übersicht Projektanmeldung Projektportfolio Projektrandbedingungen Projekt vorbereiten Projektantrag Projekthandbuch Projektplan Zurückweisung Projektauftrag Projektportfolio Status Abbruch Phase Voranalyse

Mehr

13 Anhang A: Erfüllung der Norm ISO 9000 durch HERMES

13 Anhang A: Erfüllung der Norm ISO 9000 durch HERMES 13 Anhang A: Erfüllung der Norm ISO 9000 durch Hinweis Einleitung Eine der wesentlichsten Grundlagen für die Qualitätssicherung in einem Unternehmen ist die Normenserie «ISO 9000», insbesondere ISO 9001:1994

Mehr

Informationssystemanalyse V-Modell 4 1

Informationssystemanalyse V-Modell 4 1 Informationssystemanalyse V-Modell 4 1 Das V-Modell Das V-Modell ist Bestandteil des Standardisierungskonzepts der Bundesbehörden. Dieses Konzept hat folgende Eigenschaften: Slide 1 verbindlich für IT-Vorhaben

Mehr

Das neue V-Modell XT. Methodik, Anwendung, Nutzen

Das neue V-Modell XT. Methodik, Anwendung, Nutzen Das neue V-Modell XT Methodik, Anwendung, Nutzen Wolfgang Kranz EADS Deutschland GmbH Defence Electronics 85716 Unterschleißheim Landshuterstr. 26 Tel. +49 89 3179-2786, Fax -2528 mobil: +49 172 8488200

Mehr

ISMS Teil 3 Der Startschuss

ISMS Teil 3 Der Startschuss ISMS Teil 3 Der Startschuss Nachdem das TOP-Managenment die grundsätzliche Entscheidung getroffen hat ein ISMS einzuführen, kann es nun endlich losgehen. Zu Beginn sollte Sie noch die Grundlagen des ISMS

Mehr

Richtlinie für Verfahren für interne Datenschutz-Audits

Richtlinie für Verfahren für interne Datenschutz-Audits Richtlinie für Verfahren für interne Datenschutz-Audits Freigabedatum: Freigebender: Version: Referenz: Klassifikation: [Freigabedatum] Leitung 1.0 DSMS 01-01-R-05 Inhaltsverzeichnis 1 Ziel... 2 2 Anwendungsbereich...

Mehr

Übungen Softwaretechnik I

Übungen Softwaretechnik I Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich Übungen Softwaretechnik I Übung 2: Vorgehensmodelle IAS-Vorgehensmodell Motivation Probleme Die

Mehr

Changemanagement in Projekten. Björn Thiée

Changemanagement in Projekten. Björn Thiée Changemanagement in Projekten Björn Thiée Agenda Blickwinkel auf das Change-Management Definition von Change-Management Der Prozess des Change-Managements Organisation des Change-Managements Fazit / Zusammenfassung

Mehr

V-Modell XT. Teil 2: Eine Tour durch das V-Modell

V-Modell XT. Teil 2: Eine Tour durch das V-Modell V-Modell XT Teil 2: Eine Tour durch das V-Modell DAS V-MODELL XT IST URHEBERRECHTLICH GESCHÜTZT. BUNDESREPUBLIK DEUTSCHLAND 2004. ALLE RECHTE VORBEHALTEN COPYRIGHT RESERVED BUNDESREPUBLIK DEUTSCHLAND 2004.

Mehr

Handbuch Schulungsdatenbank

Handbuch Schulungsdatenbank Handbuch Schulungsdatenbank Inhaltsverzeichnis Hinweise... 3 Überblick... 4 Themen... 5 Schulungsprogramm Verwalten... 6 Details... 7 Schulungsprogramm bearbeiten... 9 Anstehende Termine... 10 Schulungen

Mehr

SWE KEx-Datex II. System-Architektur

SWE KEx-Datex II. System-Architektur Seite: 1 von 10 SWE Version 3.0 Stand 16.02.2015 Produktzustand Datei Vorgelegt SysArc_KExDatex_FREI_V3.0_D2015-02-16.docx Projektleiter Projektträger Herr Stock Strassen.nrw Verantwortlich Ansprechpartner

Mehr

17 Überblick über die restlichen Vorgehensbausteine

17 Überblick über die restlichen Vorgehensbausteine Bundesamt für Informationsmanagement und Informationstechnik der Bundeswehr 17 Überblick über die restlichen Vorgehensbausteine V-Modell XT Anwendung im Projekt

Mehr

Das neue V-Modell XT. Methodik, Anwendung, Nutzen

Das neue V-Modell XT. Methodik, Anwendung, Nutzen Das neue V-Modell XT Methodik, Anwendung, Nutzen Wolfgang Kranz EADS Deutschland GmbH Defence Electronics 85716 Unterschleißheim Landshuterstr. 26 Tel. +49 89 3179-2786, Fax -2528 mobil: +49 172 8488200

Mehr

Verfahrensgrundlage Vergabe von Registrierungskennzahlen für Informationsobjekte

Verfahrensgrundlage Vergabe von Registrierungskennzahlen für Informationsobjekte Verfahrensgrundlage Vergabe von Registrierungskennzahlen für Informationsobjekte März 2006 Version 1.0 Inhaltsverzeichnis 1 Anwendungsbereich... 3 2 Ziel und Zweck des Registers... 3 3 Mitteilungspflicht

Mehr

Wie die in-step BLUE SPICE Edition for Automotive Ihre Organisation unterstützt, SPICE Level 3 zu erreichen

Wie die in-step BLUE SPICE Edition for Automotive Ihre Organisation unterstützt, SPICE Level 3 zu erreichen Wie die in-step BLUE SPICE Edition for Automotive Ihre Organisation unterstützt, SPICE Level 3 zu erreichen microtool GmbH Inhalte Wie die in-step BLUE SPICE Edition for Automotive Ihre Organisation unterstützt,

Mehr

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/

Mehr

Hochschule für Technik und Architektur Biel. Projekthandbuch.doc. Für Projekt Polyphemus II. Matthias Germann

Hochschule für Technik und Architektur Biel. Projekthandbuch.doc. Für Projekt Polyphemus II. Matthias Germann Hochschule für Technik und Architektur Biel Für Projekt Polyphemus II Dateiname: Revisionsstatus: Autor:.doc Genehmigt Roger Briggen Matthias Germann Änderungskontrolle Version Datum Name Bemerkungen 1

Mehr

Kosten- oder Nutzenfaktor?

Kosten- oder Nutzenfaktor? Projektmanagement im Mittelstand Kosten- oder Nutzenfaktor? Dipl.-Ing. Willi Wurl Rosenstraße 39 D-71543 Wüstenrot Prozess- & Projektmanagement 11. April 2006 0 Einleitung Situation in mittelständischen

Mehr

Muster Nachweisdokumentation und Sicherheitsbewertungsbericht

Muster Nachweisdokumentation und Sicherheitsbewertungsbericht Muster Nachweisdokumentation und Sicherheitsbewertungsbericht auf Basis der "Verordnung (EG) Nr. 352/2009 der Kommission vom 24. April 2009 über die Festlegung einer gemeinsamen Sicherheitsmethode für

Mehr

Projektarbeit Fit für Ausbildung und Beruf

Projektarbeit Fit für Ausbildung und Beruf Projektarbeit Fit für Ausbildung und Beruf Inhalt 1 Einleitung 2 Projektarbeit 2.1 Projektteam 2.2 Projektphasen 2.2.1 Definition 2.2.2 Planung 2.2.3 Durchführung 2.2.4 Abschluss 2.3 Dokumentation 2.4

Mehr

Anleitung fu r die Vorlage restpunkte.xlsx

Anleitung fu r die Vorlage restpunkte.xlsx Anleitung fu r die Vorlage restpunkte.xlsx Inhalt 1 Einleitung... 1 2 Grundsätzliche Bedienungshinweise... 1 3 Wichtige Regeln für das Ausfüllen... 2 4 Erfassen der Information... 2 4.1 Das Blatt Inspektionen...

Mehr

Testfragen PRINCE2 Foundation

Testfragen PRINCE2 Foundation Testfragen PRINCE2 Foundation Multiple Choice Prüfungsdauer: 20 Minuten Hinweise zur Prüfung 1. Sie sollten versuchen, alle 25 Fragen zu beantworten. 2. Zur Beantwortung der Fragen stehen Ihnen 20 Minuten

Mehr

Abb.: Darstellung der Problemfelder der Heine GmbH

Abb.: Darstellung der Problemfelder der Heine GmbH Entwicklung eines SOLL-Konzeptes Kehl Olga 16.05.10 Wie aus der Ist-Analyse ersichtlich wurde, bedarf die Vorgehensweise bei der Abwicklung von Projekten an Verbesserung. Nach der durchgeführten Analyse

Mehr

Erstellung von Prozessbeschreibungen. PB 4.2-1: Erstellung von Prozessbeschreibungen

Erstellung von Prozessbeschreibungen. PB 4.2-1: Erstellung von Prozessbeschreibungen Seite 1 von 9 PB 4.2-1: Erstellung von Prozessbeschreibungen 1 Ziel und Zweck Durch Prozessbeschreibungen werden die einzelnen Prozesse des Qualitätshandbuchs detaillierter beschrieben. Sie werden für

Mehr

Workshop. Projektmanagement für Schülerfirmen. Dozentin: Ramona Hasenfratz, Dozentin der IHK Schwarzwald-Baar-Heuberg

Workshop. Projektmanagement für Schülerfirmen. Dozentin: Ramona Hasenfratz, Dozentin der IHK Schwarzwald-Baar-Heuberg Schüler- und Juniorfirmen Beratungsstelle c/o IHK Schwarzwald-Baar-Heuberg Romäusring 4 78050 Villingen-Schwenningen Melanie John Fon: 07721 / 922-206 Fax: 07721 / 922-182 E-Mail: john@villingen-schwenningen.ihk.de

Mehr

Historie des Arbeitskreises

Historie des Arbeitskreises Requirements Engineering & Projektmanagement Arbeitskreis-Bericht Andrea Herrmann Ralf Fahney Rüdiger Weißbach Christian Rückert Historie des Arbeitskreises Erste Idee: voriges Jahr auf dem FG-Treffen

Mehr

Elektronische Unterschriften mit Adobe Acrobat 9. Version 1.0 14. April 2009

Elektronische Unterschriften mit Adobe Acrobat 9. Version 1.0 14. April 2009 Version 1.0 14. April 2009 Einleitung Diese Anleitung beschreibt in Kurzform wie (Standard, Pro und Pro Extended) PDF Dokumente signiert oder zertifiziert respektive die Signatur(en) geprüft werden können.

Mehr

Prüfungsfragen (HSPTP) MC - Fragen

Prüfungsfragen (HSPTP) MC - Fragen Prüfungsfragen (HSPTP) MC - Fragen Public V 2.0 1. Privatadresse Anrede Herr Frau Titel Vorname Name Strasse / Nr. PLZ / Ort E-Mail Privat Geburtsdatum Heimatort Datum Unterschrift Hilfsmittel Folgende

Mehr

Von Menschen mit Mäusen Wohin führt das Projektmanagement

Von Menschen mit Mäusen Wohin führt das Projektmanagement Von Menschen mit Mäusen Wohin führt das Projektmanagement H. Sandmayr 10. SW-Werkstatt Thun 28. Oktober 1999 28.10.1999/sa 10. SWWS Thun 1999 1 Zum Inhalt Versuch einer Standortbestimmung (als Basis für

Mehr

4 Einführung in die Gruppenarbeit Produktstruktur

4 Einführung in die Gruppenarbeit Produktstruktur Bundesamt für Informationsmanagement und Informationstechnik der Bundeswehr 4 Einführung in die Gruppenarbeit Produktstruktur V-Modell XT Anwendung im Projekt

Mehr

Projekt kontrollieren. Projekt steuern

Projekt kontrollieren. Projekt steuern Projekt vorbereiten Projektmanagement Projekt starten Projekt organisieren Projekt planen Projekt kontrollieren Projekt steuern Projekt beenden 1 Projekt kontrollieren Das Projektmanagement hat die Aufgabe

Mehr

Leitfaden zum sicheren Betrieb von Smart Meter Gateways

Leitfaden zum sicheren Betrieb von Smart Meter Gateways Leitfaden zum sicheren Betrieb von Smart Meter Gateways Wer Smart Meter Gateways verwaltet, muss die IT-Sicherheit seiner dafür eingesetzten Infrastruktur nachweisen. Diesen Nachweis erbringt ein Gateway-

Mehr

V-Modell XT meets Scrum:

V-Modell XT meets Scrum: V-Modell XT meets Scrum: Ein Erfahrungsbericht bei einer öffentlichen Ausschreibung VMEA Nov 2015 Siegburg Speaker: Markus Reinhold CoCOO info@cocoo.de - www.cocoo.de twitter: @cocoo_mr VM XT + SCRUM 1

Mehr

Gemeinsame Projektbearbeitung mit Project Professional und Project Web Access

Gemeinsame Projektbearbeitung mit Project Professional und Project Web Access Gemeinsame Projektbearbeitung mit Project Professional und Project Web Access Gemeinsame Projektbearbeitung mit Project Professional und Project Web Access Projektteam Führungskraft Portfolio Management

Mehr

KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 1/13. Dokumentation KREDITVERZEICHNIS. Teil 2. Konfiguration

KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 1/13. Dokumentation KREDITVERZEICHNIS. Teil 2. Konfiguration KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 1/13 Dokumentation KREDITVERZEICHNIS Teil 2 Konfiguration Stand 20.02.2013 KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 2/13 Inhalt 1. KONFIGURATION...

Mehr

Projektmanagement. Leitfaden. (Kurzfassung) OEC GmbH Vogelbergstraße 20 D-86441 Zusmarshausen

Projektmanagement. Leitfaden. (Kurzfassung) OEC GmbH Vogelbergstraße 20 D-86441 Zusmarshausen Projektmanagement Leitfaden (Kurzfassung) Inhaltsangabe Projektmanagementleitfadens Seitenzahl 1. Zweck und Ziel des Leitfadens 1 2. Geltungsbereich 1 3. Aufbau der Leitfadens 1 4. Projektorganisation

Mehr

V-Modell XT. Teil 9: Vorlagen

V-Modell XT. Teil 9: Vorlagen Teil 9: Vorlagen V-Modell ist eine geschützte Marke der Bundesrepublik Deutschland. Inhaltsverzeichnis 9-1 Inhaltsverzeichnis 1 Einleitung... 9-3 1.1 Zielsetzung des Vorlagen-Teiles...9-3 1.2 Zielgruppe

Mehr

Anwender- Dokumentation. REP Datenbank Wartungsprogramme. Version 320-23.00 Version 280-23.00

Anwender- Dokumentation. REP Datenbank Wartungsprogramme. Version 320-23.00 Version 280-23.00 Anwender- Dokumentation REP Datenbank Wartungsprogramme Version 320-23.00 Version 280-23.00 Allgemein Die Abkürzung REP steht in der Renault Informatik für den Begriff Référentiel Entretiens Programmés,

Mehr

CRM-Komplettpaket zum Fixpreis

CRM-Komplettpaket zum Fixpreis Richtig informiert. Jederzeit und überall. CRM-Komplettpaket zum Fixpreis Leistungsbeschreibung CAS Software AG, Wilhelm-Schickard-Str. 8-12, 76131 Karlsruhe, www.cas.de Copyright Die hier enthaltenen

Mehr

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management Anforderungsmanagement im Projekt BIS-BY von B. KREUZER Schlüsselwörter: Änderungswünsche, Anforderungsmanagement, DOORS Kurzfassung Softwaresysteme unterliegen während ihrer Entwicklung und während ihres

Mehr

Requirements Management für SAP Solution Manager Projektrisiken minimieren durch professionelles Anforderungsmanagement

Requirements Management für SAP Solution Manager Projektrisiken minimieren durch professionelles Anforderungsmanagement Requirements Management für SAP Solution Manager Projektrisiken minimieren durch professionelles Anforderungsmanagement SAP Consulting Use this title slide only with an image Agenda Risikofaktoren beim

Mehr

MS Project Professional 2007. mit Project Server 2007. und Portfolio Manager 2007

MS Project Professional 2007. mit Project Server 2007. und Portfolio Manager 2007 Unternehmensweites Enterprise Project Projektmanagement Management MS Project Professional 2007 mit Project Server 2007 und Portfolio Manager 2007 Quelle: Microsoft Seite 1 von 8 Projektmanagement mit

Mehr

Übersicht Kompakt-Audits Vom 01.05.2005

Übersicht Kompakt-Audits Vom 01.05.2005 Übersicht Kompakt-Audits Vom 01.05.2005 Bernhard Starke GmbH Kohlenstraße 49-51 34121 Kassel Tel: 0561/2007-452 Fax: 0561/2007-400 www.starke.de email: info@starke.de Kompakt-Audits 1/7 Inhaltsverzeichnis

Mehr

Requirements-Management Ein praktisches Beispiel

Requirements-Management Ein praktisches Beispiel 2003 Eurocopter Deutschland GmbH 2003 Requirements-Management Ein praktisches Beispiel a.s.drexler@t-online.de Softwareprozesse in Luft- und Raumfahrtprojekten Workshop der DGLR am 15.10.2003 Der Vortrag

Mehr

V-Modell XT. Teil 2: V-Modell-Tour

V-Modell XT. Teil 2: V-Modell-Tour V-Modell XT Teil 2: V-Modell-Tour c BUNDESREPUBLIK DEUTSCHLAND, 2004, ALLE RECHTE VORBEHALTEN. V-MODELL R IST EI- NE GESCHÜTZTE MARKE DER BUNDESREPUBLIK DEUTSCHLAND. DIESES WERK IST URHEBERRECHTLICH GESCHÜTZT.

Mehr

IT-Grundschutzhandbuch: Stand Juli 1999 1

IT-Grundschutzhandbuch: Stand Juli 1999 1 1. Information Security Policy 1.1. Einleitung Die Firma/Behörde ist von Informationen abhängig. Informationen entscheiden über unseren Erfolg und den unserer Kunden. Von größter Wichtigkeit ist neben

Mehr

Software Projekt 2 / Gruppe Knauth Lernziele:

Software Projekt 2 / Gruppe Knauth Lernziele: Lernziele: Realisierung eines komplexen Software-Projektes unter Industrie-ähnlichen Bedingungen Organisiertes Arbeiten im Team Team Organisation: Rollen und Aufgaben der Team-Mitglieder bestimmen Spezifikation

Mehr

V-Modell XT. Teil 1: Grundlagen des V-Modells

V-Modell XT. Teil 1: Grundlagen des V-Modells V-Modell XT Teil 1: Grundlagen des V-Modells DAS V-MODELL XT IST URHEBERRECHTLICH GESCHÜTZT. BUNDESREPUBLIK DEUTSCHLAND 2004. ALLE RECHTE VORBEHALTEN COPYRIGHT RESERVED BUNDESREPUBLIK DEUTSCHLAND 2004.

Mehr

Dokuart 05-03(-a)(-b) Dokubeschreibung

Dokuart 05-03(-a)(-b) Dokubeschreibung 1 Ziel und Zweck Diese Anweisung soll sicherstellen, dass die benötigten Dokumente und Daten (Doku s) zur Verfügung stehen. Die Anweisung regelt folgende Punkte: Identifikation und Rückverfolgbarkeit Änderung

Mehr

PROJEKTNAVIGATOR - effektives und effizientes Steuern von Projekten -

PROJEKTNAVIGATOR - effektives und effizientes Steuern von Projekten - PROJEKTNAVIGATOR - effektives und effizientes Steuern von Projekten - Stand: Mai 2013 KLAUS PETERSEN Was ist der Projektnavigator? Der Projektnavigator ist ein wikibasierter Leitfaden zur einheitlichen

Mehr

Einführung in das Projektmanagement

Einführung in das Projektmanagement Einführung in das Projektmanagement Warum Projektmanagement? Projekte bergen Risiken Förderung von Zusammenarbeit Verbesserung von Informationsfluss und austausch Planung unter Berücksichtigung von Ressourcen

Mehr

Maintenance & Re-Zertifizierung

Maintenance & Re-Zertifizierung Zertifizierung nach Technischen Richtlinien Maintenance & Re-Zertifizierung Version 1.2 vom 15.06.2009 Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 22899 9582-0

Mehr

Werkzeugunterstützung mit V-Modell XT Projektassistent und V-Modell XT Editor

Werkzeugunterstützung mit V-Modell XT Projektassistent und V-Modell XT Editor Das neue Werkzeugunterstützung mit Projektassistent und Editor Dr. Marc Sihling 4Soft GmbH Motivation Generelle Zielsetzung Die Verfügbarkeit bedarfsgerechter Werkzeuge hilft bei Einarbeitung, Auseinandersetzung

Mehr

Lenkung von Dokumenten

Lenkung von Dokumenten Beispiel Verfahrensanweisung Dok.-Nr. 1.8.2 Lenkung von Dokumenten Revision 0 erstellt am 11.02.2010 Seite 1 von 5 Ziel und Zweck: In den betrieblichen Vorgabedokumenten werden Handlungs- oder Verhaltensweisen

Mehr

Projektdokumentation

Projektdokumentation Projektdokumentation Erneuerung der LAN-Infrastruktur bei einem öffentlichen Auftraggeber Certified IT Business Manager Abgabedatum: 31.03.2015 Autor: IHK Prüflingsnummer: (anonym) (anonym) (anonym) Prüflingsnummer:

Mehr

Inhalt Einleitung 2 Anmeldung 3 Oberfläche und Bedienung Bearbeitungsablauf 12

Inhalt Einleitung 2 Anmeldung 3 Oberfläche und Bedienung Bearbeitungsablauf 12 Inhalt Einleitung 2 Anmeldung 3 Neues Konto anmelden 3 Passwort vergessen? 4 Oberfläche und Bedienung 5 Projektbereiche 5 Startseite 6 Übersicht 6 Probleme anzeigen 7 Probleme eingeben 10 Änderungsprotokoll

Mehr

Datensicherung. mit. Ocster Backup Pro. www.it-kroeger.de. it.kröger 27.08.2014. Hinweis:

Datensicherung. mit. Ocster Backup Pro. www.it-kroeger.de. it.kröger 27.08.2014. Hinweis: Datensicherung mit Ocster Backup Pro it.kröger 27.08.2014 Hinweis: Die Beschreibung wurde mit größter Sorgfalt erarbeitet. Dennoch können Fehler nicht ausgeschlossen werden. it.kröger haftet nicht für

Mehr