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)


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

C002 Dem Anwender wird eine Möglichkeit geboten, Feedback unkompliziert und schnell über die Benutzeroberfläche mitzuteilen.

Beispiel: Anonyme Eingabe von Anwenderfeedback jederzeit möglich (z.B. Freitextfeld mit verschiedenen Smileys zum auswählen), Feedbackkontext (z.B. Applikationsmodul) für den Anwender transparent.

Tags: Kundenorientierung Organisatorisch

Änderung vorschlagen

C129 Dem Anwender wird eine Möglichkeit geboten, Datenschutz- und Sicherheitsvorfälle unkompliziert und schnell über die Benutzeroberfläche zu melden.

Beispiel: Anonyme Meldung zu Datenschutz- und Sicherheitsvorfällen jederzeit möglich (z.B. Freitextfeld).

Tags: Kundenorientierung Nachhaltigkeit Organisatorisch Security

Änderung vorschlagen

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

C004 Die Releaseplanung ist nach außen transparent.

Beispiel: Kunden können sich jederzeit über bereitgestellte und geplante Versionen informieren.

Tags: Kundenorientierung Nachhaltigkeit Nachvollziehbarkeit Organisatorisch

Änderung vorschlagen

C005 Ein Feedbackprozess ermöglicht dem Kunden Einflussnahme auf die Releaseplanung.

Beispiel: Einbindung des Kunden in den Planungsprozess durch Agile Methoden oder andere Feedbackprozesse.

Tags: Kundenorientierung Organisatorisch

Ä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

C007 Bei Ausfall von Abhängigkeiten informiert die Applikation den Nutzer automatisch an passender Stelle und gibt Hinweise zu weiteren Schritten.

Beispiel: Der Nutzer erhält bei dem Ausfall der Datenbank einen für ihn verständlichen Hinweis mit zuständigen Ansprechpartnern.

Tags: Automatisierung Kundenorientierung Organisatorisch

Ä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

C009 Testdaten sind anonymisiert und enthalten keine zuordenbare Nutzerinformationen.

Anmerkung: Datenschutz und diskreter Umgang mit Anwenderdaten.

Tags: Organisatorisch Qualität Security

Ä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

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

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

Änderung vorschlagen

C033 Statische Codeanalysen werden regelmäßig und automatisiert durchgeführt und fließen in den Entwicklungsprozess ein.

Beispiel: Sonarqube integriert im CI-Build

Tags: Automatisierung Nachhaltigkeit Qualität Security

Ä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

C116 Alle verwendeten kryptografischen Verfahren gelten nach derzeitigem Stand als geeignet für den entsprechenden Anwendungsfall.

Beispiel: Hashing, Verschlüsselung, Zertifikate, etc...

Tags: Nachhaltigkeit Security

Änderung vorschlagen

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

Ä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

C119 Technische Schnittstellen sind durch gängige Authentifizierungsmechanismen abgesichert.

Beispiel: OAuth für Web-APIs.

Tags: Nachhaltigkeit Organisatorisch Security

Ä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

C036 Passwörter und Verbindungszeichenfolgen sind ausschließlich verschlüsselt abgelegt.

Beispiel: Verschlüsselte Variablen in der Library auf Azure-Pipelines.

Tags: Organisatorisch Security

Änderung vorschlagen

C037 Parameter werden einheitlich durch zentrale Mechanismen validiert.

Beispiel: Regex-Verzeichnis und Assert-Klassen.

Tags: Qualität Security

Ä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

C039 Für alle Enumerationen sind Default-Werte definiert.

Beispiel: Der Default-Wert nach Initialisierung sollte "Undefined" sein.

Tags: Nachhaltigkeit Qualität

Änderung vorschlagen

C126 Sitzungsidentifikatoren werden nach einer bestimmten Zeit Inaktivität ungültig.

Beispiel: Aktualisierung der Session-Cookies bei jeder Aktivität des Nutzers.

Tags: Nachhaltigkeit Security

Änderung vorschlagen

C127 Sitzungen werden nach einer konfigurierbaren Zeit ungültig.

Beispiel: Session-Cookies haben eine absolute Gültigkeit, unabhängig von der Aktivität des Nutzers.

Tags: Nachhaltigkeit Security

Änderung vorschlagen

C128 Sitzungsidentifikatoren werden nach erneutem Anmelden erneuert.

Beispiel: Neue SessionID.

Tags: Nachvollziehbarkeit Security

Ä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

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

C041 Bei der Verarbeitung von Texten ist die Kodierung immer explizit angegeben.

Beispiel: Für das Lesen und Schreiben von Daten wird explizit UTF-8 verwendet.

