07. Artefakte & Dokumentation
Lernziele
Nach diesem Kapitel können Sie: - Wichtige Artefakte in IT-Projekten identifizieren und erstellen - Komponentensteckbriefe (Component Briefs) strukturieren - Schnittstellenkataloge (Interface Catalogs) erstellen - Projektstrukturpläne (PSP/WBS) aufstellen - Dokumentationsstandards und Vorlagen anwenden - Die Bedeutung von Dokumentation für den Projekterfolg begründen
Lesezeit
ca. 15-20 Minuten
1. Einführung: Warum Artefakte und Dokumentation entscheidend sind
Artefakte und Dokumentation sind die "Bausteine" eines IT-Projekts. Sie strukturieren die Arbeit, dokumentieren Entscheidungen und bilden die Basis für Wissensmanagement und Wiederverwendbarkeit.
flowchart TD
A[Artefakte & Dokumentation] --> B[Strukturierung]
A --> C[Dokumentation von Entscheidungen]
A --> D[Wissensmanagement]
A --> E[Wiederverwendbarkeit]
B --> F[Transparenz & Kontrollierbarkeit]
C --> G[Nachvollziehbarkeit & Verantwortung]
D --> H[Wissensverlust vermeiden]
E --> I[Effizienzsteigerung durch Wiederverwendung]
F --> J[Projekterfolg]
G --> J
H --> J
I --> J
style J fill:#e1ffe11.1 Artefakte vs. Dokumentation
| Begriff | Beschreibung | Beispiele |
|---|---|---|
| Artefakte | Konkrete Ergebnisse (Produkte, Modelle, Code) | Software, Datenbank-Schema, Architektur-Diagramm |
| Dokumentation | Beschreibungen und Anleitungen | Spezifikationen, Handbücher, README-Dateien |
Beziehung: Artefakte werden durch Dokumentation beschrieben, Dokumentation bezieht sich auf Artefakte.
1.2 Die Rolle des IT-Beraters bei Artefakten und Dokumentation
Der IT-Berater ist oft derjenige, der: - Artefakte identifiziert und strukturiert - Vorlagen und Standards erstellt - Die Qualität der Dokumentation sicherstellt - Wissensmanagement initiiert
2. Komponentensteckbriefe (Component Briefs)
2.1 Grundkonzept
Ein Komponentensteckbrief (auch Component Brief oder Component Card genannt) ist eine strukturierte Beschreibung einer Systemkomponente. Er dient als "Datenblatt" für Entwickler, Architekten und Stakeholder.
2.2 Struktur eines Komponentensteckbriefs
Template:
# Komponentensteckbrief: [Name der Komponente]
## Metadaten
- **ID:** [Unique ID, z.B. COM-001]
- **Name:** [Name der Komponente]
- **Version:** [Version, z.B. 1.0]
- **Status:** [Status, z.B. In Development, In Production]
- **Eigentümer:** [Verantwortliche Person/Team]
- **Zuletzt aktualisiert:** [Datum]
## Zusammenfassung
[Kurze Beschreibung der Komponente (1-2 Sätze)]
## Zweck & Ziel
- **Geschäftlicher Zweck:** [Welches Geschäftsproblem wird gelöst?]
- **Technischer Zweck:** [Welche technische Aufgabe erfüllt die Komponente?]
## Verantwortlichkeiten
- **Funktionen:** [Was macht die Komponente?]
- **Eingaben:** [Welche Daten/Ereignisse nimmt die Komponente auf?]
- **Ausgaben:** [Welche Daten/Ereignisse gibt die Komponente ab?]
## Schnittstellen
- **Abhängigkeiten:** [Von welchen Komponenten ist diese Komponente abhängig?]
- **Abhängige Komponenten:** [Welche Komponenten hängen von dieser Komponente ab?]
- **APIs:** [Welche APIs werden angeboten oder konsumiert?]
## Nicht-funktionale Anforderungen
- **Performance:** [z.B. Antwortzeit < 2 Sekunden, 10.000 Requests/Minute]
- **Sicherheit:** [z.B. OAuth 2.0, Verschlüsselung At Rest]
- **Verfügbarkeit:** [z.B. 99.9% Uptime]
- **Skalierbarkeit:** [z.B. Horizontal Scaling, Auto-Scaling]
## Technologie-Stack
- **Sprache:** [z.B. Java 17, Python 3.11]
- **Framework:** [z.B. Spring Boot 3.2, Django 5.0]
- **Datenbank:** [z.B. PostgreSQL 15, MongoDB 6.0]
- **Deployment:** [z.B. Kubernetes, Docker Compose]
## Betrieb & Monitoring
- **Deployment-Strategie:** [z.B. Blue-Green Deployment, Rolling Update]
- **Monitoring:** [z.B. Prometheus, CloudWatch, Application Insights]
- **Logging:** [z.B. ELK Stack, CloudWatch Logs]
- **Alerting:** [z.B. PagerDuty, OpsGenie]
## Governance
- **Code-Review-Prozess:** [z.B. 2 Reviewer, SonarQube-Check]
- **Testing-Strategie:** [z.B. Unit Tests, Integration Tests, E2E Tests]
- **Release-Prozess:** [z.B. CI/CD-Pipeline, GitHub Actions]
- **Rollback-Strategie:** [z.B. Automatischer Rollback bei Fehler]
## Stakeholder
- **Entwickler:** [Team verantwortlich für Entwicklung]
- **QA:** [Team verantwortlich für Testing]
- **Ops:** [Team verantwortlich für Betrieb]
- **Produktmanagement:** [Produktmanager verantwortlich für Anforderungen]
## Risiken & Abhängigkeiten
- **Risiken:** [Welche Risiken bestehen?]
- **Abhängigkeiten:** [Welche externen Abhängigkeiten gibt es?]
## Metriken & KPIs
- **Performance-KPIs:** [z.B. Response Time P95 < 1 Sekunde]
- **Quality-KPIs:** [z.B. Bug Density < 1 Bug/1000 LOC]
- **Availability-KPIs:** [z.B. Uptime > 99.9%]
2.3 Beispiel: Payment-Service
# Komponentensteckbrief: Payment-Service
## Metadaten
- **ID:** COM-PAY-001
- **Name:** Payment-Service
- **Version:** 1.0
- **Status:** In Production
- **Eigentümer:** Payments Team
- **Zuletzt aktualisiert:** 2024-01-15
## Zusammenfassung
Der Payment-Service ist für die Abwicklung von Kreditkarten- und PayPal-Zahlungen zuständig. Er integriert zu Stripe, PayPal und Adyen.
## Zweck & Ziel
- **Geschäftlicher Zweck:** Ermöglicht Kunden die Bezahlung von Bestellungen mit Kreditkarte und PayPal
- **Technischer Zweck:** Abstraktion und Konsolidierung von Payment-Provider-APIs
## Verantwortlichkeiten
- **Funktionen:**
- Kreditkarten-Zahlungen (Stripe)
- PayPal-Zahlungen (PayPal)
- Zahlungen via Adyen
- Refund-Prozess
- Zahlungs-Status-Tracking
- **Eingaben:**
- Zahlungsanfrage (Betrag, Währung, Zahlungsart, Bestell-ID)
- Refund-Anfrage (Zahlungs-ID, Betrag)
- **Ausgaben:**
- Zahlungsbestätigung (Zahlungs-ID, Status, Transaktions-ID)
- Fehlermeldung (Fehlercode, Nachricht)
## Schnittstellen
- **Abhängigkeiten:**
- User-Service (Benutzerdaten)
- Order-Service (Bestelldaten)
- Notification-Service (Zahlungsbenachrichtigungen)
- **Abhängige Komponenten:**
- Order-Service (Zahlungsstatus für Bestellungen)
- Billing-Service (Rechnungserstellung)
- **APIs:**
- REST API `/api/v1/payments` (POST, GET, PUT)
- Webhooks für Payment-Provider (Stripe Webhook, PayPal Webhook)
## Nicht-funktionale Anforderungen
- **Performance:**
- Antwortzeit: P95 < 1 Sekunde
- Durchsatz: 10.000 Payment-Requests/Minute
- **Sicherheit:**
- PCI DSS Compliance
- OAuth 2.0 für interne Services
- TLS 1.3 für externe Aufrufe
- Verschlüsselung sensibler Daten At Rest (AES-256)
- **Verfügbarkeit:**
- 99.95% Uptime (max. 21.9 Minuten Ausfall/Jahr)
- **Skalierbarkeit:**
- Horizontal Scaling (Kubernetes HPA)
- Auto-Scaling basierend auf CPU-Last
## Technologie-Stack
- **Sprache:** Java 17
- **Framework:** Spring Boot 3.2
- **API-Style:** REST mit OpenAPI 3.0
- **Datenbank:** PostgreSQL 15
- **Cache:** Redis 7
- **Deployment:** Kubernetes (Helm Charts)
- **Monitoring:** Prometheus + Grafana
- **Logging:** ELK Stack (Elasticsearch, Logstash, Kibana)
## Betrieb & Monitoring
- **Deployment-Strategie:** Blue-Green Deployment
- **Monitoring:**
- Response Time (P50, P95, P99)
- Error Rate
- Request Rate
- Provider-Specific Metrics (Stripe, PayPal, Adyen)
- **Logging:**
- Strukturierte Logs (JSON)
- Correlation IDs für Request-Tracking
- Sensitive Data Masking (PCI DSS Compliance)
- **Alerting:**
- Error Rate > 1% → PagerDuty Alert
- Response Time P95 > 2 Sekunden → OpsGenie Alert
- Provider-Down → PagerDuty Alert
## Governance
- **Code-Review-Prozess:**
- Mindestens 2 Reviewer pro Pull Request
- SonarQube Quality Gate (Code Quality > 80)
- **Testing-Strategie:**
- Unit Tests (Mocking von Payment-Providern)
- Integration Tests (Payment-Provider Sandbox)
- E2E Tests (Kreditkarten-Zahlung, PayPal-Zahlung)
- **Release-Prozess:**
- CI/CD-Pipeline (GitHub Actions)
- Automatisiertes Deployment nach Merge in main
- Canary Deployment (10% → 50% → 100%)
- **Rollback-Strategie:**
- Automatischer Rollback bei Error Rate > 5%
- Manueller Rollback über Kubernetes Rollout Command
## Stakeholder
- **Entwickler:** Payments Team (3 Developer)
- **QA:** QA Team (2 QA Engineer)
- **Ops:** DevOps Team (2 DevOps Engineer)
- **Produktmanagement:** Product Manager Payments
- **Compliance:** DPO & Security Team (PCI DSS Compliance)
## Risiken & Abhängigkeiten
- **Risiken:**
- Payment-Provider-Ausfall (Mitigation: Multi-Provider, Fallback-Strategie)
- PCI DSS Compliance-Verletzung (Mitigation: Regular Security Audits, Penetration-Tests)
- Performance-Probleme bei Peak-Lasten (Mitigation: Auto-Scaling, Cache)
- **Abhängigkeiten:**
- Stripe API (Dependency Level: High)
- PayPal API (Dependency Level: Medium)
- Adyen API (Dependency Level: Low)
- PostgreSQL (Dependency Level: High)
## Metriken & KPIs
- **Performance-KPIs:**
- Response Time P95 < 1 Sekunde
- Request Rate > 5.000/Minute bei Peak-Lasten
- **Quality-KPIs:**
- Bug Density < 1 Bug/1000 LOC
- Payment-Success Rate > 95%
- Refund-Success Rate > 98%
- **Availability-KPIs:**
- Uptime > 99.95% (max. 21.9 Minuten Ausfall/Jahr)
- Provider-Uptime-Availability > 99.9%
3. Schnittstellenkataloge (Interface Catalogs)
3.1 Grundkonzept
Ein Schnittstellenkatalog (Interface Catalog) ist eine strukturierte Auflistung aller Schnittstellen zwischen Komponenten, Systemen und externen Partnern. Er ist essenziell für die Integration, das Testen und das Verständnis der Systemarchitektur.
3.2 Struktur eines Schnittstellenkatalogs
| Feld | Beschreibung | Beispiel |
|---|---|---|
| ID | Eindeutige Identifikation der Schnittstelle | IF-001 |
| Name | Name der Schnittstelle | Payment-API |
| Typ | Art der Schnittstelle (REST, GraphQL, gRPC, Message Queue, etc.) | REST |
| Konsument | Wer nutzt die Schnittstelle? | Order-Service, Billing-Service |
| Provider | Wer stellt die Schnittstelle bereit? | Payment-Service |
| Zweck | Warum wird die Schnittstelle benötigt? | Zahlungsabwicklung |
| Endpunkt | URL oder Pfad | /api/v1/payments |
| Methoden | HTTP-Methoden (GET, POST, PUT, DELETE, etc.) | POST (Zahlung erstellen), GET (Status abfragen) |
| Authentifizierung | Wie wird authentifiziert? | OAuth 2.0, JWT, API Key |
| Autorisierung | Wie wird autorisiert? | Role-Based Access Control (RBAC) |
| Request-Format | Format der Anfrage | JSON |
| Response-Format | Format der Antwort | JSON |
| Rate Limiting | Begrenzung der Anfragerate | 1.000 Requests/Minute |
| SLA | Service Level Agreement | Verfügbarkeit 99.9%, Antwortzeit < 1 Sekunde |
| Version | Version der Schnittstelle | v1 |
| Dokumentation | Link zur Dokumentation | OpenAPI 3.0 Spec |
| Kontakt | Ansprechpartner bei Problemen | payments-team@company.com |
3.3 Beispiel: Schnittstellenkatalog E-Commerce-System
| ID | Name | Typ | Konsument | Provider | Zweck | Endpunkt | Methoden | Auth | SLA |
|---|---|---|---|---|---|---|---|---|---|
| IF-001 | User-API | REST | Order-Service, Payment-Service | User-Service | Benutzerdaten abfragen | /api/v1/users/{id} |
GET, PUT | OAuth 2.0, JWT | 99.9%, < 500ms |
| IF-002 | Order-API | REST | Webshop, Payment-Service | Order-Service | Bestellungen erstellen und verwalten | /api/v1/orders |
POST, GET, PUT, DELETE | OAuth 2.0, JWT | 99.9%, < 1s |
| IF-003 | Payment-API | REST | Order-Service, Billing-Service | Payment-Service | Zahlungsabwicklung | /api/v1/payments |
POST, GET, PUT | OAuth 2.0, JWT + API Key | 99.95%, < 1s |
| IF-004 | Product-API | REST | Webshop, Order-Service | Product-Service | Produktdaten abfragen | /api/v1/products |
GET, POST, PUT | OAuth 2.0, JWT | 99.9%, < 500ms |
| IF-005 | Stripe-API | REST | Payment-Service | Stripe (External) | Kreditkarten-Zahlungen | https://api.stripe.com/v1/charges |
POST | API Key | 99.9%, < 1s |
| IF-006 | PayPal-API | REST | Payment-Service | PayPal (External) | PayPal-Zahlungen | https://api.paypal.com/v2/payments |
POST | OAuth 2.0 | 99.9%, < 1s |
| IF-007 | Kafka-Orders | Message Queue | Payment-Service, Notification-Service | Order-Service | Ereignisbasierte Kommunikation zu Bestellungen | Topic: orders |
Produce, Consume | SASL/SCRAM | 99.9%, < 100ms |
3.4 Best Practices für Schnittstellenkataloge
DO: - ✅ Automatisierte Dokumentation: OpenAPI/Swagger, gRPC Reflection - ✅ Versionierung: Semantische Versionierung (v1, v2, v3) - ✅ SLAs: Definierte Service Level Agreements - ✅ Monitoring: Überwachung der Schnittstellen (Response Time, Error Rate) - ✅ Deprecation-Strategie: Vorankündigung von Änderungen - ✅ Mocking: Mock-Server für Tests
DON'T: - ❌ Breaking Changes ohne Vorankündigung: Breaking Changes ohne Versions-Update - ❌ Undokumentierte Schnittstellen: "Geheime" APIs - ❌ Fehlende Authentifizierung: Unauthentifizierte Schnittstellen - ❌ Kein Rate Limiting: DoS-Anfälligkeit - ❌ Fehlende Fehlerbehandlung: Keine Standard-Fehlercodes - ❌ Keine Monitoring-Integration: "Blindflug" bei Problemen
4. Projektstrukturplan (PSP) / Work Breakdown Structure (WBS)
4.1 Grundkonzept
Der Projektstrukturplan (PSP), international auch Work Breakdown Structure (WBS) genannt, ist eine hierarchische Gliederung der Projektaufgaben in Arbeitspakete.
graph TD
A[Projekt: CRM-Einführung] --> B[Phase 1: Konzeption]
A --> C[Phase 2: Entwicklung]
A --> D[Phase 3: Test & Go-Live]
B --> B1[Anforderungsanalyse]
B --> B2[Architektur-Design]
B --> B3[Entscheidungs-Freigabe]
C --> C1[Backend-Entwicklung]
C --> C2[Frontend-Entwicklung]
C --> C3[Integrationen]
D --> D1[Testing]
D --> D2[Go-Live]
D --> D3[Hypercare]
C1 --> C1A[User-Service]
C1 --> C1B[Order-Service]
C1 --> C1C[Payment-Service]
C2 --> C2A[Webshop UI]
C2 --> C2B[Admin-UI]
C3 --> C3A[Stripe-Integration]
C3 --> C3B[PayPal-Integration]4.2 PSP-Beispiel: ERP-Migration
| ID | Arbeitspaket | Beschreibung | Verantwortlich | Dauer | Kosten | Vorbedingung |
|---|---|---|---|---|---|---|
| WP-1 | Phase 1: Vorstudie | |||||
| WP-1.1 | Ist-Analyse | Analyse der aktuellen Prozesse und Systeme | Business Analyst | 2 Wochen | €10.000 | - |
| WP-1.2 | Soll-Konzept | Definition des Zielzustands | Business Analyst | 3 Wochen | €15.000 | WP-1.1 |
| WP-1.3 | Vorstudie-Review | Review mit Stakeholdern | Project Manager | 1 Woche | €5.000 | WP-1.2 |
| WP-2 | Phase 2: Konzeption | |||||
| WP-2.1 | Architektur-Design | High-Level-Architektur entwerfen | Solution Architect | 2 Wochen | €10.000 | WP-1.3 |
| WP-2.2 | Data-Modeling | Datenbank-Design entwerfen | Data Architect | 2 Wochen | €10.000 | WP-2.1 |
| WP-2.3 | Integration-Design | Schnittstellen zu bestehenden Systemen | Integration Architect | 2 Wochen | €10.000 | WP-2.1 |
| WP-3 | Phase 3: Entwicklung | |||||
| WP-3.1 | Backend-Entwicklung | ERP-Backend entwickeln | Backend Team | 12 Wochen | €120.000 | WP-2.3 |
| WP-3.2 | Frontend-Entwicklung | ERP-Frontend entwickeln | Frontend Team | 10 Wochen | €100.000 | WP-2.3 |
| WP-3.3 | Integrationen | Integrationen zu Dritttsystemen implementieren | Integration Team | 8 Wochen | €80.000 | WP-2.3 |
| WP-4 | Phase 4: Test & Go-Live | |||||
| WP-4.1 | System-Testing | Systemtest und Fehlerbehebung | QA Team | 4 Wochen | €40.000 | WP-3.1, WP-3.2, WP-3.3 |
| WP-4.2 | User-Acceptance-Test (UAT) | UAT mit Fachbereich | QA Team | 2 Wochen | €20.000 | WP-4.1 |
| WP-4.3 | Go-Live | Go-Live und Hypercare | DevOps Team | 2 Wochen | €20.000 | WP-4.2 |
Zusammenfassung:
| Phase | Dauer | Kosten |
|---|---|---|
| Phase 1: Vorstudie | 6 Wochen | €30.000 |
| Phase 2: Konzeption | 6 Wochen | €30.000 |
| Phase 3: Entwicklung | 12 Wochen | €300.000 |
| Phase 4: Test & Go-Live | 8 Wochen | €80.000 |
| Gesamt | 32 Wochen | €440.000 |
4.3 Gantt-Diagramm
gantt
title ERP-Migration Projektplan
dateFormat YYYY-MM-DD
axisFormat %Y-%m-%d
section Phase 1: Vorstudie
Ist-Analyse :a1, 2024-02-01, 14d
Soll-Konzept :a2, after a1, 21d
Vorstudie-Review :a3, after a2, 7d
section Phase 2: Konzeption
Architektur-Design :b1, after a3, 14d
Data-Modeling :b2, after a3, 14d
Integration-Design :b3, after b1, 14d
section Phase 3: Entwicklung
Backend-Entwicklung :c1, after b3, 60d
Frontend-Entwicklung :c2, after b3, 50d
Integrationen :c3, after b3, 40d
section Phase 4: Test & Go-Live
System-Testing :d1, after c1 c2 c3, 28d
UAT :d2, after d1, 14d
Go-Live :d3, after d2, 14d5. Dokumentationsstandards und Vorlagen
5.1 Dokumentations-Typen
| Typ | Zweck | Zielgruppe | Format |
|---|---|---|---|
| Spezifikationen | Anforderungen definieren | Stakeholder, Entwickler | Markdown, Word, Confluence |
| Design-Dokumente | Architektur und Design dokumentieren | Architekten, Entwickler | Markdown, PlantUML, draw.io |
| API-Dokumentation | Schnittstellen beschreiben | Entwickler, Integration-Partner | OpenAPI/Swagger, GraphQL Schema |
| Benutzerhandbücher | Nutzung für Endanwender | Anwender, Support | PDF, Online Help |
| Betriebshandbücher | Betrieb und Wartung | Ops, DevOps | Confluence, Wiki |
| Test-Dokumentation | Testfälle und Testergebnisse | QA, Entwickler | Excel, Test Management Tool |
5.2 Dokumentations-Checkliste
Projekt-Start: - [ ] Projektcharter erstellt - [ ] Stakeholder identifiziert - [ ] Anforderungen dokumentiert - [ ] Architektur-Design erstellt - [ ] PSP/WBS erstellt
Projekt-Durchführung: - [ ] Komponentensteckbriefe erstellt - [ ] Schnittstellenkatalog erstellt - [ ] API-Dokumentation (OpenAPI/Swagger) - [ ] Testplan und Testfälle dokumentiert - [ ] Risk-Register gepflegt
Projekt-Abschluss: - [ ] Abschlussbericht erstellt - [ ] Lessons Learned dokumentiert - [ ] User- und Admin-Dokumentation erstellt - [ ] Übergabedokumentation erstellt - [ ] Wissensmanagement aktualisiert
6. Wissensmanagement
6.1 Wissensmanagement-Strategie
graph TD
A[Wissensmanagement] --> B[Dokumentation]
A --> C[Training]
A --> D[Tools & Plattformen]
A --> E[Kultur]
B --> B1[Wikis, Confluence]
C --> C1[Onboarding, Workshops]
D --> D1[Git, Jira, Confluence]
E --> E1[Wissensaustausch, Peer-Reviews]6.2 Wissensarten
| Art | Beschreibung | Beispiel |
|---|---|---|
| Expertenwissen | Wissen, das in den Köpfen der Experten steckt | Architektur-Entscheidungen, Lessons Learned |
| Explizites Wissen | Dokumentiertes Wissen | Dokumentation, APIs, Code-Kommentare |
| Implizites Wissen | Erfahrungswissen, nicht direkt dokumentierbar | "Wie machen wir das hier eigentlich?", Heuristiken |
6.3 Vermeidung von Wissensverlust
Strategien: - Regelmäßige Dokumentation: Aktualisierung nach wichtigen Entscheidungen - Pair Programming: Wissen wird geteilt während der Entwicklung - Code-Reviews: Wissen wird durch Code-Reviews transferiert - Lunch & Learns: Regelmäßige Präsentationen und Workshops - Shadowing: Neue Mitarbeiter schauen erfahrenen Mitarbeitern über die Schulter - Rotaion: Regelmäßiger Wechsel der Aufgabenbereiche - Exit-Interviews: Wissen von austretenden Mitarbeitern erfassen
Schlüsselbegriffe
| Begriff | Definition |
|---|---|
| Artefakt | Konkretes Ergebnis eines Projekts (Software, Dokumentation, Modelle) |
| Komponentensteckbrief | Strukturierte Beschreibung einer Systemkomponente (Component Brief) |
| Schnittstellenkatalog | Systematische Auflistung aller Schnittstellen (Interface Catalog) |
| PSP / WBS | Projektstrukturplan / Work Breakdown Structure, hierarchische Gliederung von Projektaufgaben |
| OpenAPI / Swagger | Standard für API-Dokumentation (REST APIs) |
| API | Application Programming Interface, Schnittstelle zwischen Software-Komponenten |
| SLA | Service Level Agreement, Vereinbarung über Service-Qualität (Verfügbarkeit, Antwortzeit) |
| Wissensmanagement | Systematische Erfassung, Speicherung und Verteilung von Wissen |
| Explicit Knowledge | Explizites, dokumentiertes Wissen |
| Implicit Knowledge | Erfahrungswissen, Heuristiken, nicht direkt dokumentierbar |
Verständnisfragen
Frage 1: Komponentensteckbrief
Sie erstellen einen Komponentensteckbrief für einen "User-Service". Welche Informationen sollten im Abschnitt "Nicht-funktionale Anforderungen" enthalten sein? Geben Sie konkrete Beispiele.
Lösung: Nicht-funktionale Anforderungen (NFRs) im Komponentensteckbrief für User-Service:
Performance: - Response Time: P95 < 500 ms, P99 < 1 Sekunde für Benutzerabfragen - Throughput: 10.000 Requests/Minute für gleichzeitige Benutzeranfragen - Concurrency: Unterstützung von 1.000 gleichzeitigen Benutzern - Caching: Cache für Benutzerdaten (TTL: 5 Minuten) zur Performance-Steigerung
Sicherheit: - Authentifizierung: OAuth 2.0 mit JWT (JSON Web Tokens) - Autorisierung: Role-Based Access Control (RBAC) mit Rollen (Admin, User, Guest) - Verschlüsselung: Verschlüsselung sensibler Daten At Rest (Passwort-Hashing mit bcrypt, AES-256 für PII) - Verschlüsselung In Transit: TLS 1.3 für alle API-Aufrufe - DSGVO-Compliance: Datenminimierung, Recht auf Löschung implementieren, Audit-Logs für Zugriffe - Penetration-Tests: Regelmäßige Penetration-Tests vor Go-Live und alle 6 Monate
Verfügbarkeit: - Uptime: 99.9% (max. 43,2 Minuten Ausfall pro Monat) - Redundanz: Multi-AZ Deployment (Availability Zones in AWS/Azure) - Disaster Recovery: Hot-Standby in sekundärer Region, RTO < 4 Stunden, RPO < 15 Minuten
Skalierbarkeit: - Horizontal Scaling: Auto-Scaling basierend auf CPU-Last und Request-Rate - Vertical Scaling: Skalierung auf größere Instanzen bei Bedarf - Database Scaling: Read Replicas für Lesezugriffe, Sharding für hohe Datenvolumina
Wartbarkeit: - Code-Qualität: SonarQube Quality Gate (Code Quality > 80, Test Coverage > 80%) - Logging: Strukturierte Logs (JSON) mit Correlation IDs für Request-Tracking - Monitoring: Metrics (Prometheus) für Performance und Verfügbarkeit - Alerting: PagerDuty Alerts bei Error Rate > 1% oder Response Time P95 > 1 Sekunde
Beispiel-Konfiguration im Komponentensteckbrief:
## Nicht-funktionale Anforderungen
- **Performance:**
- Response Time P95 < 500 ms
- Throughput: 10.000 Requests/Minute
- Concurrency: 1.000 gleichzeitige Benutzer
- Cache: Redis mit TTL 5 Minuten
- **Sicherheit:**
- Authentifizierung: OAuth 2.0 mit JWT
- Autorisierung: RBAC (Admin, User, Guest)
- Verschlüsselung At Rest: AES-256, bcrypt für Passwörter
- Verschlüsselung In Transit: TLS 1.3
- DSGVO-Compliance: Data Minimization, Right to Delete, Audit-Logs
- Penetration-Tests: Alle 6 Monate
- **Verfügbarkeit:**
- Uptime: 99.9% (max. 43,2 Min./Monat)
- Redundanz: Multi-AZ Deployment
- Disaster Recovery: Hot-Standby sekundäre Region, RTO < 4h, RPO < 15m
- **Skalierbarkeit:**
- Horizontal Scaling: Auto-Scaling (CPU, Request-Rate)
- Vertical Scaling: Größere Instanzen bei Bedarf
- Database Scaling: Read Replicas, Sharding
- **Wartbarkeit:**
- Code-Qualität: SonarQube Quality Gate > 80, Test Coverage > 80%
- Logging: Strukturierte JSON-Logs, Correlation IDs
- Monitoring: Prometheus Metrics
- Alerting: PagerDuty (Error Rate > 1%, Response Time P95 > 1s)
Frage 2: Schnittstellenkatalog
Ein E-Commerce-System besteht aus folgenden Komponenten: Webshop, Order-Service, Payment-Service, User-Service, Product-Service. Erstellen Sie einen Schnittstellenkatalog für die REST-API-Schnittstellen zwischen diesen Komponenten.
Lösung: Schnittstellenkatalog: E-Commerce-System
| ID | Name | Typ | Konsument | Provider | Zweck | Endpunkt | Methoden | Auth | Request-Format | Response-Format | Rate Limit | SLA |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| IF-001 | User-API | REST | Webshop, Order-Service, Payment-Service | User-Service | Benutzerdaten abfragen und verwalten | /api/v1/users | GET, POST, PUT, DELETE | OAuth 2.0, JWT | JSON | JSON | 1.000 Req/Min | 99.9%, < 500ms |
| IF-002 | Order-API | REST | Webshop, Payment-Service, Notification-Service | Order-Service | Bestellungen erstellen und verwalten | /api/v1/orders | POST, GET, PUT, DELETE | OAuth 2.0, JWT | JSON | JSON | 2.000 Req/Min | 99.9%, < 1s |
| IF-003 | Payment-API | REST | Order-Service, Billing-Service | Payment-Service | Zahlungsabwicklung | /api/v1/payments | POST, GET, PUT | OAuth 2.0, JWT + API Key | JSON | JSON | 1.000 Req/Min | 99.95%, < 1s |
| IF-004 | Product-API | REST | Webshop, Order-Service | Product-Service | Produktdaten abfragen | /api/v1/products | GET, POST, PUT | OAuth 2.0, JWT | JSON | JSON | 5.000 Req/Min | 99.9%, < 500ms |
**Detailbeschreibung der Schnittstellen:**
**IF-001: User-API**
```yaml
ID: IF-001
Name: User-API
Typ: REST
Konsument: Webshop, Order-Service, Payment-Service
Provider: User-Service
Zweck: Benutzerdaten abfragen und verwalten
Endpunkt: /api/v1/users
Methoden:
- GET: Benutzerdaten abfragen
- POST: Neuen Benutzer erstellen
- PUT: Benutzerdaten aktualisieren
- DELETE: Benutzer löschen
Authentifizierung: OAuth 2.0, JWT
Request-Format: JSON
Response-Format: JSON
Rate Limiting: 1.000 Requests/Minute
SLA:
- Verfügbarkeit: 99.9%
- Antwortzeit: < 500ms (P95)
Dokumentation: [OpenAPI 3.0 Spec](https://api.company.com/swagger/user-api.yaml)
Kontakt: users-team@company.com
```
**IF-002: Order-API**
```yaml
ID: IF-002
Name: Order-API
Typ: REST
Konsument: Webshop, Payment-Service, Notification-Service
Provider: Order-Service
Zweck: Bestellungen erstellen und verwalten
Endpunkt: /api/v1/orders
Methoden:
- POST: Neue Bestellung erstellen
- GET: Bestellstatus abfragen
- PUT: Bestellung aktualisieren (z.B. Storno)
- DELETE: Bestellung löschen (nur für Admins)
Authentifizierung: OAuth 2.0, JWT
Request-Format: JSON
Response-Format: JSON
Rate Limiting: 2.000 Requests/Minute
SLA:
- Verfügbarkeit: 99.9%
- Antwortzeit: < 1 Sekunde (P95)
Dokumentation: [OpenAPI 3.0 Spec](https://api.company.com/swagger/order-api.yaml)
Kontakt: orders-team@company.com
```
**IF-003: Payment-API**
```yaml
ID: IF-003
Name: Payment-API
Typ: REST
Konsument: Order-Service, Billing-Service
Provider: Payment-Service
Zweck: Zahlungsabwicklung
Endpunkt: /api/v1/payments
Methoden:
- POST: Neue Zahlung initiieren
- GET: Zahlungsstatus abfragen
- PUT: Zahlung aktualisieren (z.B. Refund)
Authentifizierung: OAuth 2.0, JWT + API Key (für kritische Operationen)
Request-Format: JSON
Response-Format: JSON
Rate Limiting: 1.000 Requests/Minute
SLA:
- Verfügbarkeit: 99.95% (kritisch für E-Commerce)
- Antwortzeit: < 1 Sekunde (P95)
Dokumentation: [OpenAPI 3.0 Spec](https://api.company.com/swagger/payment-api.yaml)
Kontakt: payments-team@company.com
```
**IF-004: Product-API**
```yaml
ID: IF-004
Name: Product-API
Typ: REST
Konsument: Webshop, Order-Service
Provider: Product-Service
Zweck: Produktdaten abfragen
Endpunkt: /api/v1/products
Methoden:
- GET: Produktdaten abfragen (Liste, Detail, Suche)
- POST: Neues Produkt erstellen (nur für Admins)
- PUT: Produktdaten aktualisieren (nur für Admins)
Authentifizierung: OAuth 2.0, JWT
Request-Format: JSON
Response-Format: JSON
Rate Limiting: 5.000 Requests/Minute (höheres Rate Limit für Lesezugriffe)
SLA:
- Verfügbarkeit: 99.9%
- Antwortzeit: < 500ms (P95)
Dokumentation: [OpenAPI 3.0 Spec](https://api.company.com/swagger/product-api.yaml)
Kontakt: products-team@company.com
```
**Best Practices angewendet:**
1. **Automatisierte Dokumentation:** OpenAPI 3.0 Spec für jede Schnittstelle
2. **Authentifizierung:** OAuth 2.0, JWT für alle internen Services, zusätzliche API Key für kritische Operationen (Payment-API)
3. **Rate Limiting:** Unterschiedliche Rate Limits je nach Nutzungsmuster (z.B. Product-API hat höheres Limit für Lesezugriffe)
4. **SLAs:** Verfügbarkeits- und Antwortzeit-Anforderungen definiert
5. **Monitoring:** Überwachung der Schnittstellen (Response Time, Error Rate) empfohlen
6. **Versionierung:** Semantische Versionierung (v1) für zukünftige Änderungen
Frage 3: Projektstrukturplan (PSP/WBS)
Ein Unternehmen plant die Entwicklung eines neuen CRM-Systems. Erstellen Sie einen Projektstrukturplan (PSP) mit mindestens 4 Phasen und 3-4 Arbeitspaketen pro Phase. Gehen Sie auch auf die Abhängigkeiten zwischen Arbeitspaketen ein.
Lösung: Projektstrukturplan (PSP): CRM-System
| ID | Arbeitspaket | Beschreibung | Verantwortlich | Dauer | Kosten | Vorbedingung | Abhängigkeiten |
|---|---|---|---|---|---|---|---|
| WP-1 | Phase 1: Vorstudie | ||||||
| WP-1.1 | Ist-Analyse | Analyse der aktuellen Vertriebsprozesse und -tools | Business Analyst | 2 Wochen | €10.000 | - | - |
| WP-1.2 | Stakeholder-Interviews | Interviews mit Vertriebsmitarbeitern, Managern, IT | Business Analyst | 2 Wochen | €10.000 | WP-1.1 | - |
| WP-1.3 | Anforderungserhebung | Anforderungen dokumentieren (Use Cases, User Stories) | Business Analyst | 3 Wochen | €15.000 | WP-1.2 | - |
| WP-1.4 | Soll-Konzept | Soll-Konzept (Fachkonzept) erstellen | Business Analyst | 3 Wochen | €15.000 | WP-1.3 | - |
| WP-1.5 | Vorstudie-Review | Review mit Stakeholdern und Management | Project Manager | 1 Woche | €5.000 | WP-1.4 | - |
| WP-2 | Phase 2: Konzeption | ||||||
| WP-2.1 | Architektur-Design | High-Level-Architektur entwerfen | Solution Architect | 2 Wochen | €10.000 | WP-1.5 | - |
| WP-2.2 | UI/UX-Design | Wireframes und Prototypen für das UI entwerfen | UI/UX Designer | 3 Wochen | €15.000 | WP-1.4 | WP-1.4 |
| WP-2.3 | Datenbank-Design | Datenbank-Schema und Datenmodell entwerfen | Data Architect | 2 Wochen | €10.000 | WP-2.1 | WP-2.1 |
| WP-2.4 | API-Design | REST-APIs spezifizieren (OpenAPI/Swagger) | API Architect | 2 Wochen | €10.000 | WP-2.1 | WP-2.1 |
| WP-2.5 | Sicherheit- und Compliance-Konzept | Security- und Compliance-Konzept erstellen | Security Architect | 2 Wochen | €10.000 | WP-2.1 | WP-2.1 |
| WP-3 | Phase 3: Entwicklung | ||||||
| WP-3.1 | Backend-Entwicklung | CRM-Backend entwickeln | Backend Team | 10 Wochen | €100.000 | WP-2.3, WP-2.4 | WP-2.3, WP-2.4 |
| WP-3.2 | Frontend-Entwicklung | CRM-Frontend (Web) entwickeln | Frontend Team | 8 Wochen | €80.000 | WP-2.2, WP-2.4 | WP-2.2, WP-2.4 |
| WP-3.3 | Integrationen | Integrationen zu bestehenden Systemen (ERP, E-Mail, Kalender) implementieren | Integration Team | 6 Wochen | €60.000 | WP-2.4 | WP-3.1 |
| WP-3.4 | Security-Implementierung | Sicherheitsmaßnahmen (Auth, RBAC, Encryption) implementieren | Security Engineer | 4 Wochen | €40.000 | WP-2.5, WP-3.1 | WP-2.5, WP-3.1 |
| WP-4 | Phase 4: Test & Go-Live | ||||||
| WP-4.1 | Unit-Testing | Unit Tests für Backend und Frontend | Backend Team, Frontend Team | 4 Wochen | €40.000 | WP-3.1, WP-3.2 | WP-3.1, WP-3.2 |
| WP-4.2 | Integration-Testing | Integration Tests für Schnittstellen | QA Team | 3 Wochen | €30.000 | WP-3.3 | WP-3.3 |
| WP-4.3 | System-Testing | Systemtest und Fehlerbehebung | QA Team | 3 Wochen | €30.000 | WP-4.1, WP-4.2 | WP-4.1, WP-4.2 |
| WP-4.4 | Security-Testing | Penetration-Tests und Security-Audit | Security Team | 2 Wochen | €20.000 | WP-3.4 | WP-3.4 |
| WP-4.5 | UAT (User-Acceptance-Test) | UAT mit Vertriebsmitarbeitern | QA Team, Vertrieb | 2 Wochen | €20.000 | WP-4.3, WP-4.4 | WP-4.3, WP-4.4 |
| WP-4.6 | Go-Live | Go-Live und Hypercare (2 Wochen) | DevOps Team, Project Manager | 2 Wochen | €20.000 | WP-4.5 | WP-4.5 |
Zusammenfassung:
| Phase | Dauer | Kosten |
|---|---|---|
| Phase 1: Vorstudie | 11 Wochen | €55.000 |
| Phase 2: Konzeption | 11 Wochen | €55.000 |
| Phase 3: Entwicklung | 10 Wochen | €280.000 |
| Phase 4: Test & Go-Live | 14 Wochen | €160.000 |
| Gesamt | 46 Wochen | €550.000 |
Abhängigkeiten visualisiert:
graph TD
WP1_1[WP-1.1 Ist-Analyse] --> WP1_2[WP-1.2 Stakeholder-Interviews]
WP1_2 --> WP1_3[WP-1.3 Anforderungserhebung]
WP1_3 --> WP1_4[WP-1.4 Soll-Konzept]
WP1_4 --> WP1_5[WP-1.5 Vorstudie-Review]
WP1_5 --> WP2_1[WP-2.1 Architektur-Design]
WP1_4 --> WP2_2[WP-2.2 UI/UX-Design]
WP2_1 --> WP2_3[WP-2.3 Datenbank-Design]
WP2_1 --> WP2_4[WP-2.4 API-Design]
WP2_1 --> WP2_5[WP-2.5 Security-Konzept]
WP2_3 --> WP3_1[WP-3.1 Backend-Entwicklung]
WP2_4 --> WP3_1
WP2_2 --> WP3_2[WP-3.2 Frontend-Entwicklung]
WP2_4 --> WP3_2
WP3_1 --> WP3_3[WP-3.3 Integrationen]
WP2_5 --> WP3_4[WP-3.4 Security-Implementierung]
WP3_1 --> WP3_4
WP3_1 --> WP4_1[WP-4.1 Unit-Testing]
WP3_2 --> WP4_1
WP3_3 --> WP4_2[WP-4.2 Integration-Testing]
WP4_1 --> WP4_3[WP-4.3 System-Testing]
WP4_2 --> WP4_3
WP3_4 --> WP4_4[WP-4.4 Security-Testing]
WP4_3 --> WP4_5[WP-4.5 UAT]
WP4_4 --> WP4_5
WP4_5 --> WP4_6[WP-4.6 Go-Live]Kritische Pfade (Critical Paths):
-
Kritischer Pfad 1 (Backend-Fokus): WP-1.1 → WP-1.2 → WP-1.3 → WP-1.4 → WP-1.5 → WP-2.1 → WP-2.3 → WP-3.1 → WP-3.3 → WP-4.2 → WP-4.3 → WP-4.5 → WP-4.6 Gesamtdauer: 46 Wochen
-
Kritischer Pfad 2 (Frontend-Fokus): WP-1.1 → WP-1.2 → WP-1.3 → WP-1.4 → WP-1.5 → WP-2.2 → WP-3.2 → WP-4.1 → WP-4.3 → WP-4.5 → WP-4.6 Gesamtdauer: 42 Wochen
Empfehlung: - Parallelisierung von Backend- und Frontend-Entwicklung möglich (siehe kritische Pfade) - UI/UX-Design kann parallel zu Architektur-Design starten - Integration-Testing erst nach Integrationen möglich - UAT erst nach System-Testing und Security-Testing möglich - Puffer (10-15%) in Zeitplan einplanen für unvorhergesehene Verzögerungen