Public Resources
k-develop

Software Project Review Guide (.NET)
Jannis Kühn

Vorschläge zur Sicherung der Qualität in agilen .NET Softwareprojekten.

Version 1.2.8

Feedback an jannis@k-develop.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

Tags: Architektur (8) Automatisierung (21) Disziplin (46) Kundenorientierung (14) Nachhaltigkeit (49) Nachvollziehbarkeit (33) Organisatorisch (53) Qualität (35) Security (36) Stabilität (32) (Filter zurücksetzen)


1Organisation

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

Änderung vorschlagen

C006 Bugs werden erfasst und immer mit höchster Priorität behoben.

Anmerkung: Jeder Bug in Produktion sollte als gleich wichtig und kritisch erachtet werden.

Tags: Disziplin Kundenorientierung Organisatorisch Security Stabilität

Änderung vorschlagen

2Entwicklung

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

Änderung vorschlagen

C032 Umfangreiche Refaktorisierungsmaßnahmen werden mit dem kompletten Team besprochen.

Beispiel: Durch die Verteilung der Information werden die Maßnahmen bei zukünftigen Implementierungen beachtet.

Tags: Disziplin Nachhaltigkeit Organisatorisch Security

Änderung vorschlagen

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

Änderung vorschlagen

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.

Tags: Disziplin Nachhaltigkeit Nachvollziehbarkeit Qualität

Änderung vorschlagen

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

Änderung vorschlagen

C121 Konfigurationsdateien enthalten ausschließlich verwendete Einträge. Nicht mehr genutzte Einträge werden konsequent aus den Dateien entfernt.

Beispiel: Obsolete Schlüssel-Wert-Paare, Verbindungszeichenfolgen, etc...

Tags: Disziplin Nachhaltigkeit Nachvollziehbarkeit Security

Änderung vorschlagen

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

Tags: Disziplin Nachhaltigkeit Qualität Stabilität

Änderung vorschlagen

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

Änderung vorschlagen

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.

Tags: Disziplin Qualität

Änderung vorschlagen

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.

Tags: Disziplin Qualität

Änderung vorschlagen

C029 Die technische und fachliche Schichtung ist einheitlich implementiert.

Beispiel: Innerhalb einer Anwendung folgen alle fachlich getrennten Web-Module dem MVC Pattern.

Tags: Architektur Disziplin

Änderung vorschlagen

C040 Die Detailstufe des technische Protokolls ist konfigurierbar und die Implementierung spiegelt das Konzept wieder.

Beispiel: Unterscheidung zwischen Verbose, Info, Warning und Error.

Tags: Disziplin Nachvollziehbarkeit Qualität

Änderung vorschlagen

2.1 Versionskontrolle

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.

Tags: Disziplin Organisatorisch Qualität Security

Änderung vorschlagen

C042 Sämtliche Commit-Messages sind ausdrucksstark formuliert und fassen sämtliche Änderungen zusammen.

Beispiel: "Updated .NET target version of all projects to 4.8" anstatt "Updated .NET".

Tags: Disziplin Nachvollziehbarkeit

Änderung vorschlagen

C043 Sämtliche Commit-Messages sind in derselben Sprache formuliert.

Beispiel: englisch.

Tags: Disziplin Nachvollziehbarkeit Organisatorisch

Änderung vorschlagen

C114 Verbindungszeichenfolgen und Geheimnisse sind nicht in das Code-Repository eingecheckt.

Beispiel: DB Connection-Strings, User-Credentials, OAuth Client-Secrets.

Tags: Disziplin Organisatorisch Security

Änderung vorschlagen

C124 Jeder darf Code hinzufügen, ändern, entfernen und dokumentieren.

Anmerkung: Der Code gehört dem Team, es gibt kein "Code-Ownership".

Tags: Disziplin Organisatorisch

Änderung vorschlagen

2.2 Fehlerbehandlung

2.3 Tests

C017 Jede Komponente ist für sich isoliert durch automatisierte Regessionstests abgedeckt.