Tags: Nachvollziehbarkeit Security

Änderung vorschlagen

C044 Persönliche, vertrauliche und geheime Daten werden ausschließlich verschlüsselt übertragen.

Beispiel: Verschlüsselung oder Tunneling bei relevanten Datenübermittlungen, z.B. HTTPS bei REST-Anfragen.

Tags: Nachvollziehbarkeit Organisatorisch

Änderung vorschlagen

2.1 Versionskontrolle

C011 Sämtliche Codeänderungen werden durch ein Versionskontrollsystem verwaltet.

Beispiel: Git

Tags: Nachvollziehbarkeit

Änderung vorschlagen

C012 Das Branchingkonzept ist jedem Teammitglied bekannt und wird angewendet.

Beispiel: Git-Flow

Tags: Organisatorisch

Änderung vorschlagen

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

C014 Die Behandlung fehlerhafter Nutzereingaben ist in einer der technischen Schichten konzentriert.

Beispiel: Sämtliche Fehlerbehandlung in Bezug auf Nutzereingaben findet vollständig in der Front-End-Layer statt.

Tags: Architektur

Änderung vorschlagen

C015 Die Behandlung fachlicher Fehler (z.B. Datensatz mit falschem Status) ist in einer der technischen Schichten konzentriert.

Beispiel: Fachliche Fehler werden nur in der Business-Layer der Applikation behandelt.

Tags: Architektur

Änderung vorschlagen

C016 Die Behandlung technischer Fehler (z.B. Netzwerkstörungen) ist in einer der technischen Schichten konzentriert.

Beispiel: Exception Handling von technischen Fehlern nur in der Serviceschicht der Applikation.

Tags: Architektur

Änderung vorschlagen

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

C023 Alle eingebundenen Bibliotheken sind auf dem neusten Versionsstand.

Beispiel: Prüfung durch Nuget Package Manager

Tags: Security Stabilität

Änderung vorschlagen

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

C046 Persönliche Daten sind verschlüsselt abgelegt.

Beispiel: Kontaktinformationen, Zahlungsmittel, Geburtsdaten...

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

C058 Timestamps enthalten eine Angabe zur Zeitzone.

Anmerkung: Der verwendete Datentyp sollte die Angabe einer Zeitzone sicherstellen.

Tags: Nachvollziehbarkeit Organisatorisch

Änderung vorschlagen

C060 Für die Abfrage von Datensätzen, durch externe Komponenten oder Benutzer der Applikation, wird als Identifikationsmerkmal keine fortlaufende, nummerische ID verwendet.

Beispiel Eine UUID als Identifikationsmerkmal kann nur schwer erraten werden.

Tags: Organisatorisch Security

Änderung vorschlagen

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".

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

C050 Die Datenintegrität ist sichergestellt.

Beispiel: Datenbank-Constrains, fehlertolerante Datenstrukturen (z.B. Faktenorientierte Datenmodelle)

Tags: Nachhaltigkeit Qualität

Änderung vorschlagen

C051 Alle Datenbankoperationen sind durch integrative, automatisierte Tests abgedeckt.

Beispiel: Integrationstests/Systemtests

Tags: Automatisierung Disziplin Nachhaltigkeit Qualität

Änderung vorschlagen

C052 Das Staging-Konzept wird auch auf die Datenbankumgebung angewendet.

Beispiel: Entwicklung, Integration (CI), Public

Tags: Organisatorisch

Änderung vorschlagen

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

C055 Zum Lesen und Schreiben von Daten existieren separate Datenbankbenutzer.

Beispiel: Die Applikation "Sample" benutzt die DB-User "app_sample_read" und "app_sample_write". Aus dem Namen des DB-Users lässt sich die zugehörige Applikation ableiten.

Tags: Nachvollziehbarkeit Organisatorisch Security

Änderung vorschlagen

C056 Jede Komponente nutzt eigene Datenbankbenutzer mit entsprechend eingeschränkten Rechten.

Beispiel: Jedes fachlich getrennte Modul erhält einen "read" und einen "write" DB-User. Aus dem Namen des DB-Users lässt sich das zugehörige Applikationsmodul ableiten.

Tags: Nachvollziehbarkeit Organisatorisch Security

Änderung vorschlagen

C057 CRUD Operationen werden von der Datenbank ausschließlich über Funktionen, Prozeduren und Views bereitgestellt. Die Applikation hat keinen direkten Zugriff auf einzelne Tabellen und besitzt keine "Kenntnis" über die interne Tabellenstruktur.

Anmerkung: Insbesondere die richtige Anwendung von typisierten Parametern verhindert die meisten Angriffe per SQL-Injection.

