Skript - Zusatz Flashcards
1
Q
Digitale Güter
A
sind immaterielle Mittel zur Bedürfnisbefriedigung, die sich mit Hilfe von Informationssystemen entwickeln, vertreiben und anwenden lassen.
2
Q
Immaterielle Güter
A
Nutzungsrechte (Lizenzen) und Dienstleistungen
3
Q
Produkt
A
Ergebnis der Produktion und Sachziel einer Unternehmung oder auch Mittel der Bedürfnisbefriedigung
4
Q
Softwareintensive Systeme
A
Systeme, deren wesentliche Eigenschaften durch Software realisiert sind. Zwei unterschiedliche Arten: Informationssysteme (Erfassen, speichern, verarbeiten Informationen), Eingebettete Systeme (Software nur ein Systembestandteil und ist eng mit Hardware integriert).
5
Q
Herausforderungen digitaler Produkte
A
Struktur: Koppelung verschiedener Systeme aus verschiedenen Technologien
Entwicklung, Betrieb und Steuerung: DP sind schnelllebig und komplex, Kostenwettbewerb, Steuerung? Gestaltung Funktionsvielfalt mit beherrschbarer Komplexität
Lebensdauer & Entwicklungsgeschwindigkeit: unterschiedliche Lebensdauer Hardware/Software, Software entwickelt sich weiter (Updates)
Langfristiger Betrieb: Hardware in Kundenhand, Software zentral betrieben Betriebskosten
6
Q
Anforderung
A
Zustand bzw. Fähigkeit ein Problem bzw. Herausforderung zu lösen oder ein Ziel zu erreichen. Fähigkeit oder Zustand eines Systems, um einen Vertrag oder Spezifikation zu erfüllen.
7
Q
Projekterfolg?
A
Wenn ich weiß, wann ich fertig bin. Wenn der Kunde zufrieden ist. Wenn die Kunden des Kunden zufrieden sind. Wenn die Einnahmen > Ausgaben sind. Wenn es der Marke dient.
8
Q
Requirements Engineering & Management
A
Alle Tätigkeiten, die sich mit Anforderungen beschäftigen. Auflösung von Unstimmigkeiten zur Verifikation und zur Validierung von Anforderungen. Verwaltete Anforderungen Stakeholdern zur Verfügung stellen/ kommunizieren. Änderungs- und Konfigurationsverwaltung. Anforderungsentwicklung anhand Anforderungsattributen steuern. Beziehungen zwischen Anforderungen und anderen Projektergebnissen pflegen.
9
Q
Projektziele
A
Ziel ist Lösung, die dem Kunden meistens Geld spart. Leitbilder für gesamtes Projekt. Festlegung des Projektumfangs. Anforderungen an das Projekt
10
Q
Angebotserstellung
A
Einschätzen können, wie viel es kosten soll. Erfahrungen aus Vorprojekten sammeln. Gesammelte Infos in Angebot oder Folgeprojekt einfließen lassen
11
Q
Projektumfang
A
Erste verbindliche Kundenanforderungen. Rahmenbedingungen. Identifizierung, Definition und Abstimmung grundleger Anforderungen, Stakeholder und Arbeiten, die nicht zu erledigen sind. Definition eines ersten verbindlichen Stands der Anforderungen.
12
Q
Dokumentation
A
Lastenheft (Vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Leistungen eines Auftragnehmers. Pflichtenheft (Vom Auftragnehmer erarbeitete Realisierungsvorgaben auf Basis Lastenheft.
13
Q
Stakeholder
A
Product Owner, Kunde, Gesetzgeber, Firma, Sponsor, Projektleiter, Kunde des Kunden, …
14
Q
Anforderungsingenieur
A
hilft unausgesprochene Erwartungen, Rahmenbedingungen, Prioritäten zu ermitteln, verwalten und aufzubereiten.
15
Q
Behandlung offener Punkte
A
Frühe Klärung und Dokumentation offener Punkte als transparenter Prozess. Mögliche Ergebnisse: Anforderungen, Arbeitsaufträge, neue offene Punkte. Priorisierung nach entstehendem Risiko. Selbstverständlichkeiten dokumentieren.
16
Q
PSP
A
bildet hierarchisch alle Projektschritte ab. Strukturierung ist phasenorientiert, fachgebietsorientiert, funktionsorientiert oder objektorientiert. Zuordnung von Anforderungen zu PSP-Elementen.
17
Q
Doku von Anforderungen - Warum?
A
Persistenz, gemeinsame Informationsbasis, fördert Kommunikation, fördert Objektivität, Einarbeitung neuer MA, Geringere Abhängigkeit von Experten, Reflexion.
18
Q
Doku von Anforderungen - Was?
A
Abweichungen, Alternativen, Wünsche, Änderungsanträge, Begründungen, Entscheidungen, Ergebnisse, Lücken, Prioritäten, Risiken, Verantwortlichkeiten.
19
Q
Doku von Anforderungen - Qualitätskriterien
A
Vollständigkeit, Nachvollziehbarkeit, Korrektheit, Eindeutigkeit, Verständlichkeit, Konsistenz, Überprüfbarkeit, Aktualität
20
Q
Organisation von Anforderungen - Ziel & Lösung
A
Ziel: Organisation & Struktur von Anforderungen, Übersicht behalten, Lücken vermeiden
Lösung: Attributierungsschema (definiert die Attribute für eine Klasse von Anforderungen)
21
Q
Definition Ziel
A
Ein Ziel ist die Intentionale Beschreibung eines charakteristischen Merkmals des zu entwickelnden Systems bzw. des dazugehörigen Entwicklungsprozesses. Verfeinerung der Vision.
22
Q
Doku Ziele:
A
Prägnante, kurze Formulierung. Aktivformulierung. Überprüfbare Ziele. Verfeinerung nicht überprüfbare Ziele. Mehrwert verdeutlichen. Begründung für ein Ziel. Keine Lösungsansätze
23
Q
Szenario
A
Ein Szenario beschreibt ein konkretes Beispiel für die Erfüllung eines oder mehrerer Ziele. Es konkretisiert dadurch eines oder mehrere Ziele. Ein Szenario enthält typischerweise eine Folge von Interaktionsschritten und setzt diese in Bezug zum Systemkontext.
Szenarien konkretisieren Ziele, sind Mittler zwischen Realität und konzeptuellem Modell. Szenarien können unterschiedlich abstrakt bzw. konkret sein und bilden vor allem die Nutzungsfacette ab.
24
Q
Gewinnung Anforderungen - Warum?
A
Identifikation relevanter Anforderungsquellen. Gewinnung existierender Anforderungen. Entwicklung von innovativen Anforderungen.
25
Arten Anforderungen
Existierende Anforderungen. Rahmenbedingungen. Innovative Anforderungen
26
Gewinnungstechniken
Interview, Workshop, Beobachtung, Schriftliche Befragung, Perspektivenbasiertes Lesen. Innovative Anforderungen: Brainstorming. Osborn-Checkliste. Walt-Disney-Methode
27
Workshop Phasen
Vorbereitung: Ziele definieren, Vorgehen festlegen, Agenda erstellen (auch Pausen), Auswahl der Teilnehmer, Ort festlegen, Moderator bestimmen/einladen, Protokollant bestimmen/einladen.
Durchführung: Ziele & Agenda vorstellen, Techniken erläutern, Regeln für den Umgang miteinander festlegen, Moderator überwacht Agenda und Regeln, Protokollierung, Ideenspeicher, Retrospektive.
Nachbereitung: Offene Punkte, Lücken im Protokoll auflösen. Genehmigung des Protokolls durch alle Teilnehmer.
Erfolgsfaktoren: Zielakzeptanz, Motivation der Teilnehmer, „richtige“ Teilnehmer (fachlich kompetent, motiviert, Entscheidungskompetenz, soziale Kompetenz), guter/passender Moderator.
28
Beobachtung
Beschreibung einer Tätigkeit ist im normalen Umfeld und während der Durchführung einfacher. Zur Gewinnung existierender Anforderungen geeignet, aber nicht für neue Anforderungsquellen. Direkte Beobachtung oder Ethnografische Beobachtung.
29
Beobachtung Phasen
Vorbereitung: Ziele der Bobachtung definieren (Anforderungsziele: Intentionen der Stakeholder. Szenarien: Interaktion der Stakeholder untereinander und mit dem System)
Durchführung: Stakeholder sind Experten: Tätigkeit wird nicht hinterfragt. Vertrauen gewinnen. Details aufnehmen. Unmittelbar dokumentieren (Text, Video, Audio). Objektivität wahren. Authentizität der Tätigkeit prüfen.
Nachbereitung: Aufarbeiten der Aufzeichnungen. Abgleich mit Stakeholdern/ Beobachteten Personen.
Erfolgsfaktoren: Kooperation der Stakeholder. Objektivität des Beobachters
30
Schriftliche Befragung Phasen
Vorbereitung: Ziele definieren. Auswahl der Stakeholder. Fragestellung definieren. Dokumentationsform festlegen. Eventuell Schulung der Dokumentationsform
Durchführung: Zeitrahmen festlegen. Ansprechpartner für Rückfragen. Erinnerung gegen Ende des Zeitrahmens. Anerkennung für Einsatz.
Nachbereitung: Aufbereiten der Antworten. Weitergehende Gewinnungsschritte definieren.
Erfolgsfaktoren: Motivation der Stakeholder. Verständliche Fragen. Klare Antworten. Auswahl der richtigen Dokumentationsform.
31
Perspektivenbasiertes Lesen
Gewinnung von Anforderungen aus Dokumenten. Gewinnung von relevanten Stakeholdern, Dokumente und Systeme, falls sie im Dokument auftauchen. Lesen mit versch. „Hüten“ auf.
32
Perspektivenbasiertes Lesen Phasen
Vorbereitung: Definition der Ziele. Definition der Perspektiven. Selektion der Dokumente. Festlegen der Teilnehmer
Durchführung: Selektives Lesen (Sequenziell. Top-Down). Paralleles Dokumentieren von Anforderungen.
Nachbereitung: Aufbereitung der Ergebnisse
Erfolgsfaktoren: Auswahl der Perspektive. Auswahl der Dokumente. Qualität der Dokumente inkl. Struktur.
33
Assistenztechnik Prototyp
Erlebbares System. Erwartungen der Stakeholder können geprüft werden. Stimulation neuer Anforderungen. Horizontaler oder vertikaler Prototyp. Wegwerf- oder evolutionärer Prototyp. Gefahr der Vorwegnahem des Systems. Agiler Kontext.
34
System
Ein System ist eine zweckmäßige Sammlung miteinander verbundener Komponenten unterschiedlicher Art, die zusammenarbeiten, um dem Eigentümer des Systems und seinen Benutzern eine Reihe von Diensten zu bieten. Es ist ein Ausschnitt aus der realen oder gedanklichen Welt.
35
Systemkontext
Der Teil der Umgebung eines Systems, der für die Definition und das Verständnis der Anforderungen and das System relevant ist. Aufteilung in: Gegenstandsfacette (für System relevante Objekte und Ereignisse), IT-Systemfacette (geplante umgebende IT Infrastruktur), Nutzungsfacette (durch Benutzer und andere Systeme, alle Aspekte), Entwicklungsfacette (z.B. Prozesse, Werkzeuge, QS)
36
Emergenz
auftauchen, hervorkommen. Eigenschaften eines Systems, die nicht einzelnen Systemkomponenten zugeordnet werden können, sondern nur dem System als Ganzem zugeordnet werden können. Manche emergenten Eigenschaften sind direkt aus Systemkomponenten ableitbar (z.B. Gewicht). Andere sind Konsequenz der Beziehung von Systemkomponenten: Entstehen eventuell völlig unerwartet. Können erst bewertet und gemessen werden, wenn alle Komponenten integriert sind.
37
Nicht-deterministisches Verhalten
begrenzen, bestimmen. Determinismus: Alle Ereignisse sind durch Vorbedingungen eindeutig bestimmt. „deterministisches Verhalten“: Gleiche Eingabe führt immer zu gleicher Ausgabe, berechenbares Verhalten. Nicht-deterministisches Verhalten: Unberechenbarkeit, gleiche Voraussetzungen führen zu unterschiedlichen Ergebnissen. Bei soziotechnischen Systemen: Menschen sind unberechenbare Systembestandteile. Nutzung des Systems ⟹ neue Beziehungen entstehen, die emergentes Verhalten ändern.
38
Subjektive statt objektive Erfolgskriterien
Wann ist ein System „erfolgreich“? ⟹ Erfolgskriterien. Aber: 1. Komplexe Systeme werden für vertrackte Probleme genutzt. 2. Erfolgskriterien werden aus organisatorischen oder politischen Zielen abgeleitet. Ziele sind: veränderbar und nicht immer stabil („moving targets“), nicht immer widerspruchsfrei (z.B. „Qualität verbessern“ kombiniert mit „Kosten senken“) und abhängig von Interpretation durch Menschen.
39
Altsysteme Austausch
risikoreich und teuer, weil oft keine vollständige Systemspezifikation vorhanden. Systeme und GPs sind tief integriert. Systeme enthalten undokumentierte Geschäftsregeln. Dazu übliches Risiko von Verzögerungen und Budgetüberschreitungen.
40
Altsysteme Alternative Weiterentwicklung
Veränderung von Altsystemen ist teuer, da: kein einheitlicher Programmierstil. Veraltete Programmiersprachen (wenig Experten). Ursprüngliche Entwickler nicht mehr da. Keine angemessene Doku. Fehlerhafte, doppelte und inkonsistente Daten
41
Altsysteme Strategie
Veränderung & Austausch nicht ohne Risiko. Organisationen brauchen eine Strategie (System ausrangieren und GPs anpassen? System weiter warten? System durch Re-Engineering transformieren und Wartbarkeit verbessern? System durch ein neues ersetzen?). Strategie sollte von Systemqualität und Geschäftswert des Systems abhängen.
42
Altsysteme Konsequenzen
Risiken an zwei Stellen: Änderung eines Altsystems können um Größenordnung teurer sein und veraltete Technik kann im Gegensatz zum aktuellen Stand Lösungsmöglichkeiten einschränken. Schon bei Anforderungserhebung muss bedacht werden, was die langfristige Strategie ist. Gibt es eine?
43
Verlässlichkeit
Für viele Systeme wichtigste Eigenschaft. Spiegelt wider, wie stark Benutzer einem System vertrauen und erwarten, dass sich das System bei normaler Nutzung wie erwartet verhält.
Störung oder Ausfall eines Systems können weitreichende Folgen haben, die viele Personen betreffen: Wirtschaftliche Einbußen, Materielle Schäden, Wiederherstellungskosten bei verlorenen Informationen. Systeme die nicht verlässlich sind, können von Benutzern abgelehnt werden!
44
Herstellen von Verlässlichkeit
zufällige Fehler während Entwicklung vermeiden. Prozesse für Verifikation und Validierung aufsetzen. Systeme fehlertolerant machen, damit sie trotz Ausfälle weiterlaufen. Schutzmaßnahmen gegen externe Angriffe. Korrekte Konfiguration für Betriebsumgebung. Mechanismen vorsehen, um das System nach Ausfall wiederherzustellen.
45
Verlässlichkeit Kosten
wachsen ungefähr exponentiell mit zunehmender Verlässlichkeit, da teurere Entwicklungsmethoden und Hardware und Nachweis der erreichten Verlässlichkeit wächst im Aufwand
Wirtschaftlichkeit: Sehr hohe Kosten für Verlässlichkeit, liegt es nahe, lieber geringere Verlässlichkeit zu akzeptieren und stattdessen Kosten für Ausfälle zu tragen. Viele Faktoren spielen hier eine Rolle: schlechte Reputation zukünftige Verluste. Geschäftssysteme könnte moderates Level von Verlässlichkeit reichen.
46
Verlässlichkeit Entwicklungsmethoden
Verlässliche Prozesse: Wohldefiniert, wiederholbar, überprüfbar – mit Schwerpunkt Verifikation und Validierung. Reviews der Anforderungen (Vollständigkeit, Konsistenz). Systemmodellierung mit graphischen Modellen, die mit Anforderungen verknüpft sind. Inspektion von Entwurf und Code durch unterschiedliche Personen. Statische Analyse auf dem Quelltext. Explizites Testmanagement: Umfangreiche, dokumentierte Tests. Formale Methoden.
47
Eingebettete Systeme
Systeme aus Hardware und Software in einem technischen Kontext zur Überwachung, Steuerung, Regelung. Software in diesen Systemen muss auf Ereignisse reagieren, die die Hardware erzeugt und Steuerungssignale als Antwort auf diese Ereignisse erzeugen. Sie ist eingebettet in diese Hardware und muss in vorgegebener Zeit auf Ereignisse reagieren können.
48
Echtzeit
Ein Echtzeit-System ist ein Softwaresystem, bei dem die korrekte Funktion eines Systems von den erzeugten Ergebnissen und der Zeit abhängt, zu der diese Ergebnisse produziert werden. Weiche Echtzeit: Überschreiten der Zeitschranke kann vorkommen – dann eingeschränkte Leistung. Harte Echtzeit: Das System garantiert feste Zeiten – sonst Fehlerfall mit eventuell schwerwiegenden Folgen.
49
Eingebettete Systeme Charakteristika
Eingebettete Systeme laufen kontinuierlich, ohne zu terminieren (bis zum Ausschalten). Interaktionen mit der Umgebung des Systems sind nicht vorhersagbar (unerwartete Ereignisse geschehen). Physikalische Beschränkungen (z.B. Platz, Gewicht, Stromversorgung). Direkte Ansteuerung von Hardware kann nötig sein. Der Systementwurf kann von Funktionsicherheits- und Zuverlässigkeitsfragen dominiert werden.
50
Stimulus-Response-Modell
System reagiert auf Stimulus (Reiz) innerhalb bestimmter Zeit mit Response. Periodische Stimuli (Vorhersagbare, regelmäßige Zeitabstände). Sporadische Stimuli (unregelmäßig, unvorhersehbar).
51
Edge Dominant Systems
Ein System, dessen Erfolg von den Beiträgen seiner Benutzer abhängt (Crowdsourcing (Open Content): Wikipedia/Youtube/Instagram/Facebook, Open Source: Apache Web Server/Hadoop)
Drei unterschiedliche Typen von Stakeholdern
Äußersten Ringe tragen Inhalt bei, aber keine Anforderungen
In der Mitte Prosumer: Ziel ist, deren Interaktionen zu erleichtern
Im Kern: Software mit Sammlung von APIs, die Prosumern Interaktion miteinander und Bereitstellung von Inhalt für äußersten Ring erlaubt
Ringe sind unterschiedlich durchlässig
Open Content: Consumer wird Beitragender und umgekehrt, aber kein Zugang zum Kern
Open Source: Von jedem Ring in jeden Ring
52
Software Produktlinie - Prinzipien
Individualität ⟷ Massen-Standard. Individualität ist teuer. Standproduktion fehlt Vielfalt. Problem: Wie lässt sich gewünschte Individualität mit günstiger Massenproduktion kombinieren? „Mass Customatisation“: Massenproduktion von Waren basierend auf individuellen Kundenbedürfnissen. Produkte aus individueller Massenfertigung haben gemeinsame Anteile Herauslösung in Plattform
53
Software Produktlinie - Motivation
Reduktion Entwicklungskosten (Break-Even bei ca. 3 Systemen). Verkürzung der Time-to-Market. Qualitätsverbesserung. Reduktion Wartungsaufwand. Besserer Umgang mit Komplexität. Leichtere Kostenschätzung. Kundenvorteile.
54
Software Produktlinie Definition
Software Product Line Engineering ist ein Paradigma zur Entwicklung von Softwareanwendungen unter Verwendung von Plattformen und Massenanpassung. Eine Softwareplattform ist eine Reihe von Software-Subsystemen und -Schnittstellen, die eine gemeinsame Struktur bilden, aus der eine Reihen von abgeleiteten Produkten effizient entwickelt und produziert werden kann.
55
Software Produktlinie Voraussetzungen
Technologische Voraussetzungen: Techniken des Software-Engineerings (Objektorientierte Programmiersprachen, Software aus Komponenten). Reife Entwicklungsprozesse mit explizitem RE und Modellierung. Sehr gute Kenntnis der Ziel-Domäne. Hinreiche Stabilität Ziel-Domäne.
56
Domain Engineering
1. Domain Requirements Engineering. 2. Domain Design. 3. Domain Realisation. 4. Domain Testing.
57
Application Engineering
1. Application Requirements Engineering. 2. Application Design. 3. Application Realisation. 4. Application Testing.
58
Arten von Variabilitäten
Gleichzeitig/nacheinander. Extern (Variabilität von Domänenartefakten sichtbar für Kunden) / intern (nicht sichtbar)
59
Domain Requirements Engineering
Herausforderungen: Spezifische Aktivitäten gegenüber Einzelsystementwicklung. Variabilitäten in unterschiedlichen Sichten.
Wichtige Schritte: Gemeinsamkeiten: Zuerst gemeinsame Anforderungen identifizieren & dokumentieren. Variabilitäten: Dann variable Anforderungen erheben.
Analyse auf Gemeinsamkeiten: Ziel: so Viele Gemeinsamkeiten wie möglich (Flexibilität kostet!). Prioritätenbasierte Analyse oder Checklistenbasierte Analyse.
60
Application Requirements Engineering
Unterschiede zur Einzelsystementwicklung: Kommunikation der Variabilitäten. Deltas (Auswirkungen der Deltas auf das Variabilitätsmodell). Dokumentation der Anwendungs-Anforderungen mit Verbindung zu den Domänen-Anforderungsartefakten. Dokumentation der Variabilitätenbindungen (Anwendungs-Variabilitätsmodell)
61
Compliance
Handeln in Übereinkunft mit den geltenden Vorschriften
62
Regulierte technische Systeme
Regulation der Systeme und Überwachung und Genehmigung durch Regulierungsbehörden (Nuklearsysteme, Flugsicherung, Medizinische Geräte). Es können System- oder Organisations-Zertifizierungen nötig sein. Zertifizierungen können aufwändig und teuer sein.
63
Kritische Infrastrukturen
Organisationen oder Einrichtungen mit wichtiger Bedeutung für das staatliche Gemeinwesen, bei deren Ausfall oder Beeinträchtigung: nachhaltig wirkende Versorgungsengpässe, erhebliche Störungen der öffentlichen Sicherheit oder andere dramatische Folgen eintreten würden. KRITITS-Betreiben unterliegen IT-Sicherheitsgesetz. Bsp: Staat & Verwaltung, Energie, Gesundheit, IT & TK, Transport & Verkehr, Medien & Kultur, Wasser, Finanz- & Versicherungswesen, Ernährung.
64
Personenbezogene Daten
alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen (Betroffener)
65
Datenschutz
Schutz des Einzelnen vor Beeinträchtigung seines Persönlichkeitsrechts beim Umgang mit seinen personenbezogenen Daten
66
Datensicherheit
Schutz der gespeicherten Daten vor Beeinträchtigung durch höhere Gewalt, menschliche oder technische Fehler und Missbrauch
67
Personenbezug
Unmittelbare Verbindung: Z.B. Namen, Anschrift, Geburtsdatum gegeben. Mittelbare Verbindung: Mittels Zusatzwissen, z.B. Telefonnummer, Matrikelnummer, Sozialversicherungsnummer, Online-Kennungen (IP-Adressen, Cookie-Kennungen). Ausreichend: Information ermöglicht theoretisch die Identifizierung der betroffenen Person. Unerheblich: Ob die Person tatsächlich identifiziert wird.
68
Datenschutz Regelungen
Gewährleistung Betroffenenrechte: Auskunft, Berichtigung, Löschung, Sperrung, Schadensersatz, Datenübertragbarkeit. Abgrenzungen in Konstellationen mit Dritten. Datenschutzkontrolle (Selbstkontrolle durch Betroffene, Eigenkontrolle durch Datenschutzbeauftragte, Fremdkontrolle durch Aufsichtsbehörde).
69
Datenschutz Durchsetzung durch Aufsichtsbehörden
Überwachung & Durchsetzung (Untersuchungsbefugnisse, Sanktionsbefugnisse), Information & Beratung.
70
Technisch und organisatorische Maßnahmen (TOM
Verantwortlicher und Auftragsverarbeiter ist verpflichtet zu solchen Maßnahmen. Angemessene Maßnahmen: Alle Maßnahmen in Verbindung mit Verarbeitung personenbezogener Daten, die angemessenes Sicherheitsniveau nach DSGVO sicherstellen.
Ziele TOMs: Restrisiko der Verwundbarkeit minimieren mit Maßnahmen
71
Privacy by Design nach Hoepman
8 Strategien unterstützt durch Umsetzungstaktiken.
1. Minimise: Datenverarbeitung soweit wie möglich beschränken (Select, Exclude, Strip, Destroy).
2. Separate: Daten aus getrennten Quellen getrennt verarbeiten (Isolate, Distribute)
3. Abstract: So wenig Details wie möglich (Summarise, Group, Perturb)
4. Hide: Daten unbeobachtbar machen (Restrict, Obfuscate, Dissociate, Mix)
5. Inform: Betroffene frühzeitig und angemessen benachrichtigen (Supply, Explain, Notify)
6. Control: Betroffenen angemessene Kontrolle geben (Consent, Choose, Update, Retract)
7. Enforce: Datenschutz angemessen durchsetzen (Create, Maintain, Uphold)
8. Demonstrate: Datenschutz vorzeigen (Record, Audit, Report)
72
Informationssicherheit
Informationssicherheit hat das Ziel, Informationen jeglicher Art und Herkunft zu schützen. Dabei können Informationen auf Papier, in IT-Systemen oder auch in den Köpfen der Benutzer gespeichert sein. IT-Sicherheit als Teilmenge der Informationssicherheit konzentriert sich auf den Schutz elektronisch gespeicherter Informationen und deren Verarbeitung.
73
Informationssicherheit Ziele
Vertraulichkeit (Confidentiality): Informationen in einem System könnten preisgegeben werden oder unautorisiert Personen oder Software zugänglich gemacht werden. Integrität (Integrity): Informationen in einem System könne beschädigt oder fehlerhaft sein, so dass sie nutzlos oder unzuverlässig ist. Verfügbarkeit (Availability): Der Zugriff auf Informationen (z.B. ein System mit seinen Daten), die normalerweise verfügbar sein sollten, könnte nicht möglich sein.
74
Informationssicherheit Abgrenzung Datenschutz
Informationssicherheit will Schaden von Organisation abwenden (alle Daten). Datenschutz von Betroffenen (nur personenbezogene Daten).
75
Cybersicherheit
befasst sich mit allen Aspekten der IT-Sicherheit, wobei das Aktionsfeld auf den gesamten Cyber-Raum ausgeweitet wird. Cyber-Raum umfasst in dieser Definition: sämtliche mit dem globalen Internet verbundene IT und IT-Infrastrukturen, sowie deren Kommunikation, Anwendungen, Prozesse mit Daten, Informationen und Intelligenzen.
76
Arten Bedrohungen
Daten ausspähen nach erlangtem Zugriff. Unterbrechung (Systemausfall). Veränderung der Daten. Erzeugen neuer, falscher Daten im System.
77
Arten von Maßnahmen
Vermeidung von Schwachstellen (System so entwerfen, dass Schwachstellen nicht auftreten können, Bsp: Keinen Anschluss an Netzwerke oder Internet, Einsatz Kryptographie). Erkennung von Angriffen und deren Eliminierung (Funktionen vorsehen, um Schwachstellen erkennen und neutralisieren können; Bsp: Überwachung auf ungewöhnliche Aktivitäten, oder Anti-Virus Software). Begrenzung des Schadens und Wiederherstellung (Funktionen vorsehen, die Wiederherstellung des gewünschten Systemzustands unterstützen; Bsp: Automatisierte Datensicherung, aber auch: Abschluss von Versicherungen).
78
Arten Sicherheitsanforderungen
Risikovermeidung. Risikoerkennung. Risikobegrenzung
79
Sicherheitsanforderungen nach Firesmith
Identifikation. Authentifizierung. Autorisierung. Immunität. Integrität. Einbruchserkennung. Unleugbarkeit. Datenschutz. Sicherheitsüberprüfung. Wartungssicherheit
80
Produktmanagement Grundprinzip
Einzelnen Produkten oder Produktgruppen wird ein Produktmanager zugeteilt mit dem Auftrag, sämtliche produktbezogenen Themenbereiche funktionsübergreifend zu koordinieren und zu steuern. Es entsteht dabei eine Matrixorganisation im Unternehmen.
81
Produktmanager
Strategisch ausgerichtet. Vorgesetzter: Geschäftsbereichsleiter.
Ziele: Strategische Produktführung, Optimierung Umsatz & Deckungsbeitrags, Optimierung der Steuerung, Koordination & Umsetzung aller produktbezogenen Maßnahmen und Aktivitäten. Optimierung des produktbezogenen Informationsmanagements.
Aufgaben: Markt- und Wettbewerbsanalyse. Produktstrategie, Entwicklung Produkt. Produktcontrolling. Marketing & Vertrieb
82
Produktbetreuer
Operativ ausgerichtet. Vorgesetzter: Produktmanager.
Ziele: Unterstützung bei Steuerung Koordination & Durchführung von produktbezogenen Maßnahmen und Aktivitäten. Unterstützung Produktmanager. Sicherstellung Produktinformation und Produktberatung.
Aufgaben: Markt- und Wettbewerbsanalyse. Mitwirken Produktstrategie. Mitwirken Entwicklung Produkt. Marketing und Vertrieb. Produktcontrolling. Dokumentation und Schulung
83
PM-Aufgaben
Markt- und Wettbewerbsanalyse. Produktstrategie und Management Produktlebenszyklus. Produktentwicklung: Strategie, Rahmen, Anforderungen, Abnahmen. Produktcontrolling und wirtschaftliche Optimierung. Unterstützung von Marketing und Vertrieb inkl. Presales bis hin zur produktbezogenen Steuerung von Maßnahmen. Zentrale Know-How-Stelle zum Produkt mit produktbezogener Dokumentation und Schulung.
84
Lebenszyklusmodell
Einführung, Wachstum, Reife, Sättigung, Degeneration
85
Produktportfolio
essenzielle Aufgabe im PM
Bezeichnet die Menge der von einem Unternehmen angebotenen Produktarten.
Portfoliomanagement ist ein dynamischer Entscheidungsprozess, bei dem die Liste der aktiven neuen Produkt- (und Entwicklungs-) Projekte eines Unternehmens ständig aktualisiert und überarbeitet wird.
86
Produktvision
Inspirierendes und langfristiges Leitbild für ein Produkt. Es wird ein klares Zielbild für das Produkt formuliert. Eine gute Vision beschreibt, warum es das Produkt gibt und welchen Mehrwert es seinen Nutzern und der Welt bieten kann. Zeithorizont bei digitalen Produkten: 2-5 Jahre.
87
Product Vision Board
Elemente mit Vision, Target Group, Needs, Product und Business Goals
88
Produktmanager = Product Owner?
PM: berichtet in Marketing/Business. Fokussiert auf Marktsegmente, Portfolio, ROI. Zuständig für Vision und Roadmap. Führt den Release
PO: berichtet in Entwicklung/Technologie. Fokussierung auf Produkt und Implementierung der Technologie. Zuständig für Implementierung. Führt die Iterationen.
89
Produktvarianten
Verschiedene Lösungen für dasselbe Anwendungsproblem. Varianten können sich ersetzen und bieten Kaufalternativen für Kunden. Trend zur Produktindividualisierung mehr Varianten.
90
SCAMPER
Substitute. Combine. Adapt. Modify. Put. Eliminate. Reverse
91
Design Thinking
Systematische Innovationsmethode, die in allen Lebensbereichen angewendet werden kann. Es ist kein Algorithmus, sondern eine Heuristik, die ganz bestimmte Verfahrensschritte vorgibt, die unter ganz bestimmten Bedingungen (multidisziplinären Teams), ihr vollständiges Erfolgsspektrum entfalten können
92
Design Thinking Ziel
Design Thinking hat zum Ziel, für Probleme neue Lösungen zu entwickeln
93
Design Thinking Prozess
Design Thinking erfolgt anhand eines strukturierten und iterativen Prozesses
94
Design Thinking Orientierung
Design Thinking orientiert sich konsequent an den Nutzern.
95
Design Thinking Beteiligte
Design Thinking wird von einem interdisziplinären Team angewendet.
96
Persönliche Eigenschaften Design Thinker
Optimismus, Empathie, Kooperationsfähigkeit, Integratives Denken, Experimentierfreude.
97
Ideenfindungs-Methoden
Heiße Kartoffel. Seestern. Ideen-Zug. Brainwriting
98
Iteration
Erarbeitetes hinterfragen und aus anderer Perspektive betrachten. Früher Austausch mit potenziellen Nutzern essenziell. Nach jedem Feedback im Team festhalten, was gelernt wurde, woran gearbeitet wurde.
99
Contextual Design Phasen
Contextual inquiry. Interpretation sessions and work modeling. Consolidation and affinity building. Visioning. Storyboarding. User environment design (UED). Paper prototypes and mock-up interviews.
100
Design Sprint
Große Challenge aussuchen. Sprint Team rekrutieren. Fünf Tage im Kalender blocken.
101
Design Sprint Phasen
Montag: Map/Target: Map erstellen, Ziel auswählen, Wie kommen wir da hin?
Dienstag: Sketch: Blitzdemonstration, Sketch
Mittwoch: Entscheiden: Storyboard, Entscheidung treffen
Donnerstag: Prototyp: Prototyp realisieren, Test-Run
Freitag: Test: Interviews, Muster finden, Plan erstellen