Beispiel: Unit-Tests

Tags: Automatisierung Disziplin Nachhaltigkeit Qualität

Änderung vorschlagen

C018 Unit Tests erzeugen ein Ausführungsprotokoll, anhand dessen der detaillierte Verlauf des Tests nachvollzogen werden kann.

Beispiel: Sämtliche Logeinträge werden während des Testes in die Testausgabe geschrieben.

Tags: Disziplin Nachvollziehbarkeit

Änderung vorschlagen

C019 Alle Komponenten sind integrativ durch automatisierte Funktionstests abgedeckt.

Beispiel: Integrationstests

Tags: Automatisierung Disziplin Nachhaltigkeit Qualität

Änderung vorschlagen

C020 Die Testabdeckung durch Komponententests wird regelmäßig analysiert und findet im Entwicklungsprozess Beachtung.

Beispiel: Unit-Test Abdeckung zur Identifizierung von ungetestetem Codeabschnitten.

Tags: Disziplin Qualität

Änderung vorschlagen

C021 Sämtliche Fallunterscheidungen sind ausnahmslos von Unit-Tests abgedeckt.

Beispiel: Messung durch statische Code-Analyse und Code-Coverage.

Tags: Disziplin Nachhaltigkeit Qualität

Änderung vorschlagen

C022 Alle automatisierten Tests sind nach einem einheitlichen Muster benannt.

Anmerkung: Erleichtert das Interpretieren von Testergebnissen.

Tags: Disziplin Qualität

Änderung vorschlagen

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

Änderung vorschlagen

2.4 Abhängigkeiten

C024 Die Lizenzen von eingebundenen Bibliotheken und Referenzen sind geprüft und dokumentiert.

Anmerkung: Wenn genutzte Komponenten noch weitere Komponenten integrieren sind auch diese zu prüfen.

Tags: Disziplin Nachhaltigkeit Organisatorisch

Änderung vorschlagen

C028 Benötigte DLLs und Binarys werden per Paket-Manager eingebunden und nicht direkt aus dem Dateiverzeichnis referenziert.

Anmerkung: Voneinander abhängige DLLs sollten in einem Nuget-Package gebündelt werden.

Tags: Architektur Disziplin

Änderung vorschlagen

3Daten

C045 Sämtliche Daten sind nach geltenden Datenschutzrichtlinien klassifiziert.

Beispiel: Klassifizierung nach öffentlichen, internen, vertraulichen und geheimen Daten.

Tags: Disziplin Nachhaltigkeit Organisatorisch Security

Änderung vorschlagen

C047 Sämtliche Daten sind nach Kriterien der Verfügbarkeit organisiert.

Beispiel: Hochverfügbare Datenbestände sind von anderen Datenbeständen getrennt.

Tags: Architektur Disziplin Organisatorisch Stabilität

Änderung vorschlagen

3.1 Datenbanken

C048 Für Datenbankoperationen wird ein einheitliches Transaktionskonzept verwendet.

Beispiel: Eine zentrale Komponente stellt Transaktionen bei entsprechenden Datenbankoperation sicher.

Tags: Disziplin Nachhaltigkeit Qualität

Änderung vorschlagen

C049 Sämtliche eingehende Daten werden seitens der Datenbank validiert.

Beispiel: Explizite typisierung parametrisierter Datenbankprozeduren.

Tags: Disziplin Qualität Security

Änderung vorschlagen

C051 Alle Datenbankoperationen sind durch integrative, automatisierte Tests abgedeckt.

Beispiel: Integrationstests/Systemtests

Tags: Automatisierung Disziplin Nachhaltigkeit Qualität

Änderung vorschlagen

4Dokumentation

C068 Eigene APIs sind dokumentiert. Die Dokumentationen ist versioniert und Teil des Code-Repositorys.

Beispiel: Swagger oder ähnliche Produkte.

Tags: Disziplin Kundenorientierung Nachvollziehbarkeit

