Aspekte der Projektdurchführung

Prof. Dr. Michael Eichberg

michael.eichberg@dhbw-mannheim.de

Übersicht

Aspekte, die im Rahmen der Durchführung des Lehrprojektes von besonderer Bedeutung sind:

Risikomanagement

Kategorien von Risiken (hier)

Projektrisiken:

Risiken, die den Projektfortschritt/-plan betreffen.

Beispiele:

  • Ausfall von Personal

  • Ausfall der Server(-infrastruktur)/des GIT Server

  • ...

Produktrisiken:

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

  • ...

Risikomanagementplan

Erstellen Sie für Ihr Projekt ein Risikomanagementplan. d. h. betrachten Sie nur solche, die im Rahmen Ihres Projekts tatsächlich auftreten können.

Architektur

Architektur und nicht-funktionale Anforderungen

Beispielhafte Fragestellungen, die eine Anwendung als solches Betreffen

Nicht-funktionale Anforderungen

Einige Fragen können rein rechtlicher Natur sein. Andere haben jedoch konkrete Auswirkungen auf die Entwicklung oder den Betrieb.

Qualitätssicherung

Durchzuführende Qualitätssicherung

Beschreibung eines Qualitätsziels

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.

Qualitätssicherungsdokumentation am Projektende

(exemplarisch) Qualitätssicherungsdokumentation - Automatisierte Tests

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.

(exemplarisch) Qualitätssicherungsdokumentation - Benutzerstudie

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.

(exemplarisch) Qualitätssicherungsdokumentation - Dokumentation des Quellcodes

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.

(exemplarisch) Qualitätssicherungsdokumentation - Code Reviews

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.

Build-Prozess

Automation des Build-Prozess

Stabile Builds

Um stabile Builds zu erhalten ist es notwendig, dass ...

Grundlegend zu automatisierende Tätigkeiten

Automatisierbare Tätigkeiten