Vorschläge zur Sicherung der Qualität in agilen .NET Softwareprojekten.
Version 1.2.8
Feedback an mail@jannis-kuehn-consulting.de
Siehe auch: Agile Project Review Guide
Anmerkungen, Vorschläge und Hinweise sind ausdrücklich erwünscht!
Inhaltsverzeichnis
| 1. | Organisation |
| 2. | Entwicklung |
| 2.1. | Versionskontrolle |
| 2.2. | Fehlerbehandlung |
| 2.3. | Tests |
| 2.4. | Abhängigkeiten |
| 3. | Daten |
| 3.1. | Datenbanken |
| 4. | Dokumentation |
| 4.1. | Logging |
| 5. | Bereitstellung |
| 5.1. | Build |
| 5.2. | Deployment |
| 6. | Betrieb |
| 6.1. | Monitoring |
| 7. | Literatur |
C001 Anforderungen gelten erst als "Done", wenn sie an den Anwender ausgeliefert und nachweislich in Benutzung sind.
Beispiel: Erst wenn Telemetriedaten zur Nutzung des Features eingetroffen sind und dokumentiert wurden, gilt die Anforderung als "Done".
Tags: Disziplin Organisatorisch Qualität
C009 Testdaten sind anonymisiert und enthalten keine zuordenbare Nutzerinformationen.
Anmerkung: Datenschutz und diskreter Umgang mit Anwenderdaten.
Tags: Organisatorisch Qualität Security
C115 Die SOLID Prinzipien werden eingehalten.
Single Responsibility Principle, Open Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, Dependency Inversion Principle
Tags: Architektur Disziplin Nachhaltigkeit Qualität Stabilität
C031 Refaktorisierungsmaßnahmen werden immer auf das komplette Projekt angewendet.
Anmerkung: Vermeidung von Architektur- und Stilbrüchen innerhalb einer Codebasis.
Tags: Disziplin Nachhaltigkeit Qualität
C030 Der Code-Style im gesamten Quellcode entspricht den für das Projekt geltenden Konventionen.
Anmerkung: Erhöht Lesbarkeit, Nachvollziehbarkeit und reduziert durch einheitliche Muster den zeitlichen Aufwand beim Verstehen des Quelltextes.
C035 Zur Sicherstellung von Qualitätsrichtlinien in Bezug auf den Quellcode werden automatische Analysetools eingesetzt.
Beispiel: FX Cop Analyzers
Tags: Automatisierung Nachhaltigkeit Organisatorisch Qualität
C033 Statische Codeanalysen werden regelmäßig und automatisiert durchgeführt und fließen in den Entwicklungsprozess ein.
Beispiel: Sonarqube integriert im CI-Build
C034 Die statische Codeanalyse ermittelt nicht erreichbaren Code. Dieser Code wird konsequent aus den Projekten entfernt.
Beispiel: Nicht erreichbarer Code erzeugt einen Buildfehler.
Tags: Disziplin Nachhaltigkeit Qualität
C122 Es gibt ein Konzept für den Austausch von Hash-, bzw. Verschlüsselungsverfahren.
Beispiel: Austausch des Hashverfahrens für Nutzerpasswörter gegen ein stärkeres oder besser geeignetes Verwahren.
Tags: Kundenorientierung Nachhaltigkeit Organisatorisch Qualität Security
C117 Die Clean Code Prinzipien sind bekannt und werden fallabhängig angewendet.
Prinzipien: Don't Repeat Yourself, Keep it simple stupid, Vorsicht vor Optimierungen, Favour Composition over Inheritance, Integration Operation Segregation Principle, Single Level of Abstraction, Single Responsibility Principle, Separation of Concerns, Source Code Konventionen, Interface Segregation Principle, Dependency Inversion Principle, Liskov Substitution Principle, Principle of Least Astonishment, Information Hiding Principle, Open Closed Principle, Tell, don't ask, Law of Demeter
C118 Die Clean Code Praktiken sind bekannt und werden fallabhängig angewendet.
Praktiken: Die Pfadfinderregel beachten, Root Cause Analysis, Täglich reflektieren, Issue Tracking, Automatisierte Integrationstests, Lesen (Fortbildung), Reviews, Automatisierte Unit-Tests, Mockups (Testattrappen), Code Coverage Analyse, Teilnahme an Fachveranstaltungen, Komplexe Refaktorisierungen, Continuous Integration, Statische Codeanalyse (Metriken), Inversion of Control Container, Messen von Fehlern, Continuous Delivery, Iterative Entwicklung, Komponentenorientierung, Test first
Tags: Automatisierung Disziplin Nachhaltigkeit Qualität Stabilität
C025 Drittanbieterkomponenten werden ausschließlich über Schnittstellen referenziert (Stichpunkt: Dependency-Inversion, Fassade).
Beispiel: Für die Nutzung von Drittanbieterbibliotheken werden Wrapperklassen implementiert und entsprechende Schnittstellen bereitgestellt.
C026 Schnittstellen können separat, ohne Referenz auf die konkrete Implementierung, referenziert werden.
Beispiel: Interface liegt in DLL Platform.Common und die Implementierung in DLL Platform.Common.Database.
C037 Parameter werden einheitlich durch zentrale Mechanismen validiert.
Beispiel: Regex-Verzeichnis und Assert-Klassen.
C038 Nutzereingaben werden sowohl auf Client- als auch auf Serverseite validiert.
Beispiel: Textlängen, Enumerationen, Pattern...
Tags: Nachhaltigkeit Qualität Stabilität
C039 Für alle Enumerationen sind Default-Werte definiert.
Beispiel: Der Default-Wert nach Initialisierung sollte "Undefined" sein.
Tags: Nachhaltigkeit Qualität
C040 Die Detailstufe des technische Protokolls ist konfigurierbar und die Implementierung spiegelt das Konzept wieder.
Beispiel: Unterscheidung zwischen Verbose, Info, Warning und Error.
C013 Für die Übernahme von Codeänderungen in den Hauptzweig des Code-Repositorys wird das Vier-Augen-Prinzip oder ein ähnliches Verfahren angewendet.
Beispiel: Pull-Request Verfahren mit verpflichtendem Review durch den Author und mindestens eine weitere Person.
C017 Jede Komponente ist für sich isoliert durch automatisierte Regessionstests abgedeckt.
Beispiel: Unit-Tests
C019 Alle Komponenten sind integrativ durch automatisierte Funktionstests abgedeckt.
Beispiel: Integrationstests
C020 Die Testabdeckung durch Komponententests wird regelmäßig analysiert und findet im Entwicklungsprozess Beachtung.
Beispiel: Unit-Test Abdeckung zur Identifizierung von ungetestetem Codeabschnitten.
C021 Sämtliche Fallunterscheidungen sind ausnahmslos von Unit-Tests abgedeckt.
Beispiel: Messung durch statische Code-Analyse und Code-Coverage.
Tags: Disziplin Nachhaltigkeit Qualität
C022 Alle automatisierten Tests sind nach einem einheitlichen Muster benannt.
Anmerkung: Erleichtert das Interpretieren von Testergebnissen.
C027 Für alle benutzten Komponenten von Drittanbieterbibliotheken sind Unit-Tests implementiert, welche das erwartete Verhalten sicherstellen.
Anmerkung: Alle Erwartungen an das Verhalten einer Library können so nach einem Versionsupdate verifiziert werden.
Tags: Disziplin Nachhaltigkeit Qualität
C062 Es gibt Mechanismen zur Bereinigung alter Datenbestände.
Beispiel: Ein Reporting stellt alle Vorgänge zusammen, die "aktiv sind, vor zwei Jahren erstellt und seit einem Jahr nicht mehr aktualisiert wurden".
C048 Für Datenbankoperationen wird ein einheitliches Transaktionskonzept verwendet.
Beispiel: Eine zentrale Komponente stellt Transaktionen bei entsprechenden Datenbankoperation sicher.
Tags: Disziplin Nachhaltigkeit Qualität
C049 Sämtliche eingehende Daten werden seitens der Datenbank validiert.
Beispiel: Explizite typisierung parametrisierter Datenbankprozeduren.
C050 Die Datenintegrität ist sichergestellt.
Beispiel: Datenbank-Constrains, fehlertolerante Datenstrukturen (z.B. Faktenorientierte Datenmodelle)
Tags: Nachhaltigkeit Qualität
C051 Alle Datenbankoperationen sind durch integrative, automatisierte Tests abgedeckt.
Beispiel: Integrationstests/Systemtests
C059 Fortlaufende IDs werden nicht von der Applikation, sondern von dem Datenbanksystem generiert.
Anmerkung: Falls möglich sollten UUIDs bevorzugt werden, da diese nur schwer erraten werden können.
C081 Sämtliche Methodensignaturen sind vollständig per XML-Kommentar dokumentiert.
Beispiel: Summary, Parameter, Result, (Code-Snippets)
C082 Die Releasenotes werden durch das komplette Team in fachlicher Sprache verfasst, nachdem Features implementiert und getestet sind.
Beispiel: Releasenotes nach dem täglichen Standup aktualisieren und für das gesamte Team transparent machen.
Tags: Disziplin Kundenorientierung Nachvollziehbarkeit Qualität
C098 API Dokumentationen werden über den Release-Prozess automatisch bereitgestellt und aktualisiert.
Beispiel: Die API Dokumentation ist Teil der Anwendung.
C101 Die Patchfähigkeit für verschiedene Release-Versionen der Applikation ist gegeben.
Beispiel: Release-Branches oder Tags (Git).
Kontakt: mail@jannis-kuehn-consulting.de
Dokument: https://old.k-drummer.de/SoftwareProjectReviewGuide
Impressum: https://old.k-drummer.de/
Guide Version: 1.2.8 (09.06.2020)
Major: Große strukturelle Änderungen
Minor: Nummern neu vergeben (z.B. C053 auf C065)
Patch: Neue Kapitel, Neue Einträge, Textanpassung, Reihenfolge
Last Page Update: 06.01.2021
Guides
Agile Projects: https://old.k-drummer.de/AgileProjectReviewGuide
Software Projects: https://old.k-drummer.de/SoftwareProjectReviewGuide
Datenschutzerklärung:
Der Webserver protokolliert Seitenzugriffe und die IP-Adressen der Aufrufer. Diese Protokolle werden ausschließlich zur Fehlersuche ausgewertet. Da es auf dieser Seite keine Benutzerkonten oder Tracking-Cookies gibt, sind diese Daten keiner Person zuordenbar und werden damit als nicht Personenbezogen betrachtet. Abgesehen davon werden keine Daten erhoben, gespeichert oder ausgewertet.
© 2020 Jannis Kühn Rights Reserved