Wie spezifiziert man die Qualität eines Softwaresystems? Herausforderungen und erste Lösungsideen aus SIKOSA

Transkript

1 Wie spezifiziert man die Qualität eines Softwaresystems? Herausforderungen und erste Lösungsideen aus SIKOSA Prof. Dr. St. Kirn (Sprecher) Prof. Dr. B. Paech Prof. Dr. D. Kossmann Prof. Dr. G. Müller

2 Schematische Übersicht über das Projekt Supply Chain Management (Porsche / LEONI / KMUs) Geschäftsprozessmodellierung Risikoanalyse Schwachstellenanalyse Anforderungsspezifikation Architekturspezifikation Gegenmaßnahmen ermitteln Testspezifikation Auswahl der Sicherheitsmechanismen Validierung des Prozesses Implementierung Test Testdaten und Testfallgenerierung Sicherheitstest Seite 2

3 Übersicht Requirements Engineering Quality Requirements! Herausforderungen Misuse-basierte Erhebung von QR Ausblick Seite 3

4 Gemeinsames Verständnis As proposed by the project sponsor As specified in the project request Requirements Engineering! As designed by the senior analyst As produced by the programmers As installed at the user's site What the user wanted Seite 4

5 Task oriented Requirements Engineering (TORE) Aufgaben Rollen Aufgaben ebene IST-Aktivitäten SOLL-Aktivitäten System- Verantwort. Domänendaten Domänen ebene Interaktions daten Systemfunktionen Interaktion UI- Struktur Interaktions ebene Interne Aktionen Interne Daten Systemebene: Anwendungskern Hilfsfunktionen Dialog UI-Daten Systemebene: GUI Architektur Screen- Struktur Seite 5

6 Was ist Qualität? ISO/IEC :2001(E), Software Engineering - Product Quality - Part 1: Quality Model, 2001 Quality in use! Effectiveness, Productivity, Safety, Satisfaction External and internal quality! Efficiency, Portability, Maintainability, Functionality, Usability, Reliability Process Quality Seite 6

7 Produktqualität nach ISO 9126/DIN66272 Funktionalität! Angemessenheit! Sicherheit! Genauigkeit der Berechnung! Interoperabilität! Konformanz zu Standards Zuverlässigkeit! Reife! Fehlertoleranz! Wiederherstellbarkeit Benutzbarkeit! Verständlichkeit! Erlernbarkeit! Bedienbarkeit Effizienz! Zeitverhalten! Verbrauchsverhalten Änderbarkeit! Analysierbarkeit! Modifizierbarkeit! Stabilität! Prüfbarkeit Gute Checkliste! Übertragbarkeit! Anpassbarkeit! Installierbarkeit! Konformanz zu Standards! Austauschbarkeit Seite 7

8 Was ist die richtige Qualität für mein Projekt? Identifiziere QR aus verschiedenen Sichten und auf verschiedenen Detailebenen Identifiziere Abhängigkeiten und Konflikte und diskutiere und prioritisiere die QR entsprechend Identifiziere und evaluiere Mittel zur Erfüllung der QR, fälle Trade- Off-Entscheidung (in Bezug auf Kosten, Zeit) Dokumentiere QR und evaluiere die Dokumente Ändere und verwalte QR effizient Seite 8

9 Herausforderungen Identifiziere QR! QR zu abstrakt (Funktionale und Architekturanforderungen konkreter), zu frühe Festlegung Identifiziere Abhängigkeiten und Konflikte! Konfiguration reicht nicht (Goal graphs), da sich Wertigkeiten ändern relativ zum Kontext Identifiziere Mittel,Trade-Off-Entscheidung! Überblick, Visualisierung Dokumentiere QR! Standardisierte Terminologie vs. spezifische Stile Ändere und verwalte QR effizient! Bilaterale Verfolgbarkeitslinks reichen nicht, QR als Aspekte Seite 9

10 Beispiel Uveitis-Datenbank Datenbank bzgl. Behandlung von Uveitis-Patienten Wichtige QR: Datenintegrität, da die Patientendaten und die Untersuchungsergebnisse für Studien verwendet werden. Checkliste (z.b. auch Chung et al oder Empress-Projekte) Datenintegrität Genauigkeit Vollständigkeit Was heißt in diesem Projekt: Genauigkeit, Vollständigkeit? Seite 10

11 Lösungsidee Unterstütze genauere Bestimmung der QR durch Betrachtung von Qualitätsmängeln und -bedrohungen! Alexander, Sindre, Opdahl: Misuse Cases! Bedrohungs/Schwachstellenanalyse im Bereich Sicherheit Seite 11

12 Qualitäts-Konzepte QR QR QR QR Wert Qualitätsmangel Betrieb/System/ Entwicklungs- Bedrohungsaktion Qualität Ausführende Systemziel Ist verhindert durch Entsteht durch Missbrauch bewirkt Wird erleichtert durch unterstützt Betrieb/System/ Entwicklungs- Gegenmaßnahme: Erkennen Verhindern Abschwächen Betrieb/System/Entwicklungs-Schwachstelle Geschäftserfolg Ist verhindert durch Geschäftsschaden QR Seite 12

