# Software

## Verfügbar

- [ ] Das Artefakt wird gemäß den Anforderungen auf einer dauerhaften, für Software geeigneten Archivplattform veröffentlicht.
- [ ] Ein stabiler Identifikator wurde im Beitrag gewählt und eingefügt.
- [ ] Die Lizenz wurde nachvollziehbar vergeben.
- [ ] Die druckfertige Version des Artikels verweist auf den persistenten Identifikator.
- [ ] Der Beitrag zum Artefakt gibt einen Überblick über den Kontext des Artefakts, gibt einen Einstieg zur Nutzung des Artefakts und stellt den zukünftigen Entwicklungsaufwand dar.

## Bewertet - Funktionsfähig

- [ ] Die README-Datei im Stammverzeichnis des Repositorys enthält mindestens eine kurze Projektbeschreibung, eine Übersicht über das Repository und verständliche Installationsanweisungen.
- [ ] Abhängigkeiten sind explizit deklariert (z. B. requirements.txt, package.json, Dockerfile, environment.yml).
- [ ] Metadaten wurden deklariert und im obersten Ordner abgelegt worden
- [ ] Das Artefakt kann auf einem modernen, dem neuesten Stand der Technik entsprechenden Computer installiert und ausgeführt werden, unabhängig von der CPU-Architektur oder dem Betriebssystem. Die Abhängigkeit von kostenpflichtigen Diensten , Closed-Source-Abhängigkeiten oder plattformspezifischer proprietärer Software muss im Beitrag zur Artefaktbeschreibung explizit sichtbar gemacht werden.
- [ ] Es werden Beispiel- oder Testdaten bereitgestellt, mit denen das Artefakt den im Artikel beschriebenen Beitrag demonstrieren kann, oder es wird eine ausführbare Testsuite bereitgestellt, die das im Artikel behauptete Verhalten abdeckt und erfolgreich durchläuft.
- [ ] Die erwarteten Ausgaben sind dokumentiert (z. B. erwartete Konsolenausgabe, Referenzergebnisdateien) oder werden durch Assertions in der Testsuite abgedeckt.
- [ ] Das Verhalten der Software, des Algorithmus oder des Analyse-Workflows stimmt mit der Beschreibung in der zugehörigen Veröffentlichung überein.

## Bewertet - Wiederverwendbar

- [ ] Die Struktur des Artefakts ist so dokumentiert, dass ein kompetenter Prüfer dessen Wiederverwendbarkeit beurteilen kann (Module, Einstiegspunkte, kurze Beschreibung der Architektur).
- [ ] Die API- oder CLI-Dokumentation wird an einem klar gekennzeichneten, dafür vorgesehenen Ort innerhalb des Artefakts bereitgestellt. 
- [ ] Es ist eine automatisierte Testsuite vorhanden, die die wichtigsten Anwendungsabläufe und die öffentlichen API-/CLI-Einstiegspunkte des Artefakts abdeckt. 
- [ ] Die Lizenz ist geeignet zur Wiederverwendung.
- [ ] Wenn das Artefakt Konfigurations- oder Erweiterungspunkte (Parameter, Plugin-Schnittstellen, Hooks) bereitstellt, beschreibt die Dokumentation die standardisierte Vorgehensweise zur Erweiterung oder Nutzung des Artefakts über diese Punkte. Artefakte ohne Erweiterungspunkte müssen diese nicht einführen.
- [ ] Die Konventionen der jeweiligen Sprache oder Technologie werden befolgt (Paketierung, Codestil, Linting). Das Projekt muss die in der Dokumentation verwendeten Konventionen enthalten (z. B. CONTRIBUTING.md, Stil- oder Linter-Konfigurationsdateien).