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 |
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
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
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
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.
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
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...
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
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
C119 Technische Schnittstellen sind durch gängige Authentifizierungsmechanismen abgesichert.
Beispiel: OAuth für Web-APIs.
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
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
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
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
C021 Sämtliche Fallunterscheidungen sind ausnahmslos von Unit-Tests abgedeckt.
Beispiel: Messung durch statische Code-Analyse und Code-Coverage.
Tags: Disziplin Nachhaltigkeit Qualität
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
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.
C045 Sämtliche Daten sind nach geltenden Datenschutzrichtlinien klassifiziert.
Beispiel: Klassifizierung nach öffentlichen, internen, vertraulichen und geheimen Daten.
C046 Persönliche Daten sind verschlüsselt abgelegt.
Beispiel: Kontaktinformationen, Zahlungsmittel, Geburtsdaten...
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
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
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.
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.
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".
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).
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
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
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.
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
C065 Das Branching-Konzept ist dokumentiert.
Beispiel: Git-Flow
C074 Für fachliche Anwendungsprotokolle sind Aufbewahrungsfristen definiert und sichergestellt.
Beispiel: Revisionsrelevante Einträge werden 10 Jahre aufbewahrt.
Tags: Nachhaltigkeit
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
C120 Sensible Sektionen der Konfiguration auf den Host-Systemen sind verschlüsselt.
Beispiel: Verschlüsselung durch ASPNET_REGIIS bei ASP.NET oder andere Verfahren.
C101 Die Patchfähigkeit für verschiedene Release-Versionen der Applikation ist gegeben.
Beispiel: Release-Branches oder Tags (Git).
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
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.
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
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
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
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
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