13 Beispiel: Qualitätsanforderungen (1) Datenintegrität Wert Qualitätsmangel Qualität Ist verhindert durch Keine Datenunvollständigkeit Entsteht durch Keine Falsche Eingaben Durch BenutzerIn bewirkt unterstützt System: Einfache Betrieb/System/Entwicklungs-Schwachstelle Wichtige Studie Geschäftserfolg Ist verhindert durch Studie angezweifelt Geschäftsschaden Betrieb/System/ Entwicklungs- Bedrohungsaktion Ausführende Systemziel Betrieb/System/ Entwicklungs- Eingabefelder Gegenmaßnahme: Erkennen Entwicklung: Verhindern Abschwächen Missbrauch Viele Nutzungstest Wird erleichtert durch Keine Komplexen Eingabefelder Seite 13

14 Beispiel: Qualitätsanforderungen (2) Datenintegrität Wert Qualitätsmangel Qualität Betrieb/System/ Entwicklungs- Bedrohungsaktion Ausführende Systemziel Ist verhindert durch Keine Datenunvollständigkeit Entsteht durch Keine Falsche Eingaben Durch BenutzerIn Missbrauch bewirkt Wird erleichtert durch unterstützt Keine Unerfahrene BenutzerIn Betrieb: Training Betrieb/System/Entwicklungs-Schwachstelle Wichtige Studie Geschäftserfolg Ist verhindert durch Studie angezweifelt Geschäftsschaden Betrieb/System/ Entwicklungs- Gegenmaßnahme: Erkennen Verhindern Abschwächen Seite 14

15 Beispiel: Qualitätsanforderungen (3) Datenintegrität Wert Qualitätsmangel Qualität Betrieb/System/ Entwicklungs- Bedrohungsaktion Ausführende Systemziel Ist verhindert durch Keine mainuplierten Datenunvollständigkeit Entsteht durch Keine Verfälschung Durch Angreifer Missbrauch bewirkt Wird erleichtert durch Keine unsicheres unsicheren Netz Räume unterstützt Betrieb/System/Entwicklungs-Schwachstelle Wichtige Studie Geschäftserfolg Ist verhindert durch Studie angezweifelt Geschäftsschaden Betrieb: Raumsicherung Betrieb/System/ Entwicklungs- Gegenmaßnahme: Erkennen Verhindern Abschwächen Seite 15

16 Iteratives Vorgehen Datensicherheit Wert Qualitätsmangel Qualität Betrieb/System/ Entwicklungs- Bedrohungsaktion Ausführende Systemziel Ist verhindert durch Kein Unsicheres Netz Entsteht durch Keine Datenzugriff Durch Unauthorisierte Missbrauch Wird erleichtert durch Keine Authorisierung unterstützt Systemziel Datenvollständigkeit System: Firewall Betrieb/System/Entwicklungs-Schwachstelle Betrieb/System/ Entwicklungs- Gegenmaßnahme: Erkennen Verhindern Abschwächen Seite 16

17 Vorgehen Betrachte ausgehend von einem Qualitätsattribut nacheinander mögliche Systemziele, Qualitätsmängel, Missbräuche, Schwachstellen und ggf. auch Gegenmaßnahmen (relativ zu den bisherigen Anforderungen) und formuliere QR auf der angemessenen Detailebene (je nach Projektfortschritt, Notwendigkeit der frühen Festlegung) Durch Einbezug konkreter Use Cases als Wert können auch UCspezifische QR abgeleitet werden. Seite 17

18 Bisherige Ergebnisse Konzepte lassen sich gut auf viele Beispiele anwenden Diese Analysen lassen sich zum Teil auch projektunabhängig durchführen! Checklisten auch für Missbräuche, Schwachstellen, Gegenmaßnahmen Abhängigkeiten zwischen QR bisher nicht betrachtet: Je tiefer die QR formuliert wird, desto mehr sind Abhängigkeiten zu anderen Entscheidungen beachten. Seite 18

19 Offene Fragen Betrachtung von Risiken, d.h. Wahrscheinlichkeit des Eintretens eines Missbrauchs und Größe des Geschäftsschaden! Wichtig zur Entscheidung bei Konflikten zwischen Anforderungen Betrachtung weiterer Faktoren, die den Missbrauch erklären! Gründe des Ausführenden (z.b. Rache) Weitere Bezüge: z.b. FMEA Seite 19

20 Zusammenfassung und Ausblick Qualitätsanforderungen werden oft nur sehr oberflächlich erfasst Betrachtung von Missbrauch, Schwachstellen und Gegenmaßnahmen erleichtert die Konkretisierung Im Projekt SIKOSA wird die Tragfähigkeit an komplexen Beispielen (Porsche, LEONI) erprobt Seite 20

21 Literatur Paech, B., Kerkow, D.: Non-functional requirements engineering quality is essential, Invited Paper, Int. Workshop REFSQ 04, Herrmann, A., Paech, B.: Quality Misuse, Int. Workshop REFSQ 05 Seite 21