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

C003 Neue Funktionen können für definierte Anwendergruppen separat freigeschaltet werden, um Testphasen in Produktion zu ermöglichen.

Beispiel: Feature-Switches auf Ebene von Anwendergruppen.

Tags: Organisatorisch Stabilitä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

C008 Test- und Produktionsdaten sind voneinander getrennt.

Beispiel: Auf Testdaten angewendete Operationen haben keine Wirkung auf Produktionssysteme.

Tags: Organisatorisch Security Stabilität

Änderung vorschlagen

C010 Test- und Produktionssysteme sind voneinander getrennt.

Anmerkung: Fehler und Systemabstürze in der Testumgebung haben so keine Auswirkung auf das operative Geschäft.

Tags: 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

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

C038 Nutzereingaben werden sowohl auf Client- als auch auf Serverseite validiert.

Beispiel: Textlängen, Enumerationen, Pattern...

Tags: Nachhaltigkeit Qualität Stabilität

Änderung vorschlagen

C123 Session-Timeouts sind explizit gesetzt.

Beispiel: Keine Verwendung von Standardkonfiguration, sondern explizite Angabe der Gültigkeitsdauer.

Tags: Nachvollziehbarkeit Stabilität

Änderung vorschlagen

2.1 Versionskontrolle

2.2 Fehlerbehandlung

2.3 Tests

2.4 Abhängigkeiten

C023 Alle eingebundenen Bibliotheken sind auf dem neusten Versionsstand.

Beispiel: Prüfung durch Nuget Package Manager

Tags: Security Stabilität

Änderung vorschlagen

3Daten

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

C053 Die Rollback-Fähigkeit von Datenbankänderungen ist sichergestellt.

Beispiel: Rollback-Skripts zu jedem Update.

Tags: Stabilität

Änderung vorschlagen

C054 Die Verfügbarkeit und Ausfallsicherheit der Datenbank ist sichergestellt.

Beispiel: Replikation der Datenbank auf mehrere Hosts durch das Datenbanksystem.

Tags: Stabilität

Änderung vorschlagen

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.

Tags: Nachhaltigkeit Qualität Security Stabilität

Änderung vorschlagen

C061 Die Anwendung funktioniert mit der vorherigen Datenbankversion (n-1).

Beispiel: Die Verfügbarkeit von neuen Prozeduren/Tabellen/Spalten wird vor der Verwendung geprüft (z.B. über die Versionsnummer der Datenbank).

Tags: Stabilität

Änderung vorschlagen

4Dokumentation

C083 Postfächer, Telefonnummern und Kontakte von zuarbeitenden Stellen sind dokumentiert, aktuell und zentral abgelegt.

Beispiel: Kontaktinformationen zu Firewall-, Netzwerk-, Plattformteams und zu wichtigen Stakeholdern des Projekts.

Tags: Nachhaltigkeit Organisatorisch Stabilität

Änderung vorschlagen

C084 Alle ein- und ausgehenden Netzwerkverbindungen der Applikation sind dokumentiert.

Beispiel: Netzwerkadresse des Zielsystems, Netzwerkkonfiguration (Proxy, etc.), Fachliche Beziehungen, Abhängigkeiten, Kritikalität bei Ausfall der Verbidung.

Tags: Nachhaltigkeit Nachvollziehbarkeit Organisatorisch Security Stabilität

Änderung vorschlagen

4.1 Logging

5Bereitstellung

5.1 Build

C088 Ein CI-Build existiert und verhindert die Übernahme von nicht-kompilierbarem Code in die Hauptzweige des Repositories.

Beispiel: CI-Build Policy für Pull-Requests gegen Hauptzweige (z.B. Master).

Tags: Automatisierung Organisatorisch Stabilität

Änderung vorschlagen

C092 Für Änderungen an den Build-Agents gibt es ein Rollback-Konzept.

Beispiel: Bereitstellung von versionierten Build-Agent-Pools.

Tags: Organisatorisch Stabilität

Änderung vorschlagen

5.2 Deployment

C089 Ein CI-Deployment existiert und verhindert die Übernahme von nicht-deploybarem Code in die Hauptzweige des Repositories.

Beispiel: CI-Release nach allen CI-Builds der Pull-Requests gegen Hauptzweige (z.B. Master).

Tags: Automatisierung Organisatorisch Stabilität

Änderung vorschlagen

C090 Eine automatisierte Prüfung der Version und des Patchlevels relevanter Systeme (Websever, Datenbanksystem, Host-System) ist Bestandteil des Deploymentprozesses.

Beispiel: Ein Deployment-Task prüft die Version des Ziel-Webservers auf > 7.0.

Tags: Automatisierung Stabilität

Änderung vorschlagen

C094 Für Änderungen an den Release-Agents gibt es ein Rollback-Konzept.

Beispiel: Bereitstellung von versionierten Release-Agent-Pools.

Tags: Organisatorisch Stabilität

Änderung vorschlagen

C096 Teil des Deployments ist die Sicherstellung, dass die Anwendung einen lauffähigen Status hat.

Beispiel: Ausführung von Alive-Tests als Deployment-Task.

Tags: Automatisierung Stabilität

Änderung vorschlagen

6Betrieb

C091 Die Verfügbarkeit und Ausfallsicherheit der Hostsysteme ist sichergestellt.

Beispiel: Replikation und automatisiertes Monitoring.

Tags: Organisatorisch Stabilität

Änderung vorschlagen

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

C106 Alle Systemkomponenten haben einen aktuellen Patch-Stand.

Beispiel: Datenbank, Webserver, Hostsystem, ...

Tags: Security Stabilität

Änderung vorschlagen

6.1 Monitoring

C107 Sämtliche Abhängigkeiten werden regelmäßig und automatisiert von der Applikation geprüft.

Beispiel: Monitoring für Erreichbarkeit und Verfügbarkeit von Web-Schnittstellen, Datenbanken, etc...

Tags: Automatisierung Stabilität

Änderung vorschlagen

C108 Das Monitoring der Applikation ist nicht oder nur in begrenztem Umfang öffentlich erreichbar.

Beispiel: Interne Monitoring-Schnittstellen sind öffentlich nicht erreichbar. Öffentliche Monitoring-Schnittstellen stellen keine detaillierten Fehlerinformationen bereit.

Tags: Architektur Nachhaltigkeit Organisatorisch Stabilität

Änderung vorschlagen

C109 Ein Benachrichtigungsprozess informiert über den Ausfall des Applikations-Monitorings.

Beispiel: Treffen in einem definierten Zeitraum keine neuen Logs ein, greift ein fest definierter Informationsprozess.

Tags: Automatisierung Organisatorisch Stabilität

Änderung vorschlagen

C110 Ein Benachrichtigungsprozess informiert über den Ausfall von geplanten Datenimporten, -exporten oder Nachtläufen.

Beispiel: Monitoring der Jobs und separate Kontrolle der Anzahl importierter Daten.

Tags: Automatisierung Nachhaltigkeit Organisatorisch Stabilität

Änderung vorschlagen

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: 05.08.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