1 / 60

II Das Unternehmen als Kontext der Projektabwicklung

II Das Unternehmen als Kontext der Projektabwicklung. Produktionsfaktor: Information (vgl. Systemwürfel) soll in geeigneter Form entsprechend definierter Vorgaben bzgl. Ort, Zeitpunkt, Menge bereitgestellt werden. diesem Zweck dient das Informationssystem

kelly-montoya
Download Presentation

II Das Unternehmen als Kontext der Projektabwicklung

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. II Das Unternehmen als Kontext der Projektabwicklung • Produktionsfaktor: Information (vgl. Systemwürfel) soll in geeigneter Form entsprechend definierter Vorgaben bzgl. Ort, Zeitpunkt, Menge bereitgestellt werden. • diesem Zweck dient das Informationssystem • Ziel eines Informationssystems ist es, die- in einem Unternehmen vorhandenen Informationen,- in einem Unternehmen nachgefragten Informationen- für ein Unternehmen notwendigen Informationenauf den Arbeitsprozess so abzustimmen, dass damit die bestmögliche Leistung erbracht werden kann

  2. Informationssystem-Management • Das ISM erstreckt sich auf die Entwicklung und den Betrieb der Informationssysteme von Unternehmen • Zwei gegensätzliche Anforderungen müssen ausgewogen werden: • Entwickler und Anwenden sollen möglichst wenig einschränkt werden, um neue Applikationen rasch und kreativ einführen/erstellen zu können. • Entwickler und Anwendungen müssen so koordiniert werden, daß Doppelarbeit, Insellösungen, umständliche Abläufe vermieden werden, damit das IS längerfristig entwicklungsfähig bleibt und das IS mit der Geschäftsstrategie zusammenpaßt.

  3. Informationssystem-Management (Jenny, Abb. 1.17, S. 19)

  4. Stufe: IS-Konzept (Jenny, Abb.1.19, S.22) Das IS-Konzept ist durch die Informationsstrategie selbst Teil der Unternehmensstrategie. Es muss daher mit den anderen Bereichsstrategien (Markt-, Produkt-, ...) in Einklang stehen.

  5. Stufe: IS-Konzept • Das IS-Konzept enthält Normen, wie: • Leitbild und resultierende Erfolgsfaktoren • Grundsätze • Standards und Richtlinien • Das IS-Konzept enthält Beschreibungen von Vorgehen und verantwortlichen Stellen, wie: • Projektmanagement • IS-Organisation • Methoden der Systementwicklung • Prinzipien des IS-Controlling

  6. Stufe: IS-Architektur • Einheitliche Architektur ist erforderlich, da i.a. viele interne und externe Partner an der Entwicklung eines IS beteiligt sind. • Eine integrierte IS-Architektur ermöglicht die gemeinsame Nutzung von Informationen mittels Unterstützung verschiedener Anwendungen. • Umfassende, Informatik-orientierte Gesamtkonzepte für Unternehmen können realisiert werden. (nach Jenny, Abb. 1.19, S. 22)

  7. Stufe: IS-Architektur - Komponenten • IS-Architektur umfaßt: • Datenmodell: konzeptuelles Modellist implementierungsunabhängig, daher flexibel • Prozeßmodell: erfaßt alle Geschäftsabläufe;vorteilhaft: top down und bottom up Erfassung • Systemmodell: Gliederung von Geschäftsfällen entsprechend der Konsumation/Erzeugung gleicher Datenklassen; daraus: Ableitung von Subsystemen ;Subsysteme entsprechen oft Geschäftsbereichen wie Produktion, Vertrieb, etc. . • Gerätemodell (siehe PRI I)

  8. Stufe: IS-Architektur Daten- und Prozessmodell • bei Anwendung eines objekt-orientierten (OO) Ansatzes sind Daten- und Prozessmodell eng verknüpft • Beispiel: Klassendiagramme und Use-Case-Diagramme im UPKlassenmodell (d.h. Daten wie auch die darauf definierten Operationen) wird aus der Modellierung von Use-Cases (Geschäftsfällen) abgeleitet. grobe Vorgehensskizze: • Identifikation und nat.spr. Beschreibung von Use-Cases • zunächst Normalabläufe, dann seltenere (Ausnahme)Fälle • Hierarchische Anordnung von Use-Cases • Ableitung des Klassenmodells

  9. Stufe: IS-Architektur Daten- und Prozessmodellbeispiel

  10. Stufe: IS-Architektur Daten- und Prozessmodellbeispiel

  11. IS-Projektportfolio • globales Ziel des IS-Projektportfolios:Initialisierung des richtigen Projektes mit den erforderlichen Ressourcen zur richtigen Zeit im richtigen Unternehmens-bereich. • die für eine Aufnahme ins IS-Projektportfolio gestellten Bedingungen werden i.a. nach individuellen Unternehmenskriterien festgelegt.Unterschiedliche Vorhaben können so verglichen und priorisiert werden, damit die (möglichst objektiv!) wichtigsten Vorhaben realisiert werden können.

  12. IS-Projektportfolio • Aufgabe des IS-Projektportfolios ist es, aufzuzeigen: • welche Projekte durchzuführen sind, • wann mit welchen Projekten begonnen werden kann, • wann ein Projekt abgeschlossen sein muß, • welche Projekte parallel bzw. sequentiell realisiert werden sollen, • wie lange das gesamte Realisierungsvorhaben dauert, • wie hoch der (jährliche) Realisierungsaufwand ist.

  13. IS-Projektportfolio - Ablauf • 1. IS-AntragAufnahmekanäle:IS-Architektur oder Fachabteilungen: intern oder extern produzierte Bedürfnisse • 2. Bewertung • 3. Machbarkeitsstudie • 4. Entwicklungsplanung • 5. Projektfreigabe:Entwicklung auf der IS-Projektebene • 6. IS-Entwicklungskontrolle:via Kontrollgrößen wird der Bezug zur Planung koordiniert

  14. IS-ProjektportfolioAblauf: Antrag - Bewertung • Zwecks fachgerechter Prüfung/Bewertung der IS-Anträge, sollten darin folgende Projektmerkmale festgelegt sein: • Projektumfang und Projektdauer • Projektspezialitäten, z.B. Innovationsgrad, spezielle Infrastruktur, spezielle Methoden/Vertragsbedingungen,… • Projektbedeutung: Stellenwert gegenüber der Konkurrenz, strategische/finanzielle Gewichtung, Prestigeobjekt,… • Projektkomplexität: grobe Schätzung durch Einflußgrößen:- Anzahl der betroffenen Organisationseinheiten: gegenseitige Abhängigkeiten, Querverbindungen- Bereich der starken Veränderung: bzgl. Daten - Geschäftsfällen- Bereich der Methoden- und Toolwahl

  15. IS-ProjektportfolioAblauf: Antrag - Bewertung • Projektkosten:Entwicklungs-, Management-, Produktinvestitionskosten • Projektrisiken: möglicher Schaden für das Unternehmen, falls die Projektziele nicht erreicht werden • Projektintensität:Ausmaß der Auslastung der Mitarbeiter während der Dauer des Projektes • Projektart:Unterstützungs-, Entwicklungs-, Organisationsprojekte

  16. IS-ProjektportfolioAblauf: Machbarkeitsstudie • Ziel der Machbarkeitsstudie: Beurteilung der Durchführbarkeit und Wirtschaftlichkeit eines Projektes • Aufwand: max. 3 Personenmonate, Dauer < 2 Monate • Ergebnis: Management-Summary mit folgenden Themen:- Ausgangslage- Ziele und Lösungsansätze- Wirtschaftlichkeitsanalyse- Risikoanalyse- Projektorganisation- Projektgesamtplanung- Aufgliederung in Teilprojekte- Erweiterter IS-Antrag

  17. IS-ProjektportfolioAblauf: IS-Entwicklungsplanung • Ziel der Entwicklungsplanung: Festlegen der Reihenfolge der Projekte und Zuordnung der Ressourcen für die Realisierung der Projekte • Entwicklungsplan: Erstellung durch Gremium mit gutem IS-Architektur Wissen und Managementkompetenz • Schritte : • Ermittlung der unternehmerischen ReihenfolgeKriterien: Unternehmensziele, Wirtschaftlichkeit • Ermittlung der betrieblichen Reihenfolge

  18. IS-ProjektportfolioAblauf: IS-Entwicklungsplanung Kriterien: Wichtigkeit/Dringlichkeit, zur Verfügung stehende Ressourcen, betriebswirtschaftlicher Aufbau der IS-Architektur • Aufstellung des applikatorischen Migrationsplans: Kompromiß; enthält die Realisierungsreihenfolge der Projekte • Personal- und Finanzplanung • Risikoanalyse der Projektanträge:Hauptproblem: “Was könnte während der Projektabwicklung mit welcher Wahrscheinlichkeit passieren und welches wären die Folgen dieser Ereignisse”.

  19. IS-ProjektportfolioAblauf: Entwicklungsplanung Beispiel einer Tabelle zur unternehmerischen Reihenfolge der Projekte: (Jenny Abb. 1.25, S. 35)

  20. IS-ProjektportfolioAblauf: Entwicklungsplanung Beispiel eines applikatorischen Migrationsplans (Jenny Abb. 1.29, S. 38)

  21. IS-ProjektportfolioAblauf: Entwicklungsplanung Beispiel eines Portfolio-Personalplans (Jenny Abb. 1.28, S. 37)

  22. IS-ProjektportfolioAblauf: Entwicklungsplanung Beispiel eines Portfolio-Finanzplans (Jenny Abb. 1.28, S. 37)

  23. IS-ProjektportfolioAblauf: Entwicklungskontrolle • Aufgaben: • Planungskontrolle: Kosten/Aufwand und Termine werden mit den Planungsvorhaben des Portfolios verglichen • Projekt-Sachfortschrittskontrolle:SOLL-Vorgaben des IS-Projektportfolios werden mit den IST-Zuständen (z.B. aus Phasenabschlußberichten) verglichen • Kontrolle des IS-Entwicklungsplans: alle Resultate der IST-SOLL-Vergleiche der laufenden Projekte bilden zusammengefaßt den “Statusbericht zur Umsetzung des IS-Entwicklungsplans”; Rückkopplung in das Projektportfolio • Projekt-Nachkontrolle: direkter IST-SOLL-Vergleich bzgl.:Entwicklungskosten, Wirtschaftlichkeit, Projektdauer.

  24. Informationssystem-Projekt Projektebene der IS-Pyramide: IS-Projekte werden gemäß dem IS-Entwicklungsplan zusammengestellt. (Jenny, Abb.1.32, S.43)

  25. Informationssystem-Projekt Komponenten der Projektabwicklung im IS-Projektbereich (Jenny, Abb. 1.33, S.44)

  26. Informationssystem-ProjektStandards und Richtlinien der Informatik-Abteilung • Quellen1) IS-Architektur: Hardware, zentrale SW, Konzeption,…;Ausrichtung auf Daten-, Prozeß-, Systemmodell2) Organisationshandbuch: - wird auf die Informatik-Abteilung spezialisiert;- enthält betriebliche Regelungen und Vorschriften als Umsetzung des Leitbildes des Unternehmens • Leitbild: umfasst • Unternehmensgrundsätze: Verhalten der Unternehmung gegenüber Umwelt, Kunden, Staat, etc. • Führungsgrundsätze: Verhalten von Vorgesetzten zu Untergebenen (wird hier nicht behandelt)

  27. Informationssystem-Projekt Gliederung des Standards und Richtlinien Handbuches: (Jenny, Abb. 1.35, S. 47)

  28. Informationssystem-ProjektRichtlinien für die Projektabwicklung • Projekthandbuch (PHB): beinhaltet organisatorische Regelungen für die Projektorganisation und -durchführungPHB ist ggf. Teil des S&R Handbuches • Ziele: • Grundlagen der Abwicklungsziele festlegen • Arbeitsweise im Projekt festlegen • Verbindliche Richtlinie für die Zusammenarbeit • Zuweisung von Aufgaben, Kompetenzen und Verantwortungen an beteiligte Stellen • Festlegung der Projektorganisation

  29. Informationssystem-ProjektRichtlinien für die Projektabwicklung • Grundlage zur Erteilung detaillierter Aufträge im Rahmen des Projektes • Unterstützung bei der Erstellung und Ausarbeitung notwendiger Verträge • Festlegung des obligatorischen Outputs der aus den im PHB angeführten Tätigkeiten • Kommentar: es ist sehr wichtig, daß die Richtlinien für die Projektabwicklung offen gehalten werden, um das Projekt-team nicht zu behindern, sondern zu unterstützen. dazu dient: • Tailoring: Mit dem Tailoring werden die nichtrelevanten Tätigkeiten, die im PHB angeführt sind, gestrichen. Damit wird gewährleistet, daß der Aufwand für jedes Projekt situationsgerecht ist.

  30. Informationssystem-ProjektRichtlinien für die Projektabwicklung Metamodell eines Projekthandbuches: (Jenny, Abb1.36, S. 49)

  31. Informationssystem-ProjektGliederungsschema für ein Projekthandbuch • Key-PHB Übergreifende Standards, Organisationsübersichten und Projektqualifikationswerte etc. werden im Key-PHB aufgeführt. • Literaturverzeichnis, Glossar, Definitionen Den Benutzer unterstützende Schriften sind in diesem Modul aufgeführt, so dass er diese in der Bibliothek einfach finden kann. Auch das Glossar und die Definitionen werden in dem Grad aufgebührt, dass es für den Anwender unterstützend ist. • Projektmanagement Das Modul Projektmanagement enthält die allgemeingültigen Projektleiter-Aufgaben sowie die Vorgaben des Problem- und Änderungsmanagements, des Konfigurationsmanagements, des Risikomanagements sowie des Qualitätsmanagements.

  32. Vorgehensmethode Hier werden die in einer Firma angewandten Vorgehensmodelle und ihre Anwendungsberechtigungen erläutert. Projektorganisation Hier werden die Gremien (Stellen und Instanzen) und Organisationsformen, die innerhalb einer Firma für ein Projekt gebildet werden müssen oder können, aufgeführt. Im weiteren können weitere zusätzliche institutionelle Werte (z.B. Informationssystem etc.) aufgeführt werden, die in den Projekten ihre Anwendung finden. Dokumentation Hier werden alle notwendigen Vorgaben (Schlüsselwerte, Strukturen etc.) bezüglich der zu erstellenden Dokumentation aufgefiihrt. So auch die Strukturen der externen Projektsicht, z.B. Verträge, Pflichtenhefte etc. Informationssystem-ProjektGliederungsschema für ein Projekthandbuch

  33. Phasenmodell und Problemlösungszyklus Hier werden alle Tätigkeiten und Ergebnisse, die in einer Phase oder in einem Phasenzyklus durchgefiihrt respektive erstellt werden können, aufgeführt. Qualitätssicherungssystem In diesem Modul sind die Vorgaben bezüglich des gewünschten Qualitätsstandards aufgeführt. Checklisten In diesem Modul werden Checklisten definiert, die bei einem Review oder Audit von Ergebnissen zur Anwendung gelangen. Methoden/Techniken Hier werden die Methoden/Techniken beschrieben, die in einem Projekt zur Anwendung gelangen sollen. Instrumente/Tools Abgestimmt auf die Methoden erfolgen hier Beschreibungen über die einzusetzenden Tools. Informationssystem-ProjektGliederungsschema für ein Projekthandbuch

  34. Informationssystem-ProjektGliederungsschema für ein Projekthandbuch Musterergebnisse Aufgrund von Aktivitäten und dem Ergebnismodell aus dem Modul "Phasenmodell" werden hier Musterergebnisse als Richtgrössen aufgeführt. Organisationsentwicklungskonzept Insbesondere bei Informatikprojekten ist es wichtig, daß das Organisationsentwicklungskonzept mit berücksichtigt wird. Das heißt, daß neben den funktionalen auch die sozio-psychologischen Veränderungen zum richtigen Zeitpunkt vorgenommen werden sollten. Konfigurationsmanagement Um sicherzustellen, daß ein Produkt bezüglich seiner funktionellen wie auch seiner äußeren Merkmale eindeutig identifizierbar ist, wird das Konfigurationsmanagement im PHB ausführlich beschrieben. Innerhalb des Konfigurationsmanagements muß auch das Change-/Änderungsmanagement beschrieben werden.

  35. Informationssystem-ProjektProjektabwicklung Gliederung des Projektmanagements: (Jenny, Abb. 1.40, S. 62)

  36. Informationssystem-ProjektProjektabwicklung Projektdurchführung: Vorgehensmodelle, Lebenszyklus-Modelle Vorgehensmodelle, Lebenszyklus-Modelle ProjektphasenProblemlösungszyklus Projektdurchführungstechniken, z.B.:Requirements Engineering, UML, Risikoanalyse, Entscheidungsbaum, ...

  37. IS-ProjektVorgehensmodelle, SW-Lebenszyklus • verschiedene Vorgehensmodelle zur Entwicklung/Wartung von Software • SW-Lebenszyklus: beschreibt die Phasen, die ein SW-Projekt “durchlebt”; • jede Phase ist mit spezifischen Aktivitäten sowie der Erstellung/Ergänzung vordefinierter Dokumente verbunden; • die Vorphasen: Zielanalyse und Planung sind nicht in allen Modellen berücksichtigt

  38. IS-ProjektVorgehensmodelle, SW-Lebenszyklus • Überblick über Lebenszyklus-Modelle: • reines Wasserfallmodell und Wasserfallmodell mit Rückkopplung/Validierung • Wasserfallmodell mit “Rapid Prototyping” in Analysephase • evolutionäres/inkrementelles Vorgehensmodell • exploratory Programming • operationales Modell mit formalen Transformationen:formale Anforderungsspezifikation wird schrittweise durch automatisations-unterstützte Transformationen in ein exkutierbares Programm übergeführt • Spiralenmodell

  39. IS-Projektdas “Wasserfall-Modell” • Wasserfallmodell [Boehm, 1981]mit Rückkopplung

  40. IS-Projektdas “Wasserfall-Modell” • Charakteristika des Wasserfallmodells: • Phasen werden strikt sequentiell abgearbeitet und abgeschlossen; Ergebisse einer späteren Phase fleßen nur sehr beschränkt in die Überarbeitung einer früheren Phase ein; konstruktivistisches Vorgehen im Gesamtsystem • Aufbau auf validierten Dokumenten als Zwischenergebnisse • starres Modell, Abweichungen vom ursprünglichen Plan nicht vorgesehen; unterstützt jedoch kompakte, zielstrebige Projektentwicklung; zeiteffizient, jedoch hoch riskant bei neuartigen Anwendungen • Anwendung: bei gut bekannten Vorhaben mit wenig Neuigkeitsgrad

  41. IS-Projekt - das “Wasserfall-Modell” mit Rapid Prototyping • Modell zur Erweiterung des Wasserfallmodells um die Erstellung eines Prototyps in der Analysephase: • Prototyp dient lediglich der Klärung der Anforderungen, er fließt nicht in das endgültige System ein; Nachteil: Kosten; • Vorteil: fundiertere Anforderungsspezifikation möglich, verkleinert das Risiko, ein unbrauchbares System zu entwickeln (Sommerville Abb. 6.2, S. 107)

  42. IS-Projekt -Exploratory Programming • Vorgehen: Entwicklung eines Prototyps aus der (groben) Anforderungsspezifikation; schrittweise Verfeinerung/Modifikation dieses Prototyp-Systems bis das gewünschte Verhalten erzielt wird • Vorteil: System weist gewünschte Funktionalität auf • Nachteile: durch die zahlreichen Änderungen bei der Entwicklung, hat das System keine stabile Struktur; System ist nicht oder nur sehr schwer wartbar • Anwendung: bei AI-Anwendungen, z.B. bei Expertensystemen, für die vhll-Entwicklungsumgebungen existieren und das Funktionieren des Systems vorrangig ist.

  43. IS-Projekt - das evolutionäre/inkrementelle Vorgehensmodell • Ziel: Vereinigung der Vorteile des explorativen Programmierens mit jenen des disziplinieten Verfolgens des Wasserfallmodells • Vorgehen: frühes Festlegen der Systemarchitektur als Rahmen; Zerlegung des Systems in Teilsysteme, die inkrementell entwickelt werden; jedes Teilsystem wird entsprechend des Wasserfallmodells entwickelt, so daß entsprechende Dokumente erstellt und validiert werden;Teilsysteme werden inkrementell ausgeliefert;

  44. IS-Projekt - das evolutionäre/inkrementelle Vorgehensmodell das Feedback der Benutzer zu früheren Teilsystemen kann bei der Entwicklung der weiteren Teilsysteme berücksichtigt werden • Vorteile:- Pläne und Dokumentation werden für jedes Teilsystem erzeugt: erleichtert das Management des Projektes;- übliche Software-Prozeß-Standards können eingehalten werden: erleichtert die Wartbarkeit, Qualitätssicherung;- Teilergebnisse liegen früh vor: das Risiko einer Gesamt- fehlentwicklung wird minimiert ;- Auftraggeber haben wichtige Teilsysteme früh verfügbar; die frühe praktische Erfahrung wirkt sich positiv auf die weiteren Planungsschritte aus;

  45. IS-Projekt - das evolutionäre/inkrementelle Vorgehensmodell - kleine Teilprojekte sind für Auftraggeber, Entwickler und Anwender handhabbarer und führen zu schnellem Feedback bzw. Korrekturmöglichkeiten;- Einsparung beim Auftraggeber durch frühe Einführung; - Auftraggeber haben wichtige Teilsysteme früh verfügbar; die frühe praktische Erfahrung wirkt sich positiv auf die weiteren Planungsschritte aus; • Nachteile:- führt gelegentlich zu Problemen bei Verträgen;- Zerlegung in abgegrenzte Teilsysteme nicht bei jeder Aufgabenstellung sinnvoll durchführbar.

  46. IS-Projekt - das evolutionäre/inkrementelle Vorgehensmodell • Graph zum Vorgehen im Rahmen des evolutionären/inkrementellen Modells: (Sommerville, Abb. 6.3, S. 109)

  47. IS-Projektdas Spiralenmodell [Boehm, 1986] • mächtigste Erweiterung des Wasserfallmodells:basiert auf der Integration verschiedener Ansätze wie z. B. Prototyping, evolutionäre Etwicklung, Einbeziehung von Validierungsschritten • beinhaltet auch Software-Management Aspekte wie Phasenplanung, Risikoanalyse, Wirtschaftlichkeitserwägungen, etc. • grundlegende Ideen:- Phasen werden zyklisch aneinandergereiht; - in jeder Phase werden die gleichen Schritte verfolgt:* Bestimmung von Zielen und Alternativen; * Evaluierung; * Durchführung u. Validierung; * Planung der folgenden Phase.

  48. IS-Projektdas Spiralenmodell Anmerkungen zur Graphik: • Beginn: im Koordinatenursprung • die radiale Dimension repräsentiert die kummulativen Kosten aller vorangehenden Schritte; • der Winkel repräsentiert den Fortschritt, der innerhalb jedes Zyklus der Spirale erzielt wurde; • in jedem Zyklus werden die gleichen Schritte durchlaufen: für jedes Subsystem sowie für jede Entwicklungsphase; • Beginn: Planungsphase; • Ende: Kodierung/Inbetriebnahme

  49. IS-Projektdas Spiralenmodell • Beispiel zu einem typischen Zyklus der Spirale: • Beginn: Identifikation der Ziele der Phase des (Teil)produktes, welches im Entwicklungsprozeß steht • Identifikation der alternativen Mittel zur Realisierung obiger Ziele (z.B. Design A, Design B, reuse, Ankauf) • Identifikation der Randbedingungen auf die Anwendung obiger Alternativen (z.B. Kosten, Termine, Personal) • Evaluierung der Alternativen hinsichtlich Unsicherheiten und somit Risiken der Entwicklung; Formulierung einer kosteneffektiven Strategie zur Minimierung der Risiken, z.B. Benutzerbefragung, Prototyping, Simulation,

  50. IS-Projektdas Spiralenmodell • Feststellung des Restrisikos: falls gering, dann - Beschreiten der nächsten Phase des Wasserfallmodells, ggf. mit Einbeziehung der inkrementellen Entwicklung- falls groß, dann weiteres Prototyping; Fortsetzung der Risiko-Resolution; • Review und Validierung des Zyklus, inklusive des groben Plans für den nächsten Zyklus; • Detailplan für den folgenden Zyklus: dieser kann z.B. die Partitionierung des Produktes in inkremenelle Teilprodukte für ein evolutionäres Vorgehen enthalten; Teilprodukte können für die Entwicklung durch andere Organisationen bestimmt werden.

More Related