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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Immaterielle Güter

A

Nutzungsrechte (Lizenzen) und Dienstleistungen

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Produkt

A

Ergebnis der Produktion und Sachziel einer Unternehmung oder auch Mittel der Bedürfnisbefriedigung

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Dokumentation

A

Lastenheft (Vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Leistungen eines Auftragnehmers. Pflichtenheft (Vom Auftragnehmer erarbeitete Realisierungsvorgaben auf Basis Lastenheft.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Stakeholder

A

Product Owner, Kunde, Gesetzgeber, Firma, Sponsor, Projektleiter, Kunde des Kunden, …

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Anforderungsingenieur

A

hilft unausgesprochene Erwartungen, Rahmenbedingungen, Prioritäten zu ermitteln, verwalten und aufzubereiten.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

PSP

A

bildet hierarchisch alle Projektschritte ab. Strukturierung ist phasenorientiert, fachgebietsorientiert, funktionsorientiert oder objektorientiert. Zuordnung von Anforderungen zu PSP-Elementen.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Doku von Anforderungen - Was?

A

Abweichungen, Alternativen, Wünsche, Änderungsanträge, Begründungen, Entscheidungen, Ergebnisse, Lücken, Prioritäten, Risiken, Verantwortlichkeiten.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Doku von Anforderungen - Qualitätskriterien

A

Vollständigkeit, Nachvollziehbarkeit, Korrektheit, Eindeutigkeit, Verständlichkeit, Konsistenz, Überprüfbarkeit, Aktualität

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Gewinnung Anforderungen - Warum?

A

Identifikation relevanter Anforderungsquellen. Gewinnung existierender Anforderungen. Entwicklung von innovativen Anforderungen.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

Arten Anforderungen

A

Existierende Anforderungen. Rahmenbedingungen. Innovative Anforderungen

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

Gewinnungstechniken

A

Interview, Workshop, Beobachtung, Schriftliche Befragung, Perspektivenbasiertes Lesen. Innovative Anforderungen: Brainstorming. Osborn-Checkliste. Walt-Disney-Methode

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

Workshop Phasen

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

Beobachtung

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q

Beobachtung Phasen

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q

Schriftliche Befragung Phasen

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q

Perspektivenbasiertes Lesen

A

Gewinnung von Anforderungen aus Dokumenten. Gewinnung von relevanten Stakeholdern, Dokumente und Systeme, falls sie im Dokument auftauchen. Lesen mit versch. „Hüten“ auf.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q

Perspektivenbasiertes Lesen Phasen

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
33
Q

Assistenztechnik Prototyp

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
34
Q

System

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
35
Q

Systemkontext

A

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)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
36
Q

Emergenz

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
37
Q

Nicht-deterministisches Verhalten

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
38
Q

Subjektive statt objektive Erfolgskriterien

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
39
Q

Altsysteme Austausch

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
40
Q

Altsysteme Alternative Weiterentwicklung

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
41
Q

Altsysteme Strategie

A

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
Q

Altsysteme Konsequenzen

A

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
Q

Verlässlichkeit

A

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
Q

Herstellen von Verlässlichkeit

A

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
Q

Verlässlichkeit Kosten

A

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
Q

Verlässlichkeit Entwicklungsmethoden

A

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
Q

Eingebettete Systeme

A

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
Q

Echtzeit

A

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
Q

Eingebettete Systeme Charakteristika

A

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
Q

Stimulus-Response-Modell

A

System reagiert auf Stimulus (Reiz) innerhalb bestimmter Zeit mit Response. Periodische Stimuli (Vorhersagbare, regelmäßige Zeitabstände). Sporadische Stimuli (unregelmäßig, unvorhersehbar).

51
Q

Edge Dominant Systems

A

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
Q

Software Produktlinie - Prinzipien

A

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
Q

Software Produktlinie - Motivation

A

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
Q

Software Produktlinie Definition

A

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
Q

Software Produktlinie Voraussetzungen

A

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
Q

Domain Engineering

A
  1. Domain Requirements Engineering. 2. Domain Design. 3. Domain Realisation. 4. Domain Testing.
57
Q

Application Engineering

A
  1. Application Requirements Engineering. 2. Application Design. 3. Application Realisation. 4. Application Testing.
58
Q

Arten von Variabilitäten

A

Gleichzeitig/nacheinander. Extern (Variabilität von Domänenartefakten sichtbar für Kunden) / intern (nicht sichtbar)

59
Q

Domain Requirements Engineering

A

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
Q

Application Requirements Engineering

A

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
Q

Compliance

A

Handeln in Übereinkunft mit den geltenden Vorschriften

62
Q

Regulierte technische Systeme

A

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
Q

Kritische Infrastrukturen

A

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
Q

Personenbezogene Daten

A

alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen (Betroffener)

65
Q

Datenschutz

A

Schutz des Einzelnen vor Beeinträchtigung seines Persönlichkeitsrechts beim Umgang mit seinen personenbezogenen Daten

66
Q

Datensicherheit

A

Schutz der gespeicherten Daten vor Beeinträchtigung durch höhere Gewalt, menschliche oder technische Fehler und Missbrauch

67
Q

Personenbezug

A

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
Q

Datenschutz Regelungen

A

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
Q

Datenschutz Durchsetzung durch Aufsichtsbehörden

A

Überwachung & Durchsetzung (Untersuchungsbefugnisse, Sanktionsbefugnisse), Information & Beratung.

70
Q

Technisch und organisatorische Maßnahmen (TOM

A

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
Q

Privacy by Design nach Hoepman

A

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
Q

Informationssicherheit

A

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
Q

Informationssicherheit Ziele

A

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
Q

Informationssicherheit Abgrenzung Datenschutz

A

Informationssicherheit will Schaden von Organisation abwenden (alle Daten). Datenschutz von Betroffenen (nur personenbezogene Daten).

75
Q

Cybersicherheit

A

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
Q

Arten Bedrohungen

A

Daten ausspähen nach erlangtem Zugriff. Unterbrechung (Systemausfall). Veränderung der Daten. Erzeugen neuer, falscher Daten im System.

77
Q

Arten von Maßnahmen

A

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
Q

Arten Sicherheitsanforderungen

A

Risikovermeidung. Risikoerkennung. Risikobegrenzung

79
Q

Sicherheitsanforderungen nach Firesmith

A

Identifikation. Authentifizierung. Autorisierung. Immunität. Integrität. Einbruchserkennung. Unleugbarkeit. Datenschutz. Sicherheitsüberprüfung. Wartungssicherheit

80
Q

Produktmanagement Grundprinzip

A

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
Q

Produktmanager

A

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
Q

Produktbetreuer

A

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
Q

PM-Aufgaben

A

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
Q

Lebenszyklusmodell

A

Einführung, Wachstum, Reife, Sättigung, Degeneration

85
Q

Produktportfolio

A

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
Q

Produktvision

A

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
Q

Product Vision Board

A

Elemente mit Vision, Target Group, Needs, Product und Business Goals

88
Q

Produktmanager = Product Owner?

A

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
Q

Produktvarianten

A

Verschiedene Lösungen für dasselbe Anwendungsproblem. Varianten können sich ersetzen und bieten Kaufalternativen für Kunden. Trend zur Produktindividualisierung  mehr Varianten.

90
Q

SCAMPER

A

Substitute. Combine. Adapt. Modify. Put. Eliminate. Reverse

91
Q

Design Thinking

A

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
Q

Design Thinking Ziel

A

Design Thinking hat zum Ziel, für Probleme neue Lösungen zu entwickeln

93
Q

Design Thinking Prozess

A

Design Thinking erfolgt anhand eines strukturierten und iterativen Prozesses

94
Q

Design Thinking Orientierung

A

Design Thinking orientiert sich konsequent an den Nutzern.

95
Q

Design Thinking Beteiligte

A

Design Thinking wird von einem interdisziplinären Team angewendet.

96
Q

Persönliche Eigenschaften Design Thinker

A

Optimismus, Empathie, Kooperationsfähigkeit, Integratives Denken, Experimentierfreude.

97
Q

Ideenfindungs-Methoden

A

Heiße Kartoffel. Seestern. Ideen-Zug. Brainwriting

98
Q

Iteration

A

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
Q

Contextual Design Phasen

A

Contextual inquiry. Interpretation sessions and work modeling. Consolidation and affinity building. Visioning. Storyboarding. User environment design (UED). Paper prototypes and mock-up interviews.

100
Q

Design Sprint

A

Große Challenge aussuchen. Sprint Team rekrutieren. Fünf Tage im Kalender blocken.

101
Q

Design Sprint Phasen

A

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