Tags: Nachhaltigkeit Organisatorisch Security

Ä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

C063 Datenbanken sind so konfiguriert, dass sie in den Produktiven Umgebungen nicht auf Anfragen zu Instanzinformationen antworten.

Beispiel: MS SQL "Hidden SQL Server Instance" oder "Turn off SQL Server Browser".

Tags: Nachhaltigkeit Organisatorisch Security

Änderung vorschlagen

C064 Die Anmeldung von globalen Root-Usern an einem Datenbanksystem ist nur von bestimmten Systemen aus erlaubt.

Beispiel: Einschränkung auf 127.0.0.1 (localhost).

Tags: Nachhaltigkeit Organisatorisch Security

Änderung vorschlagen

4Dokumentation

C066 Ein Versionsprotokoll (Changelog) ist in fachlicher Sprache vorhanden und über die Applikation erreichbar.

Beispiel: Build-In Changelog oder Verlinkung auf Web-Page.

Tags: Kundenorientierung Nachvollziehbarkeit

Änderung vorschlagen

C067 Die Versionsnummer und das Environment der Applikation ist in jeder Ansicht sichtbar.

Beispiel: Ausgabe der Daten im Fixed-Footer/-Header einer Web-Application. Wichtig: Die Angabe ist auf jedem Screenshot sichtbar.

Tags: Nachvollziehbarkeit

Änderung vorschlagen

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

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

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

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

Tags: Disziplin Nachvollziehbarkeit Organisatorisch

Ä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

C065 Das Branching-Konzept ist dokumentiert.

Beispiel: Git-Flow

Tags: Nachhaltigkeit Nachvollziehbarkeit

Änderung vorschlagen

4.1 Logging

C071 Für einzelne Features werden bedarfsorientierte Nutzungsstatistiken erhoben.

Beispiel: Wissen um wenig oder häufig genutzte Features und Identifizierung von nicht genutzen Features.

Tags: Nachvollziehbarkeit

Änderung vorschlagen

C072 Es gibt eine fachliche Protokollierung von Vorgängen.

Beispiele: Anmeldung, Vertragsabschluss, Bearbeitungsverlauf

Tags: Nachvollziehbarkeit Organisatorisch

Änderung vorschlagen

C073 Alle fachlichen Anwendungsprotokolle sind auch ohne IT-Hintergrund verständlich.

Beispiel: 2019-01-03 08:22:31 Erfolgreiche Anmeldung an "OnlineBanking" (Methode: "Passwortzugang")

Tags: Kundenorientierung Nachvollziehbarkeit

Änderung vorschlagen

C074 Für fachliche Anwendungsprotokolle sind Aufbewahrungsfristen definiert und sichergestellt.

Beispiel: Revisionsrelevante Einträge werden 10 Jahre aufbewahrt.

Tags: Nachhaltigkeit

Änderung vorschlagen

C075 Jeder fachliche Logeintrag beinhaltet die Versionsnummer und das Environment der Applikation.

Anmerkung: So ist bei jedem übermittelten Logeintrag transparent, an welchser Stelle der Logeintrag geschrieben wurde.

Tags: Nachvollziehbarkeit

Änderung vorschlagen

C076 Es gibt eine technische Protokollierung von Vorgängen.

Beispiel: Technisches Logging in Application Insights.

Tags: Nachvollziehbarkeit

Änderung vorschlagen

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

C079 Jeder technische Logeintrag beinhaltet die Versionsnummer und das Environment der Applikation.

Anmerkung: So ist bei jedem übermittelten Logeintrag transparent, an welchser Stelle der Logeintrag geschrieben wurde.

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

C098 API Dokumentationen werden über den Release-Prozess automatisch bereitgestellt und aktualisiert.

Beispiel: Die API Dokumentation ist Teil der Anwendung.

Tags: Automatisierung Organisatorisch Qualität

Änderung vorschlagen

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

C100 Anwender werden über die Bereitstellung neuer Versionen informiert und auf das fachliche Versionsprotokoll verwiesen.

Beispiel: Hinweis bei Erstanmeldung nach Featureupdate.

Tags: Kundenorientierung Nachvollziehbarkeit

Änderung vorschlagen

C097 Die Bereitstellung von Datenbankanpassungen ist automatisiert.

Beispiel: Das Einspielen von Skripts in die Datenbanksysteme ist ein automatischer Teil des Bereitstellungsprozesses.

Tags: Automatisierung

Änderung vorschlagen

5.1 Build

C085 Der Build erfolgt automatisiert über einen Build-Agent.

Beispiel: Azure DevOps (Azure Pipelines)

