1.0
Aspekte, die im Rahmen der Durchführung des Lehrprojektes von besonderer Bedeutung sind:
Risiken, die den Projektfortschritt/-plan betreffen.
Beispiele:
Ausfall von Personal
Ausfall der Server(-infrastruktur)/des GIT Server
...
Risiken, die die Qualität/Performance des Produktes betreffen.
Beispiele:
Anforderungen sind unvollständig, nicht-richtig erfasst oder ändern sich
Spezifikation verzögert
Eingesetzte Bibliotheken, Frameworks, etc. entsprechen nicht den Erwartungen
...
Erstellen Sie für Ihr Projekt ein Risikomanagementplan. d. h. betrachten Sie nur solche, die im Rahmen Ihres Projekts tatsächlich auftreten können.
Identifizieren und bewerten Sie mögliche Risiken
Beschreiben Sie für Risiken, die eine hohe Eintrittswahrscheinlichkeit haben, wie sie diesen Risiken begegnen; d. h. wie Ihre Strategie aussieht.
Dokumentieren Sie die grundlegende Architektur Ihrer Anwendung.
Bedenken Sie auch die nicht-funktionalen Eigenschaften, die von der Architektur mit- bzw. maßgeblich beeinflusst werden:
Reaktionsgeschwindigkeit responsiveness (Gibt es die Resultate in der erwarteten Zeit?)
Zuverlässigkeit reliability (Verhält es sich wie erwartet?)
Verfügbarkeit availability (Ist das System verfügbar, wenn es gebraucht wird?)
Sicherheit security (Wie werden Nutzer identifiziert? Wo werden welche Daten wie gespeichert?)
Benutzerfreundlichkeit usability
Wartbarkeit maintainability (Beheben von Fehlern/welche (Arten von) Erweiterungen sind vorgesehen?)
Resilienz resilience (Verhalten bei Teilausfall?)
Nicht-funktionale Anforderungen
Sicherheitskonzept (Welche Angriffe sind möglich? Welche Sicherheit (vor wem) wollen wir garantieren? ...)
Datenkonzept (Länge von Nachrichten? Bilder? Videos? ... Eventual Consistency?)
Datenschutzkonzept (Wo werden die Nachrichten gespeichert? Wer darf die Nachrichten einsehen? Umgang mit illegalen Inhalten?)
...
Einige Fragen können rein rechtlicher Natur sein. Andere haben jedoch konkrete Auswirkungen auf die Entwicklung oder den Betrieb.
Auf Tausenden von Windows-Rechnern weltweit ist der Bluescreen of Death zu sehen. Neben Privatpersonen und Firmen sind auch Banken, Krankenhäuser und Flughäfen betroffen. Es entsteht ein Milliardenschaden. [...]
[...] Juli 2024 - Das CrowdStrike Desaster - Wenn Sicherheitssoftware zur Gefahr wird
Wo fehlten die Qualitätsmaßnahmen (mind./vermutlich)?
passende QS Maßnahmen fehlten (vermutlich) bei der Entwicklung
passende QS Maßnahmen fehlten vor dem Rollout
Auswahl von Qualitätszielen
Es ist Ihre Aufgabe die/das wirklich Wichtigste QM Ziel zu identifizieren, und für dieses eine entsprechende Planung durchzuführen, die es Ihnen ermöglicht das Ziel im Rahmen des Projektes aus zu erreichen. Bedenken Sie die Projektdauer und Ihre Möglichkeiten.
Qualitätsmaßnahmen leben (und dokumentieren)
Beleg und Präsentation der durchgeführten Qualitätsmaßnahmen
Qualitätsziel: Sichere Webanwendung |
|
|---|---|
Projektspezifische Motivation |
Im Rahmen des Projektes … wird eine Webanwendung entwickelt, auf die über das Internet zugegriffen wird. Da diese Anwendung … personenbezogene Daten verarbeitet und potentiellen Angriffen ausgesetzt ist, ist ein wesentliches Qualitätsziel, dass die Anwendung keine Sicherheitslücken aufweist über die Angreifer Daten anderer Benutzer abgreifen können. |
Umfang Scope |
Im Rahmen dieses Projektes können wir jedoch nur gewährleisten, dass die Webanwendung keine „Standardlücken“ wie zum Beispiel SQL Injection aufweist. Um dieses Ziel zu erreichen, setzen wir die folgenden Tools: … ein. |
Durch wen/wann? |
Darüber hinaus wurde ein Entwickler benannt, der sich maßgeblich um das Thema „Sicherheit in Webanwendungen“ kümmert und … |
Wie wird reagiert? |
Die automatisierte Analyse des Codes der Webanwendung erfolgt im Rahmen des regelmäßigen „Nightly Builds“. Sollte ein Problem gefunden werden, so geht eine Mail an alle Entwickler und im Rahmen des nächsten (gruppeninternen) Meetings wird dann ein Entwickler bestimmt, der den Fehler beseitigt. |
Die Abgabe muss belegen, dass die beschriebenen Qualitätsmaßnahmen und Prozesse auch durchgeführt wurden.
Es ist darauf zu achten, dass
erkenntlich ist, dass der Prozess eingehalten wurde (d. h. wann und wie häufig etwas getan wurde) und auch, dass
die Maßnahmen im beschriebenen Umfang durchgeführt wurden.
Wurde als QS Maßnahme automatisierte Tests geplant, so ist die vollständige Liste der Tests abzugeben und es ist zu belegen welche Teile des Codes getestet wurden. Weiterhin ist die Relation der Tests zu den User Stories zu zeigen.
Dies kann insbesondere dadurch geschehen, dass ein Auszug eines Codeabdeckungstools gezeigt wird; z. B. aggregiert auf Klassen-/Dateiebene.
Bitte halten Sie die Möglichkeit vor die Testsuite im Rahmen der Abschlusspräsentation zu zeigen.
Die Abgabe soll zeigen wann diese Studie(n) von wem und mit welchen Probanden durchgeführt wurde und wie der genaue Ablauf war.
Wurden den Probanden Aufgaben geben und diese danach gebeten einen Fragebogen auszufüllen? Fand ein (geschlossenes/offenes) Interview statt? Wurden die Probanden nur beobachtet?
Insbesondere ist kurz zu präsentieren, welche Ergebnisse aus der Benutzerstudie abgeleitet wurden und welche Konsequenzen gezogen wurden.
Ist eine Maßnahme, die versprochen wurde, dass der Code dokumentiert wurde, so ist hier ein Auszug des Codes zu zeigen.
Die gezeigten Dateien sollten repräsentativ für das Projekt sein. Die gewählten Dateien müssen weiterhin von herausgehobener Bedeutung für das Projekt sein.
Der restliche Code sollte vorgehalten werden, falls im Rahmen der Präsentation Rückfragen kommen.
Falls die geplante Maßnahme systematische Code Reviews waren, dann ist diesbezüglich die Checkliste zu zeigen, auf die die Reviewer zu achten hatten.
Weiterhin ist exemplarisch ein Stück Code zu zeigen, der den Prozess durchlaufen hat.
Der weitere Code ist vorzuhalten, um ggf. im Rahmen der Präsentation die Effektivität der Maßnahme zu belegen. Sollten nicht alle Teile einem Review unterzogen worden sein, so ist dies im Vorfeld - ohne Aufforderung - im Rahmen der Präsentation zu erklären.
Stabile Builds
Um stabile Builds zu erhalten ist es notwendig, dass ...
die Laufzeitumgebung(en) fest definiert ist
alle Einstellungen festgelegt sind (insbesondere die Compiler-Einstellungen)
alle Abhängigkeiten wohl definiert (inkl. Versionsnummer) sind:
Abhängigkeiten zum Build-System
Abhängigkeiten zu den verwendeten Bibliotheken
Abhängigkeiten zu den verwendeten Tools
Codeabdeckung
Quellcode Formatierung
Überprüfung des Stils
(Lightweight) bug detection
Dokumentationsgenerierung
Packaging
Überprüfung auf veraltete Bibliotheken und Werkzeuge
Generierung der Webseite
Veröffentlichung (zum Beispiel in einem Repository, auf einem Webserver, ...) und/oder Deployment