87 lines
5.5 KiB
Markdown
87 lines
5.5 KiB
Markdown
### 1. Arten von Artefakten in einem Softwareentwicklungsprojekt
|
|
|
|
Hier sind 15 verschiedene Typen von Artefakten, die typischerweise in einem Softwareentwicklungsprojekt erstellt werden:
|
|
|
|
1. **Anforderungsdokumente:** Beschreiben die funktionalen und nicht-funktionalen Anforderungen an das System.
|
|
2. **Spezifikationen:** Technische Details und Beschreibungen der Implementierungsanforderungen.
|
|
3. **Architekturdiagramme:** Darstellungen der Systemarchitektur, z.B. UML-Diagramme.
|
|
4. **Design-Dokumente:** Beschreiben das detaillierte Softwaredesign, einschließlich Modulen und Schnittstellen.
|
|
5. **Quellcode:** Der tatsächlich geschriebene Code der Software in einer oder mehreren Programmiersprachen.
|
|
6. **Testpläne:** Beschreiben die Vorgehensweise und die Teststrategie für die Verifikation und Validierung der Software.
|
|
7. **Testfälle:** Einzelne Szenarien, die durchgeführt werden, um zu prüfen, ob die Software korrekt funktioniert.
|
|
8. **Testberichte:** Dokumentieren die Ergebnisse von durchgeführten Tests und enthalten Informationen zu Fehlern und Problemen.
|
|
9. **Benutzerdokumentation:** Enthält Handbücher und Anleitungen zur Bedienung der Software für Endbenutzer.
|
|
10. **Administrationshandbuch:** Anleitungen für Systemadministratoren zur Installation und Wartung der Software.
|
|
11. **Installationsanweisungen:** Schritt-für-Schritt-Anleitungen zur Installation der Software.
|
|
12. **Release-Notes:** Beschreiben die Änderungen, neuen Funktionen und bekannten Probleme in einer neuen Softwareversion.
|
|
13. **Projektdokumentation:** Enthält Informationen über den Projektstatus, den Zeitplan und das Budget.
|
|
14. **Konfigurationsdateien:** Dateien, die Einstellungen und Konfigurationsinformationen der Software enthalten.
|
|
15. **Protokolldateien (Logs):** Enthalten Aufzeichnungen über Ereignisse und Aktionen, die während der Ausführung der Software auftreten.
|
|
|
|
### 2. Gruppierung der Artefakte
|
|
|
|
Artefakte können nach verschiedenen Kriterien gruppiert werden. Hier sind einige sinnvolle Gruppen:
|
|
|
|
1. **Entwicklungsphase:**
|
|
- **Analysephase:** Anforderungsdokumente, Spezifikationen
|
|
- **Designphase:** Architekturdiagramme, Design-Dokumente
|
|
- **Implementierungsphase:** Quellcode, Konfigurationsdateien
|
|
- **Testphase:** Testpläne, Testfälle, Testberichte
|
|
- **Wartungsphase:** Protokolldateien (Logs), Fehlerberichte
|
|
|
|
2. **Funktionale Gruppierung:**
|
|
- **Dokumentation:** Benutzerdokumentation, Administrationshandbuch, Projektdokumentation
|
|
- **Technische Artefakte:** Quellcode, Architekturdiagramme, Konfigurationsdateien
|
|
- **Management-Artefakte:** Projektdokumentation, Zeitpläne, Budgetpläne
|
|
|
|
3. **Verwendungszweck:**
|
|
- **Interne Artefakte:** Dokumente, die nur von Entwicklern und dem Projektteam verwendet werden (z.B. Design-Dokumente, Testberichte)
|
|
- **Externe Artefakte:** Dokumente, die für Endbenutzer oder Kunden bestimmt sind (z.B. Benutzerdokumentation, Release-Notes)
|
|
- Manuell/Maschinell
|
|
- Projekt/Produkt
|
|
- Archiviert Ja/nein
|
|
-
|
|
|
|
### 3. Voraussetzungen für die Zusammenarbeit an Artefakten im Team
|
|
|
|
Damit im Team effektiv an Artefakten gearbeitet werden kann, sollten folgende Voraussetzungen erfüllt sein:
|
|
|
|
1. **Versionierung:** Alle Artefakte sollten versioniert werden, damit Änderungen nachvollziehbar sind.
|
|
2. **Zugriffsrechte:** Es müssen klare Zugriffsrechte und Rollen definiert sein, um unbefugte Änderungen zu vermeiden.
|
|
3. **Zentrales Repository:** Die Artefakte sollten in einem zentralen Repository gespeichert werden, auf das alle Teammitglieder zugreifen können (z.B. Git).
|
|
4. **Kommunikationsstrategie:** Eine gute Kommunikation im Team ist notwendig, um Missverständnisse zu vermeiden und Änderungen effektiv abzustimmen.
|
|
5. **Werkzeuge:** Es sollten geeignete Werkzeuge zur gemeinsamen Bearbeitung von Artefakten eingesetzt werden (z.B. Kollaborationsplattformen und Tools zur Dokumentenverwaltung).
|
|
|
|
### 4. Sinn und Zweck der Versionierung von Artefakten
|
|
|
|
Es ist sinnvoll, nicht nur die letzte Version eines Artefakts zu speichern, sondern auch alle alten Stände, weil:
|
|
|
|
1. **Nachverfolgbarkeit:** Es ermöglicht die Rückverfolgung von Änderungen und die Identifikation, wann und warum eine Änderung vorgenommen wurde.
|
|
2. **Fehlerbehebung:** Bei Fehlern oder Problemen kann man zu einer früheren Version zurückkehren und untersuchen, was sich geändert hat.
|
|
3. **Vergleich:** Es ermöglicht den Vergleich zwischen verschiedenen Versionen eines Artefakts.
|
|
4. **Verlaufsprotokoll:** Man erhält ein Protokoll über den Entwicklungsprozess und kann den Fortschritt dokumentieren.
|
|
|
|
**Zu versionierende Artefakttypen:**
|
|
- Quellcode
|
|
- Spezifikationen
|
|
- Anforderungsdokumente
|
|
- Testpläne und Testfälle
|
|
- Architekturdiagramme
|
|
- Design-Dokumente
|
|
- Konfigurationsdateien
|
|
|
|
### 5. Informationen über ein Artefakt
|
|
|
|
Folgende Informationen sollten über ein Artefakt bekannt sein:
|
|
|
|
1. **Name des Artefakts:** Eindeutiger Bezeichner, der das Artefakt beschreibt.
|
|
2. **Version:** Aktuelle Versionsnummer und Historie aller früheren Versionen.
|
|
3. **Autor:** Wer das Artefakt erstellt oder zuletzt geändert hat.
|
|
4. **Erstellungsdatum:** Wann das Artefakt erstellt wurde.
|
|
5. **Änderungsdatum:** Wann das Artefakt zuletzt geändert wurde.
|
|
6. **Beschreibung:** Kurze Zusammenfassung des Inhalts und Zwecks des Artefakts.
|
|
7. **Status:** Der aktuelle Status des Artefakts (z.B. Entwurf, freigegeben, in Überarbeitung).
|
|
8. **Abhängigkeiten:** Welche anderen Artefakte von diesem abhängig sind oder mit ihm in Beziehung stehen.
|
|
9. **Zugriffsrechte:** Wer Zugriff auf das Artefakt hat und es ändern darf.
|
|
|