Tags: Automatisierung

Änderung vorschlagen

C086 Fehlende technische Dokumentation zu Anwendungskomponenten erzeugt einen Fehler im Release-Build.

Beispiel: Fehlende XML-Summary an einer Klasse erzeugt einen Build-Fehler.

Tags: Qualität

Änderung vorschlagen

C087 Jede beliebige Code-Version kann jederzeit "per Knopfdruck" durch den Buildserver gebaut werden.

Beispiel: Build-Definition in Azure-Pipelines.

Tags: Automatisierung Organisatorisch

Änderung vorschlagen

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

C095 Ein Release-Build kann jederzeit "per Knopfdruck" bereitgestellt werden.

Beispiel: Release-Definition in Azure Pipelines (Azure DevOps)

Tags: Automatisierung

Ä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

C093 Das Deployment erfolgt automatisiert über einen Release-Agent.

Beispiel: Azure DevOps (Azure Pipelines)

Tags: Automatisierung

Ä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

C120 Sensible Sektionen der Konfiguration auf den Host-Systemen sind verschlüsselt.

Beispiel: Verschlüsselung durch ASPNET_REGIIS bei ASP.NET oder andere Verfahren.

Tags: Automatisierung Nachhaltigkeit Security

Änderung vorschlagen

6Betrieb

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

Beispiel: Replikation und automatisiertes Monitoring.

Tags: Organisatorisch Stabilität

Änderung vorschlagen

C101 Die Patchfähigkeit für verschiedene Release-Versionen der Applikation ist gegeben.

Beispiel: Release-Branches oder Tags (Git).

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

C102 Die tatsächlich genutzten Versionen der Applikation können für beliebige Zeiträume ermittelt werden.

Beispiel: Protokollierung der Versionsnummer bei Nutzung und Sicherstellung einer angemessenen Aufbewahrungsfrist der Information.

Tags: Kundenorientierung Nachhaltigkeit Nachvollziehbarkeit Organisatorisch

Änderung vorschlagen

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

C111 Empfohlene Literatur: "unbedingt empfohlen"

- Adaptive Code via C#: Agile coding with design patterns and SOLID principles (Gary McLean Hall) (Oktober 2014)
- The Art of Unit Testing: With Examples in C# (Roy Osherove) (Dezember 2013)
- Agile Estimating and Planning (Mike Cohn) (November 2005)
- Working Effectively with Legacy Code (Michael Feathers) (Januar 2013)
- Extreme Programming Explained: Embrace Change: Embracing Change (Kent Beck, Cynthia Andres) (November 2004)
- Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin) (August 2008)

Tags: Nachhaltigkeit

Änderung vorschlagen

C112 Empfohlene Literatur: "Nice to know"

- Clean Agile - Back to Basics (Robert C. Martin) (Oktober 2019)
- The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin) (Mai 2011)
- Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin) (September 2017)
- The Software Craftsman: Professionalism, Pragmatism, Pride (Robert C. Martin) (Dezember 2014)
- Design Patterns für die Spieleprogrammierung (Robert Nystrom) (August 2015)
- Big Data: Entwicklung und Programmierung von Systemen für große Datenmengen und Einsatz der Lambda-Architektur (Nathan Marz, James Warren) (September 2016)
- Langlebige Software-Architekturen: Technische Schulden analysieren, begrenzen und abbauen (Carola Lilienthal) (Dezember 2015)
- REST und HTTP: Entwicklung und Integration nach dem Architekturstil des Web (Stefan Tilkov, Martin Eigenbrodt, Silvia Schreier, Oliver Wolf) (April 2015)
- Data Warehouse Technologien (Veit Köppen, Gunter Saake, Kai-Uwe Sattler) (Mai 2014)
- Versionsverwaltung mit Git (Sujeevan Vijayakumaran) (Juli 2016)
- Software-Sanierung: Weiterentwicklung, Testen und Refactoring bestehender Software (Sebastian Kübeck) (September 2009)
- Informationsmodellierung: Durch Verstehen zu besserer Software (Stefan Berner) (August 2016)

Tags: Nachhaltigkeit

Änderung vorschlagen

C113 Empfohlene Literatur: "Sammlungen und Nachschlagewerke"

- Refactoring: Improving the Design of Existing Code (Martin Fowler) (November 2018)
- Design Patterns: Entwurfsmuster als Elemente wiederverwendbarer objektorientierter Software (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides) (Mai 2014)
- Pro ASP.NET Web API Security: Securing ASP.NET Web API (Badrinarayanan Lakshmiraghavan) (März 2013)

Tags: Nachhaltigkeit

Änderung vorschlagen


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