Änderung vorschlagen

C069 Die Dokumentation von genutzten Drittanbieter-APIs ist archiviert und Teil des Code-Repositorys.

Beispiel: Die Dokumentation der genutzten API Version ist zusammen mit dem Link zur aktuellen Dokumentation abgelegt.

Tags: Disziplin Nachhaltigkeit

Änderung vorschlagen

C070 Firewallregeln sind dokumentiert und werden bei jedem Release auf Notwendigkeit geprüft.

Anmerkung: Sollte eine Firewallregel nicht mehr notwendig sein, wird sie wieder entfernt.

Tags: Disziplin Nachhaltigkeit Security

Änderung vorschlagen

C081 Sämtliche Methodensignaturen sind vollständig per XML-Kommentar dokumentiert.

Beispiel: Summary, Parameter, Result, (Code-Snippets)

Tags: Disziplin Qualität

Änderung vorschlagen

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

Änderung vorschlagen

C125 Alle beteiligten Akteure eines Projektes sind mit entsprechender Rollenangabe dokumentiert.

Beispiel: Projektleiter, Entwickler, Kunden, Fachbereiche, Tester, etc...

Tags: Disziplin Nachvollziehbarkeit Organisatorisch

Änderung vorschlagen

4.1 Logging

C077 Fallunterscheidungen und durchlaufene Anwendungspfade können bei Bedarf vollständig im technischen Protokoll eingesehen werden.

Beispiel: Technisches Logging in Application Insights.

Tags: Disziplin Nachvollziehbarkeit

Änderung vorschlagen

C078 Datenbankoperationen und Ergebnisse können bei Bedarf vollständig im technischen Protokoll eingesehen werden.

Beispiel: Protokollierung von SQL-IN und SQL-OUT Dumps mit Ausschluss persönlicher Nutzerdaten.

Tags: Disziplin Nachvollziehbarkeit

Änderung vorschlagen

C080 Persönliche Nutzerinformationen (PII) sind in dem technischen Anwendungsprotokoll nicht enthalten.

Anmerkung: Auschluss von Adressen, Kontodaten und weiteren Identifikationsmerkmalen.

Tags: Disziplin Kundenorientierung Organisatorisch Security

Änderung vorschlagen

5Bereitstellung

C099 Die Dokumentation von Änderungen an den Firewall-Regeln ist Bestandteil des Release-Prozesses.

Beispiel: Firewall-Regeln werden in einem Release-Task gebrannt, dokumentiert und bei folgenden Releases nachhaltig auf Notwendigkeit geprüft.

Tags: Disziplin Nachhaltigkeit Nachvollziehbarkeit Organisatorisch

Änderung vorschlagen

5.1 Build

5.2 Deployment

6Betrieb

C103 Die Build-Agents werden regelmäßig gepatcht und laufen auf der aktuellen Version.

Beispiel: Teil jedes Sprints ist die Durchsicht der Release-Notes verwendeter Softwarekomponenten.

Tags: Disziplin Stabilität

Änderung vorschlagen

C104 Die Release-Agents werden regelmäßig gepatcht und laufen auf der aktuellen Version.

Beispiel: Teil jedes Sprints ist die Durchsicht der Release-Notes verwendeter Softwarekomponenten.

Tags: Disziplin Stabilität

Änderung vorschlagen

C105 Das Datenbanksystem wird regelmäßig gepatcht und läuft auf der aktuellen Version.

Beispiel: Teil jedes Sprints ist die Durchsicht der Release-Notes verwendeter Softwarekomponenten.

Tags: Disziplin Security Stabilität

Änderung vorschlagen

6.1 Monitoring

7Literatur


Kontakt: jannis@k-develop.de
Dokument: https://k-develop.de/SoftwareProjectReviewGuide
Impressum: https://k-develop.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: 26.06.2020

Guides
Agile Projects: https://k-develop.de/AgileProjectReviewGuide
Software Projects: https://k-develop.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