IGIS01

Question 1

Was ist ein Bit? (1.1)

Answer 1

Die kleinstmögliche Einheit der Information

Question 2

Was ist eine Bitfolge und warum benötigt man sie? (1.1)

Answer 2

Eine Abfolge von 0 und 1. Sie dient zur Speicherung von Informationsmengen, die größer sind als 1 Bit.

Question 3

Wie manifestieren sich alle Daten und Programme auf Rechnersystemen? (1.1)

Answer 3

Als eine Abfolge von 0 und 1 (Bitfolgen). Nur so können sie von den technischen Komponenten (CPU oder Hauptspeicher) verarbeitet werden.

Question 4

Wie viel Bit hat ein Lichtschalter? (1.1)

Answer 4

1 Bit

Question 5

Was ist die Boole’sche Algebra? Nennen Sie die Boole’schen Operatoren. (1.1)

Answer 5

Eine algebraische Struktur mit den beiden Elementen 0 und 1 sowie den logischen Operatoren UND, NICHT und ODER.

Question 6

Nenne und erläutere die Boole’schen Operatoren (1.1)

Answer 6

UND: 2-stellig; Er wertet zwei Boole’sche Werte x und y zu 1 aus, wenn beide Werte 1 sind. Anderenfalls wertet UND zu 0 aus.

ODER: 2-stellig; Er wertet zwei Boole’sche Werte x und y zu 1 aus, wenn mindestens einer der Werte 1 ist.

NICHT: 1-stellig; Er negiert den Wert x zu dem jeweils anderen. Der Wert 1 wird zu 0 ausgewertet, der Wert 0 zu 1.

Question 7

Wie werden Zahlen und Buchstaben im Rechner gespeichert und verarbeitet? Nennen sie zwei verschiedene Zeichensatztabellen. (1.1)

Answer 7

Kodierungssysteme wie ASCII oder UTF-8 übersetzen die Zeichen in eine Bitfolge. Dann kann der Rechner damit umgehen. Bei “Berechnungen” werden diese im Binärformat durchgeführt und dann wieder in das Dezimalsystem übersetzt.

Bsp.: “S” in UTF-8 - 01010011

2 Zeichensatztabellen: ASCII, UTF-8

Question 8

Was ist die sogenannte “Von-Neumann-Architektur”? Was war so bahnbrechend an ihr? (1.2)

Answer 8

Allgemeines Architekturkonzept zur Konstruktion von universellen Rechnern; vorgestellt von John von Neumann im Jahre 1945; die meisten Rechner heute sind „Von-Neumann-Rechner“ (Großrechenanlagen, Laptops, Spielekonsolen, Smartphones).

Die Idee, die Computer-Programme mit den zu verarbeitenden Daten in einen gemeinsamen Speicher (dem Hauptspeicher) des Rechners abzulegen. Da die Programme so ebenfalls in einem veränderbaren Speicher liegen, können somit auch die Vorschriften und Anweisungen, wie die Daten verarbeitet werden, angepasst werden, ohne die Hardware-Komponenten des Conmputersystems austauschen zu müssen. Anders als die Rechner seiner Zeit war der “Von-Neumann-Rechner” nicht zur Lösung eines speziellen Problems gedacht, sondern allgemein einsetzbar.

SPEICHER <——> BUS <——> STEUERWERK (TEIL DER CPU)

EIN-/AUSGABE <——> BUS <——> RECHENWERK (TEIL DER CPU)

Question 9

Für was steht die Abkürzung CPU? (1.2)

Answer 9

Central Processing Unit (Hauptprozessor)

Question 10

Nenne die Elemente der “Von-Neumann-Architektur” (5 Elemente) (1.2)

Answer 10

Speicher, Steuerwerk (Teil der CPU), Rechenwerk (Teil der CPU), Ein-/Ausgabe, Bus

Question 11

Welche Rolle übernimmt das Steuerwerk in der “Von-Neumann-Architektur”? Welche Aufgaben erfüllt es hierbei (4 Nennungen) (1.2)

Answer 11

Rolle des Koordinators

Aufgaben:

a. Auszuführende Befehle eines Programms in der richtigen Reihenfolge aus dem Speicher in die CPU laden
b. Befehle interpretieren
c. Quelle und Ziel der zu verarbeitenden Daten mit dem Rechenwerk verschalten
d. Rechenwerk mitteilen, welche Berechnung es mit den Daten durchführen soll

Question 12

Welche Rolle übernimmt das Rechenwerk in der “Von-Neumann-Architektur”?
Welche Aufgabe erfüllt es es (1 Nennung)? (1.2)

Answer 12

Rolle des Rechners

Aufgabe:
a. Alle Berechnungen – sie werden im Binärsystem durchgeführt; Rechenwerk verfügt über eine Menge an arithmetischen und logischen Funktionen

Question 13

Welche Rolle übernimmt der Speicher in der “Von-Neumann-Architektur”? (1.2)
Wie werden Daten gespeichert?

Answer 13

Rolle des “Aufbewahrers”

Aufgaben:

a. Aufbewahrung der binär codierten Daten und Programme. Es gibt hierbei nur einen Speichertyp, der nicht zwischen Daten- und Programmspeicher trennt
b. Aufteilung des Speicherbereichs in Speicherzellen mit eindeutigen Adresse; Daten in den Zellen können so gezielt abgerufen werden (Lokalisieren, Auslesen und/oder Verändern).

Question 14

Welche Rolle übernimmt die Ein-/Ausgabe in einem “Von-Neumann-Rechner”?
Welche Aufgaben erfüllt sie hierbei? (3 Nennungen) (1.2)

Answer 14

Rolle der Schnittstelle

Aufgabe:

a. Ein- und Ausgabe von Daten und Programmen
b. Kommunikation mit dem Anwender (z. B. über Bildschirm, Tastatur und Maus)
c. Kommunikation mit anderen Systemen (z. B. über Systemschnittstelle, Datennetze)

Question 15

Welche Rolle übernimmt der Bus in einem “Von-Neumann-Rechner”?
Welche Aufgaben erfüllt er? (2 Nennungen) (1.2)

Answer 15

Rolle der internen Kommunikation

Aufgaben:

a. Ein von allen Komponenten genutztes Datenübertragungssystem, dass der Kommunikation zwischen den Bestandteilen dient.
b. Bereitstellung der Daten und Programme; (deshalb bestimmt die Geschwindigkeit des Bus die Geschwindigkeit des Rechners maßgeblich mit)

Question 16

Beschreibe den Ablauf einer Berechnung in einem “Von-Neumann-Rechner”? (1.2)

Answer 16

1. Aufeinanderfolgende Befehle eines Programmes werden im Speicher in aufeinanderfolgenden Speicherzellen gespeichert.
2. Start eines Programms: Das Steuerwerk veranlasst das Laden des ersten Befehls in das Rechenwerk
3. Ausführen des Befehls
4. Zurück zu 1.

Question 17

Was ist ein verteiltes Softwaresystem? Nennen Sie ein Beispiel für etwas, das über ein solches System funktioniert? (1.3)

Answer 17

Es ist ein Softwaresystem, dass nur im Zusammenspiel mehrerer, über ein Kommunikationsnetz verbundener Rechner eingesetzt werden kann.

Beispiel: Online-Shop (Kunden-Rechner verbunden mit Firmen-Rechner)

Question 18

Nenne die Bestandteile eines minimalen verteilten Systems (5 Nennungen) (1.3)

Answer 18

Server, Client, Kommunikationsnetz, Nachricht, Vereinbarung über die Struktur der zu sendenden Daten

Question 19

Was ist ein Server? (1.3)

Answer 19

Ein Rechner, der Funktionen anbietet, die von anderen Rechnern über ein Kommunikationsnetz aufgerufen werden können. Die angebotenen Funktionen heißen auch Services (Dienste).
Ein Server ist nicht durch seine Hardware definiert, sondern durch seine Funktion. Ein Handy kann ein Server sein.

Bsp.: Server von Suchmaschinen bieten die Suche von Informationen im Internet an.

Question 20

Was ist ein Client? (1.3)

Answer 20

Rechner, die von Servern angebotene Dienste in Anspruch nehmen.

Bsp.: Ein Rechner, der etwas über einen Netzwerk-Drucker ausdrucken lässt.

Question 21

Was ist ein Kommunikationsnetz? Welche Komponenten hat ein Kommunikationsnetz (3 Nennungen)? (1.3)

Answer 21

Infrastruktur, über die Rechner Nachrichten austauschen können.

Komponenten:

a. Physikalischen Komponenten zur Datenübertragung (z. B. Kabel, elektromagnetische Wellen oder optische Signale)
b. Technische Komponenten zur Datenvermittlung (z. B. Router, Switches, Repeater und Bridges)
c. Netzwerkschnittstellen, um Rechner mit einem Kommunikationsnetz zu verbinden (z. B. Ethernet-Anschluss, Bluetooth-Chip) –> Netzwerkschnittstellen sind häufig eigentlich auch technische Komponenten)

Question 22

Was ist eine Nachricht im Kontext der industriellen Softwaretechnik? (1.3)

Answer 22

Eine logisch zusammenhängende Information, die zu einem Zeitpunkt von einer Anwendung verschickt wird.

Question 23

Was ist ein Datenpaket? (1.3)

Answer 23

Transportbehältnis für Nachrichten durch das Kommunikationsnetz (bei DSL-Anschluss: 1452 Byte pro Paket)

Question 24

Was sind Netzwerkarchitekturen und Protokolle im Kontext der industriellen Softwaretechnik? Welche Hauptprotokolle (Referenzmodelle) kennen Sie (2 Nennungen)?

Answer 24

Netzwerkarchitekturen: In einer Kaskade verschiedener Schichten werden Nachrichten in jeweils für den Übertragungskanal passende Pakete codiert und empfangene Pakete decodiert und zu einer Nachricht zusammengesetzt.

Protokoll: Die Funktionen, die für das Codieren und Decodieren von Nachrichten in einer Schicht eingesetzt werden

TCP/IP Transmission Control Protocol/Internet Protocol

OSI Open Systems Interconnection
- ein ISO genormtes 7-Schichtenmodell; benötigtes Hilfsmittel um eine offene Kommunikation zwischen verschiedenen Netzwerkgeräten unterschiedlicher Hersteller zu ermöglichen; die sieben Ebenen bauen aufeinander auf und jede Einzelne kann unabhängig von den Anderen benutzt werden; Unterteilung in zwei Hauptgruppen möglich (Transportsystem (1-4), Anwendungssystem (5-7)).

Question 25

Nenne und beschreibe die Schichten im OSI-Referenzmodell (7 Nennungen) (1.3)

Answer 25

Anwendungsschicht: anwendungsabhängige Vorschriften zum Aufbau und Austausch von Nachrichten (z. B. http (Hypertext Transfer Protocol) oder SMTP (Simple Mail Transfer Protocol)) Darstellungsschicht: Definition von Syntax und Semantik der übertragenden Informationen Sitzungsschicht: Aufbau von Sitzungen (engl.: Session) zwischen entfernten Rechnern; Aktionen beider Rechner können gezielt gesteuert und synchronisiert werden. Transportschicht: Direktkommunikation von Sender zu Empfänger; Nachrichten aus höheren Schichten werden in kleine Einheiten aufgeteilt und an die Vermittlungs- bzw. Internetschicht übergeben. Die Schicht sorgt auch dafür, dass die Datenpakete tatsächlich beim Empfänger ankommen. Vermittlungsschicht: Betrieb des Kommunikationsnetzes; Weg des Datenpakets von Sender zu Empfänger, Qualität der Übertragung (s. auch wie die Post funktioniert; es kommt an, wie genau ist dem Sender und Empfänger unbekannt) Sicherungsschicht: Sicherstellen, dass Daten vollständig und fehlerfrei versendet wurden. Flusskontrolle bei zu hoher Sendegeschwindigkeit und Fehlerbehandlung Bitübertragungsschicht: die binärcodierten, digitalen Datenpakete über den physikalischen Kommunikationskanal übertragen. Umwandlung in Strom, Licht, Funkwellen und wieder zurück in Binärcode.

Question 26

Nenne und beschreibe die Schichten des TCP/IP-Referenzmodells (4 Nennungen) (1.3)

Answer 26

Anwendungsschicht: anwendungsabhängige Vorschriften zum Aufbau und Austausch von Nachrichten (z. B. http (Hypertext Transfer Protocol) oder SMTP (Simple Mail Transfer Protocol)) Transportschicht: Direktkommunikation von Sender zu Empfänger; Nachrichten aus höheren Schichten werden in kleine Einheiten aufgeteilt und an die Vermittlungs- bzw. Internetschicht übergeben. Die Schicht sorgt auch dafür, dass die Datenpakete tatsächlich beim Empfänger ankommen. Internetschicht: TCP/IP; selbe Funktion wie die Vermittlungsschicht; Vermeidung von Überlastung Host-zu-Netz-Schicht: TCP/IP; Verbindungsaufbau, um die Datenpakete zu versenden

Question 27

Was ist ein betriebliches Informationssystem? (1.4)

Answer 27

Ein gewerblich eingesetztes Softwaresystem und sein Systemkontext. Der Systemkontext bezeichnet dabei die Nutzer des Systems und die mit dem System technisch verbundenen Systeme.

Question 28

Nenne und beschreibe die Systemklassen betrieblicher Informationssysteme nach dem IGIS-Skript (4 Nennungen). (1.4)

Answer 28

1. Kommunikationssysteme Systeme zur Unterstützung der zwischenmenschlichen Kommunikation (E-Mail, Telefon, Chat, soziale Netzwerke) Format: Meist Standardsoftware mit Lizenz- oder Abomodell (Teams, Skype, Outlook) 2. Querschnittssysteme Systeme, die keine Kommunikationssysteme sind, aber ebenfalls als Standardsoftware eingesetzt (Textverarbeitung, Tabellenkalkulation, Präsentationssoftware) Format: Meist Standardsoftware mit Lizenz- oder Abomodell (Office 365) 3. Operative Systeme Systeme, die gezielt Geschäftsprozesse und Aktivitäten in Organisationen unterstützen (CMS, Buchhaltungssoftware, Personalwesen, branchenspezifische Lösungen z. B. in der Logistik, ERP-Systeme (Enterprise Resource Planning) (z. B. SAP)) Format: Typischerweise stark auf die wertschöpofenden und unterstützenden Geschäftsprozesse hin angepasst. Oft Gegenstand von Projekten (z. B. zur Anpassung oder gar zur Neuentwicklung einer Lösung). 4. Dispositive Systeme Systeme, die der Unterstützung von Planungs- und Entscheidungsprozessen dienen. Es stehen Daten im Vordergrund (z. B. Data Warehouse, Busines-Intelligence-Lösungen) Format: Da sich die dispositiven Systeme häufig aus den operativen speisen, müssen sie ebenfalls angepasst werden und können nicht „von der Stange“ gekauft werden.

Question 29

Was ist ein Binärsystem? (1.1)

Answer 29

Ein Stellenwertwertsystem mit der Basis von 2 (Dualsystem). Die Stellen sind 0 und 1. Mit der Hilfe des Binärsystems können Informationen, aber auch logische Vorgängen (z. B. Entscheidungen) dargestellt werden. Sie ist die Grundlage für den Aufbau von Chips und Co.

Question 30

Erläutern Sie die folgende Aussage: "Digitale Systeme speichern und verarbeiten Informationen binär." (1.1)

Answer 30

Binäre Codierung (Informationen in Form von Bitfolgen) bildet den Übergang der Welt der digitalen Rechner in die reale Welt. Bitfolgen können physikalisch und elektrotechnisch relativ einfach nachgebildet werden. Die Bool'sche Algebra bilden die logischen Operatoren. Gemeinsam ist dies die Basis heutiger Prozessoren und Chips.

Question 31

Nennen Sie mindestens 3 Prinzipien für Rechnersysteme auf Basis der Von-Neumann-Architektur. (1.2)

Answer 31

1. Die Struktur des Rechners ist unabhängig vom zu lösenden Problem. Programme müssen im Speicher abgelegt werden. 2. Für Daten, Programme und Resultate wird derselbe Speicher genutzt. Dadurch können alle Daten im Speicher sowohl als Programme als auch als Eingabedaten interpretiert werden. 3. Der Speicher ist eindimensional in fortlaufenden Zellen adressiert.

Question 32

Grenzen Sie die Begriffe Nachricht und Datenpaket im Kontext des Nachrichtentransport/Nachrichtenfluss ab. (1.3)

Answer 32

Ein Datenpaket ist das Transportbehältnis für Nachrichten durch das Kommunikationsnetz. Ist die Nachricht größer als der Speicherplatz in einem für Kommunikationsnetz zulässigen Datenpaket, wird sie auf mehrere Datenpakete aufgeteilt.

Question 33

Nennen Sie mindestens 3 Softwaresysteme oder Softwareprodukte mit denen Sie in Ihrem Unternehmen persönlich arbeiten bzw. von deren Existenz wissen und ordnen Sie diese je einer Systemklasse zu. (Tut 1)

Answer 33

1. Zoom, Teams - Kommunikationssystem 2. Word, PPT, Excel - Querschnittsystem 3. SAP, Content-Management-Systeme, Buchhaltungssoftware (Lexware Buchhalter) - Operatives System 4. Quicksight - Dispositives System (Entscheidungsunterstützung; Datensammlung und -darstellung)

Question 34

Nennen Sie sechs Aspekte, die maßgeblich zur Komplexität von industriellen Softwaresystemen beitragen (6 Nennungen) (2.1)

Answer 34

a. Muss vielfältige Funktionen unterstützen b. Teil einer komplexen Anwendungslandschaft; muss über technische Schnittstellen mit anderen Softwaresystemen verbindbar sein c. Wird von vielen Anwendern benutzt d. Soll auf möglichst vielen Betriebssystemen und Geräten funktionieren e. Soll in möglichst vielfacher Hinsicht erweiterbar sein. f. Wird von vielen Personen erstellt. g. Besteht aus vielen verschiedenen Komponenten

Question 35

Worin unterscheiden sich Softwaresysteme maßgeblich von anderen industriellen Produkten? (2.1 und 2.2)

Answer 35

Sie sind immateriell. Software kann man nicht anfassen. Ein fertiges Softwaresystem manifestiert sich als eine Bitfolge (eine sehr lange Reihe von 0 und 1) auf Festplatten oder anderen Speichermedien. Kein Verschleiß; aber sie altert aufgrund der Umgebung in der sie sich bewegt. Schneller und leichter änderbar als technische Produkte Software ist nicht vermessbar; Güte nicht mit physikalischen Größen festzumachen (wie z. B. bei Rohstoffen) Begrenzung: Softwaresysteme sind nicht natürlich oder physikalisch begrenzt, sondern durch die Abstraktionsfähigkeit und die Kommunikationsfähigkeit der am Softwareprojekt beteiligten Personen begrenzt.

Question 36

Nennen und erläutern Sie die typischen Eigenschaften von Softwaresystemen (8 Nennungen) (2.1)

Answer 36

a. Korrektheit: Übereinstimmung mit Spezifikation; Sie soll genau das tun, was in der Spezifikation festgelegt wurde. b. Zuverlässigkeit: dauerhaft von den Anwendern einsetzbar c. Robustheit: Bei Bedienfehlern oder Fehlverhalten angeschlossener Systeme, soll sich die Software tolerant verhalten und keine unkontrollierten Fehler/Daten produzieren d. Usability (Gebrauchstauglichkeit): Anwender sollen sie einfach benutzbar finden e. Performanz: Einhaltung bestimmter Anforderungen an das Antwortzeitverhalten und den Ressourcenbedarf; Überprüfung durch Messen, Berechnen und Simulation. f. Wartbarkeit: Die Eigenschaft von Software, Änderungen wirtschaftlich sinnvoll durchführen zu können; über lange Zeit hin anpassbar sein g. Wiederverwendbarkeit: Möglichkeit, das System in einem anderen Kontext wiederverwenden zu können h. Portierbarkeit: Aufwand, um die Software auf anderen Plattformen (Datenbanken, Betriebssystemen, Geräten) lauffähig zu machen i. Interoperabilität: Mit geringem Aufwand mit anderen Systemen zusammenschließen bzw. in sie integrieren lassen. Dies sind keine Muss-Eigenschaften für jedes System. Vielmehr werden einzelne Eigenschaften je nach der Art des Systems entweder mehr oder weniger wichtig.

Question 37

Definiere Softwaretechnik (Software Engineering) (2.2) Wo ist die Disziplin der Softwaretechnik in der Informatik verortet und was sind die drei Teilbereiche, mit denen sie sich beschäftigt? (Tut 2)

Answer 37

Die strukturierte und methodische Planung, Erstellung und Weiterentwicklung von Softwaresystemen sowie deren Betrieb "Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwaresystemen. Zielorientiert bedeutet die Berücksichtigung z. B. von Kosten, Zeit, Qualität." --- Praktische Informatik Softwaremanagement Softwareentwicklung Softwarequalitätsmanagement

Question 38

Womit beschäftigt sich die Forschung im Bereich des Software Engineering? (2.2)

Answer 38

Weiterentwicklung bestehender sowie Entwicklung und Evaluierung neuer Methoden und Werkzeuge.

Question 39

Was sind Patterns im Kontext der Softwaretechnik (des Software Engineering) ? (2.2)

Answer 39

Organisatorische und technische Strukturen (Muster), die sich über mehrere Projekte hinweg bewährt haben.

Question 40

Nennen sie vier Gründe für die steigende Komplexität von Softwaresystemen (6 Nennungen möglich) (2.2).

Answer 40

* Leistungsfähigere Hardware, * Ausdrucksmächtigere Programmiersprachen, * Vernetzung von Rechnersystemen, * Ausbau von Übertragungskapazitäten, * Mobilisierung von Rechnersystemen (Handy), * Leistungsfähigere Entwicklungswerkzeuge.

Question 41

Nennen Sie zwei mögliche Risiken, warum ein noch nicht abgeschlossenes Softwareprojekt scheitern kann. (2.3) (3 Nennungen möglich)

Answer 41

* Zentrale Anforderungen nicht realisierbar (aufgrund zu hoher Anforderungen oder nicht/zu spät erkannter technischer, organisatorischer oder gesetzlicher Rahmenbedingungen) * Kostenexplosion; noch zu erwartende Kosten unabsehbar * Streit unter den Projektmitarbeiter:innen

Question 42

Nennen Sie zwei mögliche Risiken, warum ein ausgeliefertes Softwaresystem nicht eingesetzt werden kann (2.3) (3 mögliche Nennungen)

Answer 42

* Wichtige fachliche Funktion fehlen oder sind falsch umgesetzt * Vom Kunden geforderte Qualitätseigenschaften werden nicht erfüllt (z. B. zu langsam) * Das System wird von den Anwender:innen nicht angenommen (Bedienung, Oberfläche)

Question 43

Nennen Sie zwei mögliche Risiken der Wartung und Weiterentwicklung von Softwaresystemen. (2.3) (3 mögliche Nennungen)

Answer 43

* Dokumentation nicht ausreichend; Konsequenzen der Wartung nicht abschätzbar * Interne Struktur des Systems über Jahre hinweg degeneriert; Selbst kleine Anpassungen benötigen unwirtschaftlichen Aufwand * Wissensverlust; es gibt keine Fachkräfte (mehr), die sich mit den Programmiersprachen und Betriebssystemen auskennen.

Question 44

Was ist ein Stakeholder (in Bezug zur Softwareentwicklung)? (2.4)

Answer 44

Eine Person, die ein berechtigtes Interesse an ein System und dessen Erstellungsprozess hat (z. B. Nutzer, Auftraggeber, Datenschützer)

Question 45

Erläutern Sie, warum Softwareentwicklung ein stark erkenntnisgetriebener Prozess ist und welche Auswirkungen das auf ein Softwareprojekt hat (Dilemmasituation). (2.4)

Answer 45

Anforderungen an das zu erstellende System werden erst im Verlauf des Softwareentwicklungsprozesses erkannt. Dilemmasituation: Allerdings bilden die Anforderungen an das System den Ausgangspunkt für alle weiteren Aktivitäten innerhalb eines Projekts. In der Regel werden relevante Anforderungen von Anwendern und Kunden aber erst erkannt, nachdem sie eine erste Version des Systems gesehen haben

Question 46

Erläutern Sie, warum fehlendes Fachwissen auf Seiten der Softwareentwickler ein Projektrisiko ist. (2.4)

Answer 46

Das Entwicklungsteam muss die von den Stakeholdern formulierten Anforderungen fachlich verstehen, damit es ein benutzbares Softwaresystem ausliefern kann. Weil industrielle Softwaresysteme der heutigen Zeit in der Regel über eine Vielzahl technischer Schnittstellen in komplexe Anwendungslandschaften eingebunden sin, muss das Entwicklungsteam in der Lage sein, die fachlichen Zusammenhänge über Systemgrenzen hinweg zu kennen. Außerdem kann ein Projektteam mit Fachwissen über den Anwendungsbereich sicherer mit unklaren Anforderungen zurechtkommen, das es Lücken oder Fehler in den Anforderungen selbständig identifizieren und den Stakeholdern zielgerichtet Lösungen anbieten kann.

Question 47

Erläutern Sie, zu welchen Problemen mangelnde Kommunikation und Koordination in einem Softwareprojekt führen kann (2.4).

Answer 47

Diversität an unterschiedlichen Vorstellungen und Zielsetzungen in Bezug auf das Softwaresystem über die beteiligten Bereiche und Abteilungen hinweg; ergänzt durch mangelnde Fachkompetenz und nicht klar abgegrenzte Verantwortungsbereiche ... - unterschiedliche Zielvorstellungen - Nicht-Treffen bzw. Verschieben wichtiger Entscheidungen - Austragen von persönlichen Konflikten

Question 48

Nennen Sie die 5 Bereiche, die die wesentlichen Herausforderungen im Software Engineering darstellen. (2.5)

Answer 48

Wirtschaftliche Ungewissheit Cone of Uncertainty Technologische Ungewissheit - Die möglichen Entscheidungsspielräume hinsichtlich der technischen Lösung werden mit dem Verlauf des Projekts – auch aufgrund neu hinzukommender Anforderungen – immer kleiner, bis mit Projektende eine konkrete Lösung erarbeitet ist. Kommunikation - Viele verschiedene Stakeholder mit verschiedenen Hintergründen, verschiedenen Wissen, verschiedenen Zielen - Aufrechterhaltung der Kooperationsbereitschaft und der Kommunikation - Planänderungen den Stakeholdern in einer für sie verständlichen Art und Weise kommunizieren. - Einbeziehung beim Treffen von Entscheidungen und Qualitätssicherung • Zielkonflikte - Magisches Dreieck (Qualität, Kosten und Termin) • Komplexität

Question 49

Was ist der Cone of Uncertainty? Ordnen Sie in einer der Herausforderungen im Software Engineering zu. (2.5)

Answer 49

Cone of Uncertainty (Kegel der Ungewissheit): Veranschaulichung der wirtschaftlichen Ungewissheit Je früher in einem Softwareentwicklungsprojekt die Gesamtkosten geschätzt, umso höher ist die Abweichung vom tatsächlichen Aufwand am Projektende. Eine präzise Vorhersage von Kosten ist oft - anders als bei der Produktion von physischen Gütern - nicht möglich.

Question 50

Zeichne das magische Dreieck in Bezug auf Zielkonflikte in den Herausforderungen des Software Engineering (2.5)

Answer 50

# CHOOSE TWO Auch in der Softwareentwicklung bewegt man sich im Spannungsfeld zwischen Qualität, Kosten und Termin. Auch ändern sich die einzelnen Größen aufgrund der Ungewissheit des Projekts an sich, was das Dreieck zusätzlich komplex macht. Qualität (korrekt/funktionsfähig) /\ / \ / \ ---------- Kosten: im Budget Termin: rechtzeitig

Question 51

Was ist Analysis Paralysis im Kontext des Software Engineering? Was ist die Gefahr dabei? (2.5)

Answer 51

Phänomen von unangemessen aufwendigen Analyseaktivitäten. Dabei wird versucht, durch die Produktion komplexer Analyseergebnisse die Ungewissheit auszublenden. Hervorgerufen durch die Komplexität des Software Engineerings. Gefahr: Zu viele Ressourcen gebunden, die eigentlich bei der Umsetzung einer ersten Softwareversion helfen sollten. Die zu Beginn aufwendig erstellten Analysemodelle veralten außerdem - durch neu gewonnene Erkenntnisse bei der Umsetzung und nach Vorstellung der ersten Softwareversion - schnell.

Question 52

Beschreiben Sie anhand eines Szenarios, welche Herausforderungen die Zielkonflikte zwischen den Größen Kosten, Termin, Qualität ausgesetzt sind. (2.5)

Answer 52

Wenn im Rahmen eines Projekts sehr großer Wert auf Qualitätssicherung gelegt wird, gehen die Aktivitäten der Qualitätssicherung zu Lasten der rechtzeitigen Fertigstellung. Wenn der Fokus auf die Projektkosten gelegt wird und dabei alle Termine einzuhalten sind, dann bleiben weniger Ressourcen für die Qualitätssicherung. Wenn aber ein Projekt in hoher Qualität punktgenau zu einem Termin ausgeliefert werden soll, dann wird der Kostenrahmen nicht zu halten sein.

Question 53

Was ist Software? (2)

Answer 53

"Programme, zugehörige Daten und notwendige Dokumentationen, die es zusammengefasst erlauben, mit Hilfe eines Computers Aufgaben zu erledigen" [Balzert 2001, S.45] "Computer programs and associated documentation. Software products may be developed for a particular customer or may be developed for a general market." [Sommerville 2001, S.6] Software = Dokumentation, Programmcode, Daten

Question 54

Was bedeutet die Immaterialität von Software für die Erstellung von Softwareprodukten? (2 Tut)

Answer 54

- Tatsächlicher "Baufortschritt" kann nur schwer erfasst werden. - Physikalische Messgrößen sind nicht anwendbar. "Die Software hat jetzt 60 MB mehr." --> nutzlos. - Bestandteile können nicht direkt untersucht werden - Abhängigkeiten zwischen Bestandteilen sind komplex.

Question 55

Definiere "Softwarelebenszyklus" und was sind seine Phasen (5 Nennungen)? (3.1)

Answer 55

Softwarelebenszyklus: Eine Abfolge verschiedener Phasen, in denen sich ein Softwaresystem befinden kann. Eingesetzt für die mittel- und langfristige Projektplanung 1. Planung - Aktivitäten vor dem Start eines Entwicklungsprojekts 2. Entwicklung - Aktivitäten zwischen Start des Projektes und Inbetriebnahme des fertigen Systems, Erstellung des Systems 3. Betrieb - Inbetriebnahme des fertigen Systems 4. Wartung - Wartung und Weiterentwicklung nach Inbetriebnahme 5. Abschaltung - Aktivitäten mit dem Ziel das System aus dem Betrieb zu nehmen

Question 56

Welche Aktivitäten des IT-Managements können durch Einordnung von Softwaresystemen in ihre aktuelle Phase des Softwarelebenszyklus unterstützt werden? (3.1)

Answer 56

Überblick über den aktuellen Zustand der Systemlandschaft Darauf aufbauend - Personal-, Ressourcen- und Investitionsplanung aufstellen Es lassen sich außerdem bestimmte Aktivitäten und Methoden des Software Engineering ableiten (s. spätere Kapitel)

Question 57

Nennen Sie die typischen Anlässe für einen Softwarebedarf (3.2) (3 Nennungen)

Answer 57

1. Ablösung bestehender Altsysteme 2. Nachfrage der Fachabteilungen 3. Technologische Weiterentwicklung ZUSATZINFO: 1. Ablösung bestehender Altsysteme IT-Systeme unterliegen einem Alterungsprozess. Sie haben nur eine begrenzte Laufzeit. Nach erster Inbetriebnahme folgen Wartung und Erweiterung. Mit der Zeit wird Wartung und Weiterentwicklung allerdings entweder zu teuer oder das Know-how geht verloren oder die Software wird vom eigentlichen Hersteller nicht mehr unterstützt  Neue Software 2. Nachfrage der Fachabteilungen Insbesondere in den Branchen Versicherungen, Medien und Logistik verschaffen sich Firmen über ihre Software Wettbewerbsvorteile. Daher entsteht hier der Bedarf häufig auf Anfrage von Fachabteilungen. 3. Technologische Weiterentwicklung Sich ändernde technologische Rahmenbedingungen führen zu einem Bedarf an Softwaresystemen, denn sie erschließen neue Anwendungs- und Geschäftsfelder, die durch entsprechende IT-Lösungen unterstützt werden müssen.

Question 58

Nennen Sie vier typische Aktivitäten der Planungsphase und grenzen Sie diese voneinander ab (3.2)

Answer 58

Bedarfsermittlung: Ermittlung des Bedarfs und der Anlässe für ein neues Softwaresystem Make-or-Buy-Entscheidung: Prüfen und Entscheiden, ob ein System gekauft oder neu gebaut werden soll Zeit- und Ressourcenplanung: Erstellung des ersten Projektplans inklusive konkretere Zeit- und Ressourcenplanung Auftragsvergabe: Vergabe des Auftrags, z. B. an externe Dienstleister oder die interne IT-Abteilung

Question 59

Was ist eine Make-or-Buy-Entscheidung und welche Auswirkungen hat diese Entscheidung auf den Softwarelebenszyklus (3.2)

Answer 59

Im Kontext der Bedarfsplanung: Erfüllt ein bereits bestehendes System die Anforderung oder gibt es Standard-Produkte, die für unternehmensspezifische Anforderungen angepasst werden können [BUY] (SAP Business Suite, Oracle E-Business Suite) oder muss die Software neu entwickelt werden [MAKE]. Eventuell werden in diesem Schritt Vorstudien, Testinstallationen oder erste Anwendungsprototypen erstellt und ausprobiert (je nach Wichtigkeit des Systems) Falls am Markt ein passendes System verfügbar ist, entfällt die Phase "Entwicklung" und die Phase "Wartung" wird deutlich weniger stark ausgeprägt.

Question 60

Was sind die Kernaktivitäten des Software Engineerings in der Phase der Entwicklungsphase des Softwarelebenszyklus? (3 Nennungen) (3.3)

Answer 60

1. Requirements Engineering und Spezifikation 2. Architektur und Implementierung 3. Qualitätssicherung

Question 61

Was geschieht grob in der Phase des Requirements Engineering und der Spezifikation in der Phase Entwicklung des Softwarelebenszyklus? (2 Nennungen) (3.3)

Answer 61

Requirements Engineering und Spezifikation * Fachliche Anforderungen werden verfeinert und weiter detailliert (RE). * Dokumentation der erforderlichen Eigenschaften des zu erstellenden Systems (Spezifikation)

Question 62

Was geschieht grob in der Phase der Architektur und Implementierung in der Phase Entwicklung des Softwarelebenszyklus? (2 Nennungen) (3.3)

Answer 62

* Festlegung des internen Aufbaus des Softwaresystems anhand einer Abwägung der Bedürfnisse der verschiedenen Stakeholder * Implementierung (Konstruktion des System durch Erzeugung des Quellcodes) des Programmcodes des Systems

Question 63

Was geschieht grob in der Phase der Qualitätssicherung in der Phase Entwicklung des Softwarelebenszyklus? (2 Nennungen) (3.3)

Answer 63

* Testen des Programmcodes in verschiedenen Teststufen, je nach aktuellem Stand des Projekts * Erfüllen die erzeugten Artefakte die festgelegten Anforderungen?

Question 64

Was sind die Kernaktivitäten in der Phase Betrieb des Softwarelebenszyklus? (3 Nennungen) (3.4)

Answer 64

``` 1. Bereitstellung der Ausführungsumgebung - Eine Infrastruktur (z. B. in einem Rechenzentrum) wird für das Softwaresystem zur Verfügung gestellt ``` 2. Integration - Das neue System wird an den von den Entwicklern vorgesehenen technischen Schnittstellen angeschlossen 3. Inbetriebnahme - Nach Abschluss der Integration müssen alle technischen Schnittstellen bestehender System auf das neue System umgestellt sein. Für die Sicherstellung der Verfügbarkeit und Sicherheit muss die neue Anwendung ebenfalls an technische Überwachungssysteme angeschlossen werden. Darüber hinaus muss die IT-Sicherheit die neue Anwendung mit in die Liste der zu überwachenden Anwendungen aufnehmen.

Question 65

Welche Themen sind bei der Bereitstellung einer Ausführungsumgebung in der Phase Betrieb des Softwarelebenszyklus besonders zu beachten? (5 Nennungen)

Answer 65

1. Massive Nutzung durch Anwender In der Betriebsphase ist die Arbeit am Programmcode „eingestellt“ und das System wird intensiv von den Anwendern (in großen Firmen bis zu 1.000; Werden Kunden und Endanwender eingebunden 10.-100.000de von Personen) 2. Sicherheitsrisiko steigt • Angriffsrisiko – besonders wenn über das Internet von Personen erreichbar; • Bei einem Ausfall des Systems sollen Daten nicht verloren gehen; • Das System soll Lastspitzen verkraften, aber im Normalbetrieb nur so viel Ressourcen in Anspruch nehmen, wie nötig. 3. Zu diesem Zweck: Bereitstellung einer Infrastruktur (s. andere Frage) 4. Qualität der Anwendung in diesem Kontext sicherstellen (s. andere Frage) 5. Für Stabilität sorgen – Zielkonflikt zwischen Entwicklung und Betrieb: Einerseits muss schnell auf fachliche Anforderungen reagiert werden, andererseits soll das System zuverlässig und sicher laufen

Question 66

Was ist eine Produktivumgebung (auch: Liveumgebung)? (3.4)

Answer 66

Hard- und Softwareumgebung des Systems, in der es von den Anwendern zuverlässig genutzt werden kann. Das System muss an die von den Entwicklern vorgesehenen technischen Schnittstellen angeschlossen werden. (CRM-System an die Adressdatenbank zur automatischen Validierung von Adressen)

Question 67

Was muss bei der Inbetriebnahme in der Phase des Betriebs des Softwarelebenszyklus beachtet werden? (3.4)

Answer 67

Alle technischen Schnittstellen bestehender Systeme auf das neue umgestellt. An technische Überwachungssysteme angeschlossen, die dem Management kontinuierlich Informationen über den Ressourcenbedarf (CPU, Hauptspeicher, Datenspeicher, Netzwerkzugriffe) liefert. In die Liste der von der IT-Sicherheit überwachten Systeme aufnehmen

Question 68

Welche zwei großen Bereiche umfasst die Phase Wartung im Softwarelebenszyklus (3.5) ?

Answer 68

1. Wartung - korrigierende Anpassung von Softwaresystemen | 2. Weiterentwicklung - Erweiterung um fachliche Funktionen

Question 69

Was ist ein Releaseplan? (3.5)

Answer 69

Plan für jede Anwendung, in dem Termine genannt werden, zu den jeweils ein Update der Anwendung zur Verfügung gestellt wird. Ein Hilfsmittel zur Koordination der an Wartungsaufgaben beteiligten Abteilungen.

Question 70

Welche Qualitätsanforderung werden bei Betriebnahme an eine Anwendung gestellt (3 Nennungen)? (3.4)

Answer 70

1. Sicherheit 2. Verfügbarkeit 3. Skalierbarkeit

Question 71

Welche IT-Elemente sind zur Bereitstellung einer Software notwendig? (9 Nennungen) (3.4)

Answer 71

``` Server, Betriebssysteme, Datennetze, Speichersysteme, Sicherheitssysteme, Stromversorgung, Klimatisierung und Anbindung an externe Netze (Internet), Nutzerverwaltung – Vergabe von Zugriffsrechten ```

Question 72

Begründen Sie kurz, warum Softwaresysteme auch nach Inbetriebnahme ganz sicher geändert werden müssen (1 Nennung - mehrere möglich) (3.5).

Answer 72

QS kann nicht alle Restfehler finden. auch: Neue Anforderungen technologische Weiterentwicklung Sicherheitslücken

Question 73

Für welche Phase werden häufig höhere Aufwände nötig sein: Erstellung oder Wartung? (3.5)

Answer 73

Wartung (mit einem Faktor 2-4 mehr als Erstellung)

Question 74

Nennen Sie drei Gründe für die Abschaltung (retirement) eines Softwaresystems (3.6)

Answer 74

1. Ablösung bestehender Systeme durch neue Systeme 2. Zusammenführung bzw. Vereinheitlichung von Anwendungen nach der Zusammenlegung von IT-Organisation (z. B. Zusammenschluss von Unternehmen) 3. Aufgeben von Geschäftsfeldern oder Auslagern von Aktivitäten im Unternehmen

Question 75

Welche Themenkomplexe Entstehung in der Phase Abschaltung (retirement) des Softwarelebenszyklus (4 Nennungen)?

Answer 75

1. Herauslösung aus der Anwendungslandschaft a. Identifikation von Abhängigkeiten (technologsicher Art; z. B. an den Schnittstellen) b. Abdeckung der Abschaltung eines Systems durch ein neues oder bereits bestehendes System c. Systemdokumentation (hoffentlich vorhanden) heranziehen; fehlt die Dokumentation muss der Quellcode analysiert werden. Sind diese Wissensträger noch im Unternehmen? Bei alten Systemen fraglich 2. Migration von Daten a. Gespeicherte Daten müssen übernommen werden (z. B. Kontoverwaltung bei Banken) b. Herausforderungen: Abbildungen des alten Datenschemas im neuen Umfeld; Menge der zu migrierenden Daten 3. Kündigung von Verträgen (Lizenzen, Nutzungsrechte, Wartungsverträge bei Dienstleistern) 4. Weiterqualifizierung von Beschäftigten Kann das Personal auch mit dem neuen System arbeiten? Falls nein, frühzeitig weiterqualifizieren

Question 76

Welche Risiken bestehen bei der Herauslösung von Altsystemen aus der Anwendungslandschaft (3 Nennungen)? (3.6)

Answer 76

1. Liegt die Dokumentation nur unvollständig oder in einer veralteten Version vor, können Abhängigkeiten nur durch probeweises Abschalten identifiziert werden. 2. Fehlendes Wissen zu alten Technologien, da die Wissensträger der alten Technologien bereits das Unternehmen verlassen haben. 3. Bei der Migration von Daten darf es auch bei der Übertragung von mehreren Millionen Vertragsdaten - diese Anzahl ist bei Kranken- oder Lebensversicherungen durchaus üblich - keinen Fehler geben.

Question 77

Definiere Requirements Engineering. In welcher Phase des Softwarelebenszyklus wird es durchgeführt? (4.1)

Answer 77

Requirements Enginneering ist ein kooperativer, iterativer, inkrementeller Prozess, dessen Ziel ist, zu gewährleisten, dass: 1. Alle relevanten Anforderungen bekannt und in erforderlichem Detaillierungsgrad verstanden sind. 2. Alle Anforderungen konform zu den Dokumentationsvorschriften dokumentiert bzw. konform zu den Spezifikationsvorschriften spezifiziert sind. 3. Die involvierten Stakeholder ausreichende Übereinstimmung über die bekannten Anforderungen haben. PHASE: Entwicklung

Question 78

Nenne Merkmale des Requirements Engineering (2 Nennungen) (4.1)

Answer 78

1. Kooperativ: Es sind immer mehrere Personen oder Personengruppen (Anforderungsquelle: Stakeholder) involviert. 2. Iterativ/inkrementell: Keine einzelne, abgeschlossene Aktivität zu Beginn eines Softwareprojekts, sondern mehrfache Durchführung, auch projektbegleitend, da Softwareentwicklung ein erkenntnisgetriebener Prozess ist. Die Anforderungen werden umfangreicher, besser, spezifischer (inkrementelle Verbesserung).

Question 79

Nenne die drei Kernaktivitäten des Requirements Engineering. Werden sie in einer bestimmten Reihenfolge ausgeführt? (4.1)

Answer 79

1. Ermittlung von Anforderungen Die Anforderungen müssen von den Beteiligten und Betroffenen sowie sonstigen Quellen z. B. Normen, Gesetzestexte, Standards, systematisch gewonnen werden (Balzert, 444) 2. Dokumentation von Anforderungen 3. Prüfen und Abstimmen von Anforderungen Nein, es gibt keine bestimmte Reihenfolge. Die Kernaktivitäten werden je nach Bedarf ausgeführt.

Question 80

Nenne und beschreibe den systematischen Ablauf zur Ermittlung von Anforderungen an ein Softwaresystem im RE (4 Nennungen) (4.1)

Answer 80

Sequentiell - Warum sequentiell? 1. Systemkontext bestimmen: Welche Stakeholder und Systeme haben direkte Abhängigkeiten zu dem zu erstellenden System? 2. Quellen für Anforderungen ermitteln: Stakeholder, Dokumente (z. B. Gesetze), andere Systeme (Altsystem, Konkurrenzsystem) 3. Geeignete Ermittlungstechniken auswählen: je nach Anforderungsquelle und Projektsituation (menschlich (Sind die Leute überhaupt bereit zu einem Workshop, Brainstorming?), fachlich (Haben wir das notwendige Know-how?), organisatorisch (Zeit und Geld)) (z. B. Befragung, Kreativitätstechnik (Brainstorming), Beobachtung, Dokumentenzentrierte Techniken, Erstellen eines Prototyps) 4. Anforderungen unter Einsatz der Techniken ermitteln: aus 2. und 3. Anforderungen im für die aktuelle Situation erforderlichen Detailgrad erstellen Ziel: Identifikation der Anforderungen an das System, die zur Erreichung des Ziels benötigt werden

Question 81

Nenne und beschreibe den systematischen Ablauf zur Dokumentation von Anforderungen an ein Softwaresystem im RE (4 Nennungen) (4.1)

Answer 81

Sequentiell 1. Zweck und Zielgruppe der Dokumentation bestimmen 2. Detailebene und Darstellungsart auswählen: in Abhängigkeit von Zweck und Zielgruppe 3. Anforderungen dokumentieren: in einem für 1. angemessenen Format 4. Prüfen: Passt die Dokumentation noch zu Zweck und Zielgruppe? Ziel: Festhalten eines aktuellen Erkenntnisstands für alle Stakeholder, sodass sich jeder stets Überblick verschaffen. Oft sind Anforderungsdokumente auch Teil von Softwareerstellungsverträgen.

Question 82

Nenne und beschreibe den systematischen Ablauf zum Prüfen und Abstimmen von Anforderungen an ein Softwaresystem im RE (4 Nennungen) (4.1)

Answer 82

Sequentiell 1. Prüfkriterien festlegen: bes. im Hinblick auf den Zeitplan 2. Prüfprinzipien und Prüftechniken auswählen: Abhängig von Kriterien, Zeit und Stand der Dokumentation 3. Prüfung durchführen und Ergebnisse dokumentieren: Nur Ergebnisse dokumentieren, die Fehlerbehebung erfolgt im Anschluss 4. Abstimmen der Anforderungen/Konfliktmanagement: bei sich widersprechenden Anforderungen Ziel: Die Qualität der Menge der dokumentierten Anforderung hinsichtlich der Kriterien Inhalt, Dokumentation und Abgestimmtheit sicherstellen. Missverständnisse durch Mehrdeutigkeiten vermeiden

Question 83

Warum ist das Konfliktmanagement im RE so wichtig? (4.1)

Answer 83

In Projekten zur Erstellung von industriellen Informationssystemen sind viele verschiedene Stakeholder einzubeziehen. Im Verlauf des Requirements Engineerings werden daher in der Regel konkurrierende oder sich gegenseitig widersprechende Anforderungen ermittelt und dokumentiert.

Question 84

Definiere Spezifikation. Was ist ihr Ziel? (4.2)

Answer 84

Spezifikation = Aktivitäten zur Dokumentation von detaillierten technischen Anforderungen. Die Spezifikation eines Systems gibt aus fachlicher Sicht den technisch detaillierten Rahmen für Designentscheidungen vor. Dabei trifft eine Spezifikation keine Entscheidung darüber, wie das System intern konstruiert werden muss, sondern beschreibt stets nur die nach außen sichtbaren Systemeigenschaften. Aus Sicht der Spezifikation ist das System eine Black-Box, über deren inneren Aufbau nichts bekannt ist. Ermittelte fachliche Anforderungen werden bei der Spezifkation um technische Anforderungen erweitert und verfeinert. Das Resultat ist eine fachlich-technische Spezifikation, auf deren Basis zunächst das Systemdesign und anschließend die Implementierung des Systems erstellt wird. Außerdem werden auf Grundlage der Spezifikation Testfälle für die verschiedenen Teststufen erstellt, in denen das Softwaresystem auf Erfüllung der Anforderungen getestet wird.

Question 85

Grenze das Requirements Engineering von der Spezifikation ab (4.2)

Answer 85

In mancher Literatur wird zwischen RE und Phase Spezifikation nicht wirklich unterschieden. Dort wird die Spezifikation als Ergebnis des RE dargestellt. Unser Skript tut dies nicht. Hier stellt die RE die fachlichen Anforderungen auf und die Spezifikation ergründet, mit welchen Mitteln diese fachlich-technischen Anforderungen erreicht werden können. Anforderungen werden in der Spezifikation konkretisiert und so verfeinert, dass sie messbar sind. Die Spezifikation ist eine Erweiterung und Detaillierung der Anforderungen aus dem RE. Bsp. Requirements Engineering: "Der Anwenderzugang muss mit einem Passwort gesichert werden." Spezifikation: "Das Passwort muss mindestens 8 Zeichen und mindestens 1 Sonderzeichen, 1 Großbuchstaben und einen Ziffer enthalten."

Question 86

Nenne und beschreibe die Elemente einer Spezifikation (4 + 2 Nennungen). (4.2)

Answer 86

1. Datenmodell: Geschäftsobjekte, die im System verarbeitet werden, sowie deren Beziehung untereinander (Bsp.: Schadensmeldung, Versicherungsantrag, Kundendaten) 2. Fachfunktionen: Fachliche Beschreibung der Aufgaben des Systems bzw. der spezifischen Komponente. (Bsp.: Algorithmus zur Prämienberechnung) 3. Geschäftsregeln: Regeln zu einem Geschäftsobjekt, die nicht verletzt werden dürfen (Bsp.: Datum des Vertragsbeginns muss vor dem des Vertragsendes liegen, Summe des Warenkorbs darf nicht negativ sein) 4. Eigenschaften die zu Schnittstellen (Kunden und Systemumfeld) spezifiziert werden: a. Zweck der Schnittstelle auf einer fachlichen Ebene (Bsp.: Validierung von Adressdaten auf Gültigkeit) b. Technisches Protokoll bzw. die technischen Regeln, nach denen das System mit seinem Umfeld kommuniziert (Bsp.: http, FTP) c. Datenstruktur der Nachrichten, die evtl. mit anderen Systemen ausgetauscht werden (Bsp.: XML, CSV) d. Benutzeroberfläche: Aufbau und Verhalten bei den Anwendern --- 5. Qualitätseigenschaften: Bsp.: „Das Inkasso-System soll einer Verfügbarkeit von 99,9 % innerhalb eines Jahres besitzen. Planmäßige Wartungsarbeiten schränken die Verfügbarkeit nicht ein.“ Daraus folgt: Es stehen ca. 8:45h für eine außerplanmäßige Wartung zur Verfügung. 6. Randbedingungen: technischer oder organisatorischer Art (Bsp. Gesetze, Styleguides)

Question 87

Was bedeutet GUI? (4.2)

Answer 87

Graphical User Interface | Grafische Benutzeroberfläche

Question 88

Welche Eigenschaften werden in einer Spezifikation in Bezug auf GUIs festgelegt? (3 Nennungen) (4.2)

Answer 88

1. Inhalte und Aufbau von einzelnen Dialogmasken: Art, Größe, Position, Farbe und Inhalt von Elementen einer Bildschirmseite (z. B. Eingabefelder, Texte, Schaltflächen, Bilder) 2. Validierung von Daten: Regeln zur Prüfung auf fachliche Plausibilität von Eingaben 3. Dialogfluss: Führung des Anwenders durch die Oberfläche in Abhängigkeit von eingegebenen Daten und Aktionen des Anwenders Spezifikation sowohl visuell als auch textuell (Zusammenhänge, die sich nicht unmittelbar visuell ausdrücken lassen z. B. Regeln zur Aktivierung und Deaktivierung von GUI-Elementen, Validierungsregeln)

Question 89

Welche Einzelschritte stehen bei der Spezifikation von Aufbau und Abläufen eines Softwaressystems an? (4 Nennungen). Definiere zentrale Begriffe. (4.2)

Answer 89

1. Identifikation und Spezifikation fachlicher Komponenten Komponenten: Komplexe Softwaresysteme werden in Komponenten aufgeteilt, wobei jede Komponente eine unabhängige Softwareeinheit ist, die aufgrund vereinbarter Schnittstellen mit anderen Komponenten zu einem Softwaresystem zusammengestellt werden kann. a. Fachliche Komponenten identifizieren und gegenüber anderen Komponenten abgrenzen b. Interne Funktionen von Komponenten spezifizieren c. Abläufe und die logische Struktur der ausgetauschten Nachrichten an Schnittstellen von Komponenten spezifizieren 2. Spezifikation fachlicher Datenmodelle Fachliche Datenmodelle: Modelle zur Spezifikation fachlicher Entitäten (Geschäftsobjekte) und deren Zusammenhänge Aufbau, Zusammensetzung und Beziehungen zwischen verschiedenen fachlichen Entitäten werden spezifiziert. Es soll die Austauschfähigkeit von Daten erhalten bleiben (die gleichen Daten in verschiedenen Systemen) 3. Spezifikation von Geschäftsregeln Geschäftsregel: Eine Aussage, die einen fachlichen Aspekt definiert oder bedingt (z. B. Zusicherungen über die Struktur von Geschäftsobjekten oder das Verhalten von Geschäftsprozessen) (Bsp.: Ein Vertrag muss immer einer Kundennummer zugeordnet sein oder „Ein Auftrag von über 500.000 EUR muss immer von mindestens zwei Sachbearbeitern begutachtet werden.)

Question 90

Was gilt es bei der Spezifikation von Qualitätseigenschaften zu beachten (2 Nennungen)?

Answer 90

Softwarequalität (ISO 9126-Standard): Gesamtheit der Merkmale und Merkmalswerte eines Softwareprodukts, die sich auf dessen Eignung zur Erfüllung gegebener Erfordernisse bezieht. 1. Konkrete Spezifikation: Die Qualitätseigenschaften müssen in der Spezifikation auf Basis von Werten konkretisiert werden. Bsp.: „Das System muss viele Nutzer gleichzeitig arbeiten lassen können.“ (DAS HILFT NICHT). Die genauen Qualitätseigenschaften haben massive Auswirkungen auf die technische Umsetzung. 2. Testbarkeit: Die Qualitätseigenschaften sollten testbar sein, sodass Testfälle erstellt werden können.

Question 91

Welche Bedeutung hat die Dokumentation von Anforderungen im RE? Was erfüllt sie? (5 Nennungen) (Tut 4.1)

Answer 91

1. Persistenz, Gemeinsame Informationsbasis 2. Fördert Kommunikation, Fördert Objektivität 3. Einarbeitung neuer Mitarbeiter, vermindert Abhängigkeiten von Wissensträgern 4. Bestandteil von rechtsgültigen Verträgen 5. Basis für die Prüfung der Leistungserbringung

Question 92

Was kann alles in einer Dokumentation im RE dokumentiert werden? Nennen Sie einige Beispiele. (Tut 4.1)

Answer 92

1. Argumente von Stakeholdern 2. Abweichung von Dokumentationsvorschriften 3. Benutzte Anforderungsquellen - Wachsende Komplexität 4. Ergebnisse aus Prototypbenutzung, Beobachtung, Brainstormings, Inspektionen, Interviews, Priorisierung, Reviews

Question 93

Was ist so besonders am Begriff Architektur im Kontext der industriellen Softwaretechnik? (5.1)

Answer 93

Der Begriff „Architektur“: Es hat sich keine allgemeingültige Definition durchgesetzt. Der Begriff wird in verschiedenen Organisationen und Kontexten nach Vorliebe anders verwendet. In diesem Skript verwenden wir den Begriff Architektur für alle Festlegungen und Entscheidungen über das System, die vor der Implementierung getroffen werden. Also als Sammelbegriff für alles, was an anderer Stelle auch als Entwurf, Design, Grobentwurf oder Feinentwurf bezeichnet wird. Zum Beispiel: Prozess der Gestaltung von Softwaresystemen, Titel einer IT-Architekturtypologie (Client-Server-Architektur), Fachgebiet der IT-Architektur, Ergebnis für das ein IT-Architekt verantwortlich ist, Bezeichnung für die Wissenschaft vom Gestalten von IT-Systemen, also die Lehre der IT-Architektur Architektur kann also Aktivität sein, aber auch ein Ergebnisartefakt.

Question 94

Wie wird der Begriff der "Architektur" im Skript definiert? (5.1)

Answer 94

Es gibt keine einheitliche Definition. Architektur (im Sinne von Design): Aus den fachlichen Anforderungen (RE) und der Spezifikation (technisch) werden konkrete Festlegungen getroffen, wie das zu erstellende System diese Anforderungen erfüllt. Im Skript ist "Architektur" ein Sammelbegriff für alles, was anderer Stelle auch als "Entwurf", "Design", "Grobentwurf" oder "Feinentwurf" bezeichnet wird.

Question 95

Was ist eine Architekturbeschreibung und wozu dient sie? (5.1)

Answer 95

Sie ist das Ergebnis der Aktivitäten des Architekten, das dem Entwicklerteam als Vorlage und Rahmenwerk (zur Implementierung) dient. Sie steht zwischen RE/Spez und Implementierung. Der IT-Architekt erstellt die Architekturbeschreibung (auch: Architekturdefinition). Man kann ein System auch ohne Architektur bauen (wie auch ein Haus), jedoch besteht dann die Gefahr, dass Elemente vergessen werden, oder es den Belastungen nicht standhält. Architektur ist systemimmanent.

Question 96

Was sind die Kernaktivitäten der Architekturerstellung (3 Nennungen)? (5.1)

Answer 96

1. Erfassen der Anforderungen und Interessen der Stakeholder (Stakeholder, Aufwand, Dokumentation) 2. Entwerfen einer Architektur, die diese Menge an Anforderungen erfüllt Entwurfsentscheidungen, eine erste Architekturbeschreibung, die geprüft wird, evtl. muss die IT-Architektur noch einmal angepasst werden 3. Beschreiben und Dokumentieren der Architektur Iterative Erstellung der Architekturbeschreibung; Architektur unter Verwendung von Softwaremodellen technisch dokumentieren.

Question 97

Was ist beim Erfassen der Anforderungen und Interessen der Stakeholder bei der Architektur von Softwaresystemen wichtig (3 Nennungen)?

Answer 97

1. Was ist den Stakeholdern wichtig? - Fachliche Anforderungen - Stakeholder in der Entwicklung - Stakeholder, die am Betrieb der Lösung beteiligt sein werden - Auftraggeber 2. Aufwandsschätzung 3. Dokumentation der eingeschränkten Menge an Anforderungen und Annahme durch die Stakeholder

Question 98

Welche Möglichkeiten zur Dokumentation von IT-Architekturen kennen Sie (4 Nennungen)? Welche würden sie warum empfehlen? (5.1)

Answer 98

1. Für erste Ideen: Skizzen, PowerPoint-Grafiken (s. Abb. 16) – lässt einen sehr großen Interpretationsspielraum 2. Strukturierte Softwaremodelle (UML) (Abb. 17): uneingeschränkt empfohlen Notationselemente haben hier eine festgelegte Semantik, die weltweit verbreitet ist 3. Architekturbeschreibungssprachen (ADL) – in der Forschung 4. Programmcode – allerdings kein einfacher Überblick mehr und nur von Experten lesbar.

Question 99

Was ist eine Herausforderung im Wechselspiel zwischen Architekturbeschreibung und der tatsächlichen Systemarchitektur? (5.1)

Answer 99

Divergenz der dokumentierten Design-Entscheidungen in Form der Architekturbeschreibung und der tatsächlichen Systemarchitektur.

Question 100

Erläutern Sie Einsatzszenarien für Architekturdokumentationen (2 Nennungen) (5.1)

Answer 100

1. A priori: Erstellung der Dokumentation vor der Umsetzung des Systems auf Grundlage von Designaktivitäten und -entscheidungen. Ziel: Vereinbarungen über das System zu explizieren und zu dokumentieren (Soll-Zustand) 2. Ex post: Erstellung der Dokumentation nach der Umsetzung des Systems auf Grundlage des implementierten Programmcodes. Ziel: Darstellen und Dokumentieren der tatsächlich implementierten Architektur (Ist-Zustand). Vergleich geplante/implementierte Architektur, Einhaltung von Normen usw.

Question 101

Nenne die Ebenen von IT-Architekturen (3 Nennungen) (5.1)

Answer 101

1. Übersicht über fachliche Konzepte und Zusammenhänge (Facharchitektur) Dokumentation von fachl. Elementen, Akteuren und Abläufen sowie deren Abhängigkeiten und Beziehungen zueinander 2. Softwarearchitektur Vorgabe der Struktur eines Softwaresystems, innerhalb derer Softwareentwickler den Programmcode implementieren. Dokumentation der tatsächlichen Struktur eines Softwaresystems 3. IT-Unternehmensarchitektur (s. Tabelle 2 für die Details bzgl. Gegenstand, Elemente, Einsatzgebiet und Beschreibungsmittel) Dokumentation aller im Unternehmen eingesetzten IT-Anwendungen und deren Bezug zu (wertschöpfenden) Geschäftsprozessen. Dokumentation der Bebauungsplanung, Übewrwachungs- und Änderungsprozesse.

Question 102

Bete die Tabelle 2 von Seite 74 f. runter. Du weißt schon, was ich meine. Sorry (5.1)

Answer 102

s. Seite 74 f. Skript

Question 103

Was versteht man unter Implementierung in der Phase Erstellung des Softwarelebenszyklus? (5.2)

Answer 103

Die eigentliche Erstellung des Softwaresystems, d. h. das Erzeugen (auch: Schreiben) von Programmcode. Auf Basis der dokumentierten fachlichen Anforderungen (RE), der technischen Spezifikation und der Architekturbeschreibung wird eine Menge von Programmcode-Artefakten erstellt, die in ihrer Summe das lauffähige Softwaresystem ergeben.

Question 104

In welchen Formen manifestieren sich Softwaresysteme (2 Nennungen)? (5.2)

Answer 104

1. Quellcode: Die Menge der vom Entwicklungsteam erzeugten beziehungsweise zusammengestellten Artefakte 2. Kompilierte Binärversion (ausführbare Version), die auf einem Rechner gestartet werden kann Während der Implementierung wird der Quellcode erzeugt. Dieser Code wird dann kompiliert, d. h. in eine ausführbare Version umgewandelt.

Question 105

Welche verschiedenen Weisen zur Umsetzung der Architekturbeschreibung in ein Softwaresystem gibt es (3 Nennungen)? Beschreibe diese näher. (5.2)

Answer 105

1. Schreiben von Programmcode Erstellung strukturierten Texts zur gezielten Lösung von spezifischen Problemen (Datenstrukturen, Algorithmen, Regeln zur Bearbeitung von Daten). Dabei ist der Entwickler fest an die Ausdrucksmöglichkeit und die Wörter der eingesetzten Programmiersprache gebunden. 2. Wiederverwendung von bestehendem Programmcode Besonders bei allgemeineren und immer wiederkehrenden Problemen wurden wahrscheinlich bereits Lösungen erstellt, die in Frameworks zur Verfügung gestellt werden. Diese können Teil der Programmiersprache sein oder von Dritten (Dienstleistern oder Open Source) hergestellt sein. Große Systeme sind ohne Frameworks nicht mehr denkbar. D. h. Entwickler schreiben nicht nur Code, sie wissen auch, welches Framework und welche Bibliothek welche Funktionen zur Verfügung stellt und wie diese mit dem selbst geschriebenen Programmcode integriert werden können. 3. Automatische Generierung von Programmcode Dann, wenn der Aufwand zur Erstellung und Wartung eines Code-Generators geringer ist als für die manuelle Erzeugung der Code-Fragmente (z. B. bei wiederkehrenden aber fachlich trivialem Programmcode).

Question 106

Was ist ein Framework im Kontext der Implementierung in der Phase Entwicklung des Softwarelebenszyklus? (5.2)

Answer 106

Sammlung von Programmcode zur Lösung von typischen Problemen. Sie können im Rahmen von Entwicklungsprojekten genutzt werden.

Question 107

Was ist eine Entwicklungsumgebung? Nenne Beispiele. (5.2)

Answer 107

Das Programm, das von den Entwicklern genutzt wird, um Programmcode zu erstellen. Sie soll die bestmögliche Unterstützung geben und dabei Trivialaufgaben so weit wie möglich automatisieren. eclipse IDE (Open Source), Microsoft Visual Studio

Question 108

Nenne die 5 Hauptfunktionen einer Entwicklungsumgebung (5.2)

Answer 108

1. Unterstützung des Schreibens von Programmcode Syntax-Highlighting, Erkennen und Anzeigen von Kompilierfehlern, automatische Vervollständigung, Navigation durch den Programmcode, einfaches Kompilieren und Ausführen des Programms zu Testzwecken 2. Einbindung von Bibliotheken und Framework Einfache Import- und Navigationsfunktionen 3. Generierung von Programmcode für triviale Aufgaben GUI-Editor und spezielle Dialoge zur Generierung von Standard-Codefragmenten 4. Unterstützung der Versionsverwaltung Weil mehrere Entwickler daran arbeiten, besonders wichtig. Bsp.: GitHub, Microsoft Team Foundation Server 5. Kompilieren: Erzeugen einer lauffähigen Version aus dem Programmcode Erzeugen einer lauffähigen Version aus dem Programmcode Build-Systeme: Eine Software zum automatisierten Kompilieren und Testen von in Entwicklung befindlicher Software (Bsp.: Make, Ant oder Maven); ermöglicht den Entwicklern das Testen von ihren Änderungen im Programm und erzeugt eine Version der Software.

Question 109

Was ist ein Build-System? (5.2)

Answer 109

Build-Systeme: Eine Software zum automatisierten Kompilieren und Testen von in Entwicklung befindlicher Software (Bsp.: Make, Ant oder Maven); ermöglicht Entwicklern das Testen von ihren Änderungen im Programm und erzeugt eine Version der Software.

Question 110

Nenne 5 der 10 meist verwendeten Programmiersprachen (Stand: 2019) (5.2)

Answer 110

1. Java (16,2 %) 2. C (16 %) 3. Python (9,8 %) 4. C++ (5,6 %) 5. C# (4,3 %) 6. VisualBasic.NET (4,2 %) 7. JavaScript (1,9 %) 8. PHP (1,72 %) 9. SQL (1,69 %) 10. Swift (1,65 %)

Question 111

Welche Themen sind wichtig bei der Auswahl einer Programmiersprache für ein Softwareprojekt? (5.2) (9 mögliche Nennungen)

Answer 111

1. Ausführungsumgebung der späteren Anwendung 2. Welche Sprachen beherrschen die Entwickler? 3. Eingliederung der Sprache in meine Anwendungslandschaft 4. Mit welchen Sprachen sind diese Anwendungen umgesetzt und muss ich meine neue Anwendung hierin intergieren? 5. Wissen zur Technologie über den gesamten Lebenszyklus verfügbar? 6. Gibt es ausreichend Frameworks und Bibliotheken? 7. Gibt es bereits Erfahrungen mit der Sprache in Produktivsystemen? 8. Sind gute Tutorials, HowTos und Experten zur Sprache verfügbar? 9. Ist die Unterstützung der Sprache für zukünftige Systemplattformen gesichert?

Question 112

Was ist eine Beschreibungssprache? Nenne Beispiele. (5.2)

Answer 112

In der Informationstechnik sind Beschreibungssprachen, Description Languages (DL), spezielle Programmiersprachen mit denen die Komponenten und deren Beziehungen innerhalb einer Aufgabe beschrieben werden. Mit Beschreibungssprachen kann eine Struktur vorgegeben werden, in der Nachrichten ausgetauscht werden können (jedoch nicht, wie diese interpretiert werden). Bsp.: HTML, XML, CSS

Question 113

Für was wird SQL verwendet? (5.2)

Answer 113

Speichern und Lesen von Datenbanken, speziell für eine bestimmte Datenbank entwickelte SQL-Programmierung

Question 114

Für was wird JavaScript am ehesten verwendet? (5.2)

Answer 114

Web-Anwendungen, Internet, wird direkt im Browser ausgeführt, keine Vor-Kompilierung; auch in Kombination mit Java oder C# (z. B. interaktive Benutzerdialoge)

Question 115

In welcher Beziehung stehen RE, Architektur und Implementierung zueinander? (4 und 5)

Answer 115

Beginnend mit dem RE wird analysiert und anschließend spezifiziert, was vom System verlangt wird. Bei der Implementierung wird die Menge von Bedingungen und Vorgaben an ein konkretes System in ausführbaren Programmcode übersetzt. Zwischen RE/Spezifikation und Implementierung ist die Architektur angesiedelt. Der IT-Architekt muss die Bedürfnisse der Stakeholder analysieren und verstehen, gegeneinander abwägen und durch eine Menge von Entscheidungen und Gestaltungsaktivitäten eine Architekturdefinition entwickeln. Die Architekturdefinition stellt die Verbindung von Lösungsraum und Problemraum. Sie dient dem Entwicklerteam als Vorlage und Rahmenwerk für die Aktivitäten zur Implementierung.

Question 116

In welchem Verhältnis stehen Architekturbeschreibung und System? (5.2)

Answer 116

Das Ergebnis der Gestaltungsaktivitäten eines IT-Architekten ist die Architekturbeschreibung. Die eigentliche Architektur des Systems manifestiert sich jedoch erst während der Implementierung des Systems. Jedes System hat eine Architektur, auch wenn kein Softwarearchitekt eine Architekturbeschreibung erstellt hat. Architektur ist systemimmanent.

Question 117

Was bedeutet "systemimmanent"? (5.2)

Answer 117

Bsp.: Architektur ist systemimmanent. Sobald z. B. ein Haus oder auch ein Softwaresystem, erstellt wird, hat es eine Architektur, unabhängig davon, ob es eine Architekturbeschreibung gab, oder, ob sich jemals jemand über die Architektur des Systems Gedanken gemacht hat. Sie entsteht einfach mit.

Question 118

Warum wird die Qualitätssicherung im Software Engineering begleitend durchgeführt? (6.1)

Answer 118

Es wäre zu risikobehaftet damit bis zum Ende der Implementierung zu warten. Schon in der Phase Entwicklung werden die fertig gestellten Softwarefragmente getestet, aber auch die Fragmente der RE und Spezifikation (Spezifikationsdokumente) und die Architekturbeschreibung müssen einer QS unterzogen, da sich Fehler hierin direkt in die Implementierung fortpflanzen.

Question 119

Definiere Softwarequalität nach DIN-ISO-Norm 9126 (2 und 6.1)

Answer 119

„Gesamtheit der Merkmale und Merkmalswerte eines Softwareprodukts, die sich auf dessen Eignung beziehen, festgelegte Erfordernisse zu erfüllen.“

Question 120

Was ist wichtiger: Kundenbedürfnisse erfüllen oder Spezifikation einhalten? (6.1)

Answer 120

Im Idealfall enthält die Spezifikation die Kundenbedürfnisse. Ist dies nicht der Fall sollte nachgebessert werden, denn die Erfüllung der Kundenbedürfnisse ist das wichtigste Element überhaupt.

Question 121

Was ist Qualitätsmanagement (QM)? (6.1)

Answer 121

Alle organisierten Maßnahmen zur Verbesserung der Qualität von Produkten, Prozessen oder Leistungen jeglicher Art.

Question 122

Beschreibe die typischen Aktivitäten im Qualitätsmanagement (4 Nennungen) (6.1).

Answer 122

1. Qualitätsplanung: Dokumentation der Qualitätsanforderungen mit Auftraggeber 2. Qualitätslenkung: Überwachung, Steuerung & Kontrolle von Aktivitäten zur Qualitätsprüfung 3. Qualitätsprüfung: Sicherstellen, dass Produkte, Prozesse und Leistung, die festgelegten Qualitätsanforderungen erfüllen. 4. Qualitätsverbesserung: Auswertung von Produkt- und Prozessdaten zur Verbesserung des Qualitätsniveaus.

Question 123

Grenze konstruktives Qualitätsmanagement von analytischem Qualitätsmanagement ab.

Answer 123

1. Konstruktives Qualitätsmanagement A-priori-Definition aller Qualitätseigenschaften für Produkte und Prozesse, um Fehler während der Softwareentwicklung zu vermeiden; vorbeugend 2. Analytisches Qualitätsmanagement Ex-post-Definition Maßnahmen zur Prüfung und Bewertung des aktuellen Qualitätsniveaus der Prüfobjekte, um Fehler systematisch aufzuspüren und ihre Ausmaße zu bestimmen.

Question 124

Was sind Maßnahmen im konstruktiven Qualitätsmanagement (3 Nennungen)? (6.1)

Answer 124

- Technische Maßnahmen (Einsatz von Modellierungssprachen, Werkzeugen, Entwicklungsumgebungen) - Organisatorische Maßnehmen (Richtlinien, Standards, Templates, Checklisten) - Sozio-psychologische Maßnahmen (Trainings, Arbeitsklima, gemeinsame Hobbys)

Question 125

Welche Arten von Tests gibt es im analytischen Qualitätsmanagement? (2 Nennungen) (6.1)

Answer 125

Statisch: Review, Audit – Analyse, Begutachtung, Untersuchung – gewonnenen Informationen werden zusammengetragen und in Metriken oder Kennzahlen verdichtet und schließlich ausgewertet. Dynamisch: Die Software wird mit konkreten Eingabewerten ausgeführt und das Ergebnis der Ausführung bewertet.

Question 126

Was könnte neben Programmcode außerdem Gegenstand von Testfällen im QM sein und warum? (6.1) (4 Nennungen)

Answer 126

1. Fachliche Anforderungen 2. Tech. Spezifikation 3. Architekturbeschreibung 4. Testfälle Dynamische Tests allerdings nur bei ausführbaren Artefakten. Fehler in den frühen Phasen der Softwareentwicklung. RE, Spez, Architektur schreiben sich in den Programmcode fort und multiplizieren sich, da auf der Basis falsche Anforderungen weitergearbeitet wird.

Question 127

Nenne die vier Teststufen im Qualitätsmanagement. (4 Nennungen) (6.1)

Answer 127

1. Komponententest 2. Integrationstest 3. Systemtest 4. Abnahmetest (auch: Akzeptanztest) Die Teststufen sind Gruppierungen einzelner Tests.

Question 128

Beschreibe die Teststufe des Komponententests (6.1)

Answer 128

Zur Implementierung eines Systems wird dieses in Komponenten (logische Bestandteile) unterteilt, die einzeln erstellt und auch getestet werden können. Bsp.: Warenkorb: Berechnung der Gesamtsumme aller Artikel

Question 129

Beschreibe die Teststufe des Integrationstests. Was sind in diesem Zusammenhang Treiber und Dummies (6.1)

Answer 129

Testet das Zusammenspiel von Gruppen von Komponenten; arbeiten diese so zusammen, wie in der Spezifikation beschrieben? Noch fehlende Komponenten können durch Treiber oder Dummys simuliert werden. Treiber (hier): Softwarefragemente, die das Aufrufen anderer Komponenten simulieren. Dummies: Simulieren Komponenten, die durch andere Komponenten aufgerufen werden Bsp.: Zusammenspiel von Schnittstellen (externe Schnittstellen mit System); Integration von PDF-Drucker und dem Warenkorb zur Erzeugung einer Rechnung

Question 130

Beschreibe die Teststufe des Systemtests im Qualitätsmanagement. Welche besondere Herausforderung gibt es hier? (6.1)

Answer 130

Testet System als Ganzes; letzter Test vor der Übergabe; erfüllt das System die Anforderungen? a. Test der Erfüllung der fachlichen Anforderungen b. Test spezifizierter Qualitätseigenschaften c. Stress- und Lasttests (Systemverhalten in anspruchsvollen Situationen; z. B. viele Nutzer, große Datenmengen) Herausforderung: Möglichst originalgetreue Nachbildung der Produktivumgebung des Kunden 1. Hardware und Softwareumgebung, in der das System betrieben wird 2. Softwaresysteme, zu denen das zu testende System technische Schnittstellen hat 3. Realistische Auslastung und realistisches Nutzerverhalten 4. (Möglichst) echte Datensätze (besonders bei Datenschutzrelevanz) Bsp.: Online-Shop: Test eines neuen Shop-Systems nach vollständiger Ablösung des Altsystems

Question 131

Beschreibe die Teststufe des Abnahmetests (auch: Akzeptanztest) im Qualitätsmanagement (6.1)

Answer 131

Test des fertigen Systems beim Kunden; erfüllt es aus Sicht des Kunden die vertraglich vereinbarten Leistungsmerkmale. Auftraggeber führt den Test selbst durch oder wird in den Test einbezogen.

Question 132

Wo liegen die Hauptaugenmerke in der Phase "Betrieb" des Softwarelebenszyklus? (4 Nennungen) (6.2)

Answer 132

1. Verfügbarkeit (für die Nutzer) 2. Absicherung gegen Ausfallszenarien: Oft gibt es technische und prozessuale Abhängigkeiten, die bei Ausfall ganze Unternehmensbereiche lahmlegen können. 3. Absicherung gegen Bedrohungsszenarien 4. Änderung an laufenden Systemen mit äußerster Sorgfalt planen und durchführen

Question 133

Was ist ein Releaseplan? (6.2)

Answer 133

Legt Termine fest, zu denen Änderungswünsche und Anpassung in Betrieb genommen werden. Der Releaseplan gewährleistet, dass die betroffenen Abteilungen, die für die neue Softwareversion erforderlichen Arbeiten einplanen und durchführen können (z. B. QS). 1-4 Termine pro Jahr, gerichtet nach Branchengegebenheiten.

Question 134

Welche drei Phänomene entstehen durch eine strikte Releaseplanung für ein Softwaresystem von 1-4 Releases pro Jahr? (6.2)

Answer 134

1. Geballte Änderungen: Wenige Releases führen zu einer Ballung der Änderungen; dies stellt besondere Anforderungen an die QS, da die Entwickler müssen gleichzeitig an verschiedenen Stellen Änderungen vornehmen 2. Fachabteilungen unzufrieden: Änderungswünsche werden in der Regel erst nach Wochen oder Monaten umgesetzt; die Reaktionszeit scheint zu langsam; evtl. entstehen auch Wettbewerbsnachteile 3. Schwachstellen in der Sicherheit: Eine zu lange Reaktionszeit führt zu Schwachstellen in der Sicherheit des Systems, die zu lange ausgenutzt werden können.

Question 135

Was sind Continuous Integration und Continuous Delivery? (6.2)

Answer 135

Continuous Integration: Zunehmend werden durch Automatisierung und Werkzeugunterstützung tägliche und wöchentliche Releases von Softwaresystemen erstellt und automatisch getestet. Continous Delivery: Automatische Inbetriebnahme von angepassten Versionen in kurzen Zyklen. Voraussetzung: regelmäßige automatische Tests und organisatorische sowie technische Fähigkeit die Aktivitäten der Inbetriebnahme zu automatisieruen.

Question 136

Was hat es mit IT-Service Management im Kontext des Betriebs auf sich? (6.2)

Answer 136

Die Bereitstellung von IT-Services ist eine weitere Aufgabe im Betrieb. Also zum Beispiel: Bereitstellung von Datennetzen, Serversystemen (Hardware), Betriebssystemen, Speichersystemen und Backup-Lösungen. Dienstleistungen, die für Entwicklung und Betrieb benötigt werden. Erstellung eines standardisierten Service-Portfolios: einem Katalog verfügbarer Dienste, die vom IT-Betrieb angeboten werden, das auf typische Anforderungen zugeschnitten ist.

Question 137

Wann spricht man von einer Weiterentwicklung eines Softwaresystems? (6.3)

Answer 137

Wenn das System um fachliche Funktionen erweitert wird oder fachliche Funktionen verändert werden.

Question 138

Nenne 5 Herausforderungen bei der Weiterentwicklung von Softwaresystemen? (6.3)

Answer 138

1. Degeneration der Architektur bestehender Systeme mit jeder Codeänderung; geplante Struktur wird verloren, kleine Änderungen führen zu unvorhersehbaren Auswirkungen Also: Softwarearchitektur kontinuierlich und strukturiert überwachen und Systemdokumentation aktuell halten. 2. Nicht-Unterstützung der neuen Anforderungen durch das alte System (Architektur oder Technologie) 3. Unvollständige und nicht aktuelle Dokumentation: sorgt für enormen Aufwand bei der Identifikation der zu verändernden Codestellen („Reengineering“). 4. Fehlendes Wissen zu Architektur und Programmiersprache 5. Sicherstellen, dass nicht zu verändernde Bestandteile unverändert bleiben, bzw. bereits behobene Bugs behoben bleiben.

Question 139

Worin unterscheiden sich Neuentwicklung und Weiterentwicklung von Softwaresystemen? (6.3)

Answer 139

Ganz grundsätzlich umfassen die Aktivitäten der WE dieselben Aufgaben und Aktivitäten wie die NE eines Softwaresystems. Jedoch beziehen sich die Aktivitäten der WE bereits auf ein produktiv eingesetztes System, an dem Änderungen vorzunehmen sind.

Question 140

Grenzen Sie Integration von Inbetriebnahme ab. (Tut 6)

Answer 140

Integration: Anschluss eines entwickelten Produkts/Objekts an bereits bestehende Systeme; Entwickler geben technische Schnittstellen für den Anschluss vor Inbetriebnahme: Nach Abschluss der Integration müssen alle technischen Schnittstellen bestehender Systeme auf das neue System umgestellt sein. Sicherstellung der Verfügbarkeit und Sicherheit (Anschluss der neuen Anwendung an technische Überwachungssysteme)

Question 141

Was ist ein Rollensystem und welchen Vorteil bietet es bei industriellen Softwareprojekten? (7.1)

Answer 141

Zum Management großer Projekte werden einzelnen Personen Rollen zugeordnet. Dies ermöglicht Spezialisierung und Expertenbildung.

Question 142

Nennen Sie ein Beispiel für einen durch das Rollensystem induzierten Zielkonflikt zwischen Rolleninhaber:innen. (7.1)

Answer 142

Durch das Rollensystem werden automatisch Zielkonflikte induziert (z. B. Tester will möglichst lange und viel testen, Projektleiter will aber Budget und Zeitplan einhalten). Diese konkurrierende und sich widersprechenden Ziele müssen laufend verhandelt und aufgelöst werden.

Question 143

Was zeichnet eine Rolle aus? Können diese mehrfach vergeben werden oder kann eine Person mehrere Rollen ausüben? (7.1)

Answer 143

Eine Rolle ist gekennzeichnet durch Namen, spezifische Aufgaben und spezifische Zielsetzungen. Rollen können mehrfach vergeben werden (z. B. Entwickler). Eine Person kann auch mehrere Rollen auf einmal innehaben.

Question 144

Nenne die Grundannahme des Software Engineering (Projekte), die sich aus der Idee des Rollensystems ableitet. (7.1)

Answer 144

"Projekte funktionieren und können erfolgreich abgeschlossen werden, wenn die richtigen Personen unter Verwendung der geeigneten Methoden (Modellierungs- und Programmier-)Sprachen und Werkzeuge vernünftig miteinander arbeiten."

Question 145

Welche typischen Rollen in Software-Engineering-Projekten werden im Skript genannt (10 Nennungen). Ordne diese der Überbegriffen (übergreifende Rolle, konstruktive Rolle und betreibende Rolle zu) (7.1).

Answer 145

1. Projektmanager (übergreifender Einfluss) 2. Risikomanager (übergreifender Einfluss) 3. Qualitätsmanager (übergreifender Einfluss) 4. Requirements Engineer (konstruktive Rolle; an der Entwicklung beteiligt) 5. Spezifizierer (konstruktive Rolle; an der Entwicklung beteiligt) 6. Architekt (konstruktive Rolle; an der Entwicklung beteiligt) 7. Entwickler (konstruktive Rolle; an der Entwicklung beteiligt) 8. Tester (konstruktive Rolle; an der Entwicklung beteiligt) 9. Integrator (betreibend; Integration und Betrieb nach der Entwicklung) 10. Systemtechniker (betreibend; Integration und Betrieb nach der Entwicklung)

Question 146

Gehe auf die Rollen mit übergreifendem Einfluss aus dem Skript näher ein. An welchen Phasen sind die einzelnen Rollen beteiligt? (3 Nennungen)

Answer 146

Projektmanager (beteiligt an: RE, Spezifikation, Architektur, Implementierung, Qualitätssicherung, Betrieb und Weiterentwicklung) Risikomanager (beteiligt an: RE, Spezifikation, Architektur, Implementierung, Qualitätssicherung, Betrieb und Weiterentwicklung) Qualitätsmanager (beteiligt an: RE, Spezifikation, Architektur, Implementierung, Qualitätssicherung, Betrieb und Weiterentwicklung)

Question 147

Gehe auf die konstruktiven Rollen aus dem Skript näher ein. An welchen Phasen sind die einzelnen Rollen beteiligt? (5 Nennungen)

Answer 147

Requirements Engineer (beteiligt an: RE, Spezifikation, Architektur, Qualitätssicherung und Weiterentwicklung) Spezifizierer (beteiligt an: RE, Spezifikation, Qualitätssicherung und Weiterentwicklung) Architekt (beteiligt an: Architektur, Implementierung, Qualitätssicherung und Weiterentwicklung) Entwickler (beteiligt an: Implementierung, Qualitätssicherung und Weiterentwicklung) Tester (beteiligt an: Qualitätssicherung und Weiterentwicklung)

Question 148

Gehe auf die betreibenden Rollen aus dem Skript näher ein. An welchen Phasen sind die einzelnen Rollen beteiligt? (2 Nennungen)

Answer 148

Integrator (beteiligt an: Architektur, Qualitätssicherung, Betrieb und Weiterentwicklung) Systemtechniker (beteiligt an: Betrieb und Weiterentwicklung)

Question 149

Was sind Ziele (1 Nennung) und Aufgaben (4 Nennungen) des Projektmanagers? (7.2)

Answer 149

(übergreifender Einfluss) Ziel: erfolgreiche Durchführung des Projekts Aufgaben: Planung, Organisation, Kosteneinschätzung Steuerung und Koordination der Aktivitäten & Personen Kontrolle und Verfolgung der Ergebnisse Überwachung des Projektplans und der Produktivität (trifft die wesentlichen Entscheidungen für das Projekt)

Question 150

Was sind Ziele (1 Nennung) und Aufgaben (4 Nennungen) des Risikomanagers? (7.2)

Answer 150

(übergreifender Einfluss) Ziel: Risikominimierung Aufgaben: Identifikation von Risiken aller Art im Projekt Risikoanalyse und Beurteilung von Risiken Entwicklung von Strategien zur Risikoauflösung oder -abschwächung Risikoüberwachung

Question 151

Was sind Ziele (1 Nennung) und Aufgaben/Aktivitäten (5 Nennungen) des Qualitätsmanagers? (7.2)

Answer 151

Ziel: Hohe Qualität des erzeugten Produkts Aufgaben/Aktivitäten: Definition der Systemqualität Plan zur Qualitätssicherung erstellen (überprüfbar) Koordination der Maßnahmen zur QS Beobachten und Sicherstellen der Kundenzufriedenheit Qualitätsrichtlinien und deren Prüfung

Question 152

Was sind Ziele (1 Nennung) und Aufgaben/Aktivitäten (6 Nennungen) des Requirement Engineers? (7.2)

Answer 152

Ziel: Erstellen und Abliefern einer Menge von mit allen relevanten Personen abgestimmten Anforderungen an ein Softwaresystem Aufgaben/Aktivitäten: Bestimmung relevanter Quellen für Anforderungen Anforderungsermittlung Anforderungsdokumentation Erzielung einer Übereinstimmung bzgl. dokumentierter Anforderungen Prüfen und Abstimmen der dokumentierten Anforderungen Verwaltung der Nachverfolgung der Anforderungen

Question 153

Was sind Ziele (1 Nennung) und Aufgaben/Aktivitäten (4 Nennungen) des Spezifizierers? (7.2)

Answer 153

Ziel: Erstellung einer detaillierten, technischen Spezifikation des Systems Aufgaben/Aktivitäten: Beschreibung des Verhaltens, der Daten, der Funktion des Systems Modellierung der Anforderungen auf einer detaillierten, technischen Ebene Definition von überprüfbaren Qualitätsanforderung an das System Vorbereitung der QS durch Dokumentation der Anwendungsfälle und der Definition v. Testfällen

Question 154

Was sind Ziele (1 Nennung) und Aufgaben/Aktivitäten (6 Nennungen) des Architekten? (7.2)

Answer 154

Ziel: Erfolgreiche technische Umsetzung der fachlichen Anforderungen in ein Softwaresystem Aufgaben/Aktivitäten: Erfassen und Verstehen der fachlichen, technischen und organisatorischen Anforderungen Gestaltung und Beschreibung der Architektur des Systems Sicherstellung der Einhaltung von Qualitätsanforderungen Sicherstellung der Einhaltung von technischen Randbedingungen Überwachung der Architektur während der Implementierung Vorbereitung der Systemintegration durch Dokumentation der Systemarchitektur und Definition von Testfällen für den Integrationstest.

Question 155

Was sind Ziele (1 Nennung) und Aufgaben/Aktivitäten (5 Nennungen) des Entwicklers? (7.2)

Answer 155

Ziel: Erstellung von Programmcode (auf Basis der Spezifikation und Architektur), der sich zu einem ausführbaren System kompilieren lässt. Aufgaben/Aktivitäten: Programmierung einzelner Module des Systems Dokumentation des Programmcodes Definition der modulspezifischen Algorithmen Durchführung von Tests auf Modulebene Integration einzelner Module zu einem Gesamtsystem

Question 156

Was sind Ziele (1 Nennung) und Aufgaben/Aktivitäten (4 Nennungen) des Testers? (7.2)

Answer 156

Ziel: Auffinden von Fehlern in Systemteilen (im Verlauf eines Softwareprojekts) und von Fehlern im System als Ganzes Aufgaben/Aktivitäten: Auswahl der Testverfahren Detaillierung von Testplan, Testfällen, Testdaten, Testverfahrensspezifikation Durchführung von Tests auf verschiedenen Teststufen Dokumentation der Testbedingungen und -ergebnisse

Question 157

Was sind Ziele (1 Nennung) und Aufgaben/Aktivitäten (4 Nennungen) des Testers? (7.2)

Answer 157

Ziel: Auffinden von Fehlern in Systemteilen (im Verlauf eines Softwareprojekts) und von Fehlern im System als Ganzes Aufgaben/Aktivitäten: Auswahl der Testverfahren Detaillierung von Testplan, Testfällen, Testdaten, Testverfahrensspezifikation Durchführung von Tests auf verschiedenen Teststufen Dokumentation der Testbedingungen und -ergebnisse

Question 158

Was sind Ziele (1 Nennung) und Aufgaben/Aktivitäten (5 Nennungen) des Integrators? (7.2)

Answer 158

Ziel: Einpassung des neu erstellten oder geänderten Systems in die bestehende Landschaft aus Software und Hardware Aufgabe: Prüfung der Integrierbarkeit des Systems Ausprobieren ausgewählter Aspekte der Integration Prognose des Laufzeitverhaltens und des Ressourcenbedarfs Integration des fertigen Systems in die Betriebsinfrastruktur Herstellung der Verbindung von technischen Schnittstellen

Question 159

Was sind Ziele (1 Nennung) und Aufgaben/Aktivitäten (5 Nennungen) des Integrators? (7.2)

Answer 159

Ziel: Einpassung des neu erstellten oder geänderten Systems in die bestehende Landschaft aus Software und Hardware Aufgabe: Prüfung der Integrierbarkeit des Systems Ausprobieren ausgewählter Aspekte der Integration Prognose des Laufzeitverhaltens und des Ressourcenbedarfs Integration des fertigen Systems in die Betriebsinfrastruktur Herstellung der Verbindung von technischen Schnittstellen

Question 160

Was sind Ziele (1 Nennung) und Aufgaben/Aktivitäten (5 Nennungen) des Systemtechnikers? (7.2)

Answer 160

Ziel: Bereitstellen und Gewährleisten von technischen Ressourcen zum Betrieb eines Softwaresystems. Aufgabe: Evaluation, Installation und Wartung der Infrastruktur Bereitstellung der benötigten Ressourcen Überwachung der zur Verfügung stehenden und genutzten Ressourcen wie Festplattenspeicher, Hauptspeicher, CPU-Zeit und Netzauslastung Einrichtung, Betrieb und Wartung von Systemen zur Sicherstellung der Verfügbarkeit der Infrastruktur.

Question 161

Was sind charakteristische Merkmale einer Rolle? (Tut 7)

Answer 161

- Name - spezifische Aufgaben - spezifische Zielsetzung - personenunabhängig - eine Rolle kann von mehreren Personen wahrgenommen werden - eine Person kann mehrere Rollen innehaben - Personen werden den Rollen zugeordnet.

Question 162

Erklären Sie den Zusammenhang von Prozessparadigma, Softwareprozessmodell-Rahmenwerk, individuellem Softwareprozessmodell und Softwareprozess. (8.1)

Answer 162

Prozesspardigma legt die grobe Struktur fest für das Softwareprozessmodell-Rahmenwerk, welches Blaupausen und detaillierte Vorgaben für das individuelle Softwareprozessmodell liefert, welches organisationsspezifische Vorgaben für den Softwareprozess.

Question 163

Was ist ein Prozessparadigma? Nenne Beispiele (3 Nennungen im Skript) (8.1)

Answer 163

- Sehr allgemeines Vorgehensmodell mit grober Struktur (in unserem Fall für Softwareprozesse) - Grundprinzip ohne Rollen, Zuständigkeiten, Abläufe. - Bsp.: Wasserfallmodell, V-Modell, evolutionäre Entwicklung

Question 164

Was ist ein individuelles Softwareprozessmodell? Was sollte es beinhalten? (8.1)

Answer 164

- Für einen Organisation individuell beschriebener Entwicklungsprozess - Beinhaltet: • Durchzuführende Aktivitäten, • Reihenfolge der Aktivitäten, • Rollen und Organisationseinheiten, die für die Durchführung der Aktivitäten verantwortlich sind • Werkzeuge und Methoden zur Unterstützung der Aktivitäten • Typen der Objekte, die durch die Ausführung der Aktivitäten erzeugt und verarbeitet werden.

Question 165

Was ist ein Softwareprozess? (8.1)

Answer 165

- Ein einzelner Softwareentwicklungsprozess als Ausprägung des individuellen Softwareprozessmodells - Ein individuelles Softwareprozessmodell führt zu mehreren Softwareprozessen - Festlegungen: • Welche Aktivität wird wann von wem durchgeführt? • Welche Objekte werden bei der Durchführung einer Aktivität verarbeitet oder erzeugt?

Question 166

Beschreibe das Wasserfallmodell (8.2)

Answer 166

Winston Royce (1970) - Ein Prozessparadigma, das die schrittweise, jeweils vollständige Bearbeitung einzelner Phasen in einer festgelegten Reihenfolge vorschreibt. - Das Softwareprojekt fällt nach der Reihe von „oben nach unten“ durch den Prozess. - Legt großen Wert auf vollständige und aktuelle Dokumentation. Erst wenn die Dokumentation abgeschlossen ist, darf der Prozess in die nächste Phase übergehen. - Zwischen benachbarten Phasen gibt es die Möglichkeit der Rückkopplung, falls es Probleme mit dem produzierten Ergebnis gibt. Phasen: Systemanforderungen --> Softwareanforderungen --> Analyse --> Programmentwurf --> Implementierung --> Test --> Betrieb

Question 167

Welche Vorteile (für das Management) und welche Nachteile hat das Wasserfallmodell. Ist es heutzutage noch zu empfehlen? (8.2)

Answer 167

- Vorteile (aus Managementsicht): • Gliederung in klare Phasen mit definierten Ergebnissen; • klare organisatorische Zuständigkeiten und Überwachung des Fortschritts so besser möglich. - Nachteile: • Starre Reihenfolge steht komplett konträr zur Erkenntnisgetriebenheit von Softwareprojekten. Anforderungen z. B. lassen sich nicht vollständig zu Beginn beschreiben. • Im Wasserfallmodell ist es außerdem nicht möglich, einzelne Komponenten einer Phase bereits in die nächste zu schieben, bevor nicht alles abgeschlossen ist. • Nach der Fertigstellung der einzelnen Phasen folgt jeweils eine umfangreiche QS, auf dessen Ende gewartet werden muss. Empfehlung: - Heutzutage nur noch als grobe Orientierungshilfe einsetzen (in industriellen Softwareprojekten) - Insbesondere klar abgetrennte Phasen und Konzentration auf eine zu jeder Zeit vollständige Dokumentation, führen zu viel Aufwand, der in Erkenntnisse gesteckt wird, die (aufgrund der Erkenntnisgetriebenheit) in der nächsten Phase häufig überaltern.

Question 168

Beschreibe das V-Modell. Welche Phasen stehen sich gegenüber und warum? (8.2)

Answer 168

Grundgedanke: 1:1-Zuordnung von konstruktiven Phasen (linke Hälfte im V) und zu prüfenden Phasen (rechte Hälfte im V). Ein am Wasserfallmodell angelehntes Prozessparadigma, das jeder Phase der Konstruktion eine konkrete Teststufe zuordnet. Merkmale: - Phasen werden nacheinander bis zur fertigen Konstruktion des Softwaresystems durchgearbeitet und müssen vor der Weiterarbeit abgeschlossen sein (s. Wassefallmodell). - Anschließend bewegt sich das Modell über verschiedene Teststufen hinweg. Jede Teststufe ist einer Stufe der konstruktiven Phase zugeordnet. So entsteht das „V“ Phasen: Systemanforderungsanalyse <--> Abnahme und Nutzung Systemarchitektur <--> Systemintegration Systementwurf <--> Integrationstests Softwarearchitektur <--> Unit-Tests Softwareentwurf

Question 169

Was hat es mit der evolutionären Entwicklung auf sich? Welche Phasen durchläuft der Zyklus (4 Nennungen)? (8.2)

Answer 169

Definition: Ein Prozessparadigma, dessen Grundidee die Erstellung des Softwaresystems in mehreren sich wiederholenden Zyklen ist. Merkmale: - Mit jeder Version wächst der Funktionsumfang - Erkenntnisse, die bei der Umsetzung und Bewertung der aktuellen Version gewonnen werden, können im folgenden System berücksichtigt werden. - Fokus auf lauffähiger Software und nicht so sehr auf vollständige Dokumente und Spezifikation. Zyklus: 1. Festlegen der zu umsetzenden Funktionen 2. Umsetzung 3. Integration der neue Funktion in das bestehende System

Question 170

Beschreiben Sie Vor- und Nachteile des Softwareprozessmodells "Evolutionäre Entwicklung". (8.2)

Answer 170

Vorteile: - Berücksichtigung der Erkenntnisgetriebenheit: Der Softwareprozess dreht sich „im Kreis“ um ein fertiges Stück Software. Nicht am Stück, sondern kleinteiliger und miteinander verzahnt durchgeführt. Erkenntnisse können so eingebracht, Fehler schnell erkannt und behoben werden. - Schnelle Verfügbarkeit eines lauffähigen Systems: Zwar nicht mit allen Funktionen, aber zumindest teilweise einsetzbar. Nachteile: - Management: Keine Spezifikation zu Beginn, deshalb wirkt sie vielleicht unstrukturiert und hat kein klar definiertes Ergebnis

Question 171

Warum braucht es Softwareprozessmodelle (und deren Rahmenwerke) sowie Prozessparadigmen? (Tut 8)

Answer 171

Softwareprojekte können nicht adhoc chaotisch organisiert werden; aufgrund von organisatorischer Komplexität, bedingt durch die Beteiligung verschiedener Rollen und vielfältiger Aktivitäten.

Question 172

Was ist das das V-Modell XT? Wo kommt es besonders zum Einsatz? Nenne die Hauptelemente (4 Nennungen) (9.1)

Answer 172

Ein in Deutschland entwickeltes Rahmenwerk für Softwareprozessmodelle, das teilweise verbindlich für öffentliche IT-Projekte vorgeschrieben ist. Die Hauptelemente sind: Projekttypen, Entscheidungspunkte und Projektdurchführungsstrategien, Vorgehensbausteine und Referenzen

Question 173

Erläutere die Hauptelemente des V-Modell XT näher (4 Elemente).

Answer 173

Projekttypen - gewährleistet Einsatzmöglichkeit in möglichst vielen Projekten 1. Systementwicklungsprojekt eines Auftraggebers 2. Systementwicklungsprojekt eines Auftragnehmers 3. Systementwicklungsprojekt eines Auftraggebers mit Auftragnehmer in der gleichen Organisation 4. Einführung und Pflege eines organisationsspezifischen Vorgehensmodells Das Modell beschreibt jeweils für die Projekttypen, welche Vorgehensbausteine zum Einsatz kommen müssen und welche optional ausgewählt werden können. ----------------------------------------------------------------------------------------------------------------- Entscheidungspunkt Hier wird entschieden, ob eine bestimmte Projektfortschrittsstufe erreicht wurde. Zu jedem Punkt ist definiert, welche Ergebnisse bzw. Produkte fertiggestellt werden. Die Reihenfolge wird durch die Projektdurchführungsstrategie festgelegt und leitet sich aus dem Projekttyp ab. ------------------------------------------------------------------------------------------------------------------- Vorgehensbaustein Festlegung konkreter Aufgaben, Aktivitäten, Ergebnisse und daran beteiligte Rollen innerhalb eines Softwareprojektes. Sie stellen auch die Abhängigkeiten zwischen einzelnen Bausteinen dar. Der konkrete Projekttyp entscheidet, ob ein Baustein zur Anwendung kommen muss oder nicht. Er gibt vor WAS von WEM im Projekt zu tun ist. ------------------------------------------------------------------------------------------------------------------- Referenzen Basis für die organisations- und projektspezifische Anpassung; eine Art Naschlagewerk: - Tailoring (Zuschneiden) eigener Softwareprozessmodelle - Rollen: 30 verschiedene Rollen mit Beschreibung, Zuständigkeiten und Kategorie - Produkte im Softwareprozess: detaillierte Beschreibung zur Erstellung, Verwendung und zu Abhängigkeiten von 110 Produkt- bzw. Ergebnistypen - Aktivitäten: 102 Aktivitäten mit einzelnen Arbeitsschritten, und detaillierte Anleitung zur Erstellung und Bearbeitung der Ergebnisse - Konventionsabbildungen mit (inter)nationalen Konventionen in Beziehung zu Elementen des Modells

Question 174

Definiere den RUP. Welche Phasen hat er? (9.2)

Answer 174

Definition: Ein industriell geprägtes Rahmenwerk für Softwareprozessmodelle, das von IBM entwickelt wurde. Es teilt den Softwareprozess in vier Phasen: Inception (Konzeption), Elaboration (Entwurf), Construction (Konstruktion), Transition (Übergabe).

Question 175

Beschreiben Sie die Aktivitäten der vier Phasen des RUP näher. (9.2)

Answer 175

- Inception: RE, Erarbeitung der Projektvision, Risikoanalyse, Projektplan und Budget - Elaboration: Anforderungen verfeinern und detaillieren, Konzept für die System-Architektur entwickeln, Bau erster Prototypen, Ergebnis der Phase ist die Architekturbeschreibung - Construction: Programmcode des Softwaresystems erstellen, Softwaretests durchführen und Fehler beheben - Transition: Aktivitäten, die nach Abschluss der Entwicklungsarbeiten bis hin zur abgeschlossenen Inbetriebnahme durchgeführt werden: Nutzerschulung, Systemtest, Integration in Ausführungsumgebung, Dokumentation.

Question 176

Was hat es mit den "Disciplines im RUP auf sich? Wie werden die Kernaktivitäten abgearbeitet? (9.2)

Answer 176

Disciplines: Die Software Engineering Kernaktivitäten im RUP Zu jeder Disziplin werden spezifische Rollen, Artefakte (Ergebnisse, Produkte), Aktivitäten (Arbeitsschritte, Aufgaben) und Workflows (Reihenfolge v. Aktivitäten in Verbindung mit Artefakten und Rollen) benannt. Kernaktivitäten finden (anders als im Wasserfallmodell) teilweise parallel oder eng verzahnt statt. Allerdings werden die einzelnen Aktivitäten in den einzelnen Phasen mit unterschiedlicher Intensität ausgeführt; unterstützt die evolutionäre Entwicklung.

Question 177

Definiere Scrum (9.3)

Answer 177

Ein stark evolutionäres Softwareprozessmodell-Rahmenwerk mit konsequenter Organisation in kurzen Zyklen in einem sich selbst organisierenden Team. Es ist ein Rahmenwerk für Prozessmodelle über den Softwareprozess hinaus und kann für ganz verschiedene Aufgaben eingesetzt werden.

Question 178

Was sind die drei spezifische Rollen im Scrum? (9.3)

Answer 178

1. Product Owner 2. Scrum Master 3. Team

Question 179

Beschreibe das Aufgabenpaket des Product Owners im Scrum. (9.3)

Answer 179

Product Owner: a. Die Rolle, die den Kunden repräsentiert und für den Erfolg des Produktes und das RE verantwortlich ist. b. Brücke zwischen Projekt und Außenwelt; ist die einzige Schnittstelle zwischen Stakeholdern und Entwicklern des Systems c. Erstellt Releaseplan d. Priorisiert Anforderungen e. Nimmt erstelltes Ergebnis ab.

Question 180

Beschreiben Sie Aufgabenpaket und Struktur des Teams im Scrum (9.3)

Answer 180

Team a. Technische Konzeption [der Software]; an organisatorischen Vorgaben und Konventionen gebunden; ansonsten frei in der Wahl der technischen Umsetzung b. Konstruktion [der Software] c. QS [der Software] d. Arbeitet selbstorganisiert und autonom e. Bestimmt in Absprache mit dem Product Owner, wie viele Funktionen wann in einem Zyklus umgesetzt werden. f. Team besteht aus 3-9 Personen; die in der Phase Entwicklung verorteten Rollen (Architekt, Entwickler usw.) sind hier.

Question 181

Beschreiben Sie das Aufgabenpaket des Scrum Master im Scrum (9.3).

Answer 181

Scrum Master: Moderiert und begleitet alle Aktivitäten und sorgt für den reibungslosen Ablauf (s. organisatorischer Projektleiter) a. Überwachung der Einhaltung der zeitlichen und organisatorischen Vorgaben in einem Scrum-Zyklus b. Sorgt für eine möglichst ideale Arbeitsumgebung von PO und Team, durch das Ausdemwegräumen von Hindernissen. c. Hat keine Weisungsbefugnis, sondern managt den Scrumprozess, indem er zur Arbeit befähigt und vor äußeren Einflüssen und Störungen beschützt.

Question 182

Welche Elemente zur Verwaltung und Steuerung eines Scrum-Prozesses kennen Sie (3 Nennungen)? Beschreibe diese näher.

Answer 182

1. Product Backlog: Detaillierungsgrad variiert; Zu Beginn wenige grob umrissene Anforderungen, die vom PO – und nur von ihm – verfeinert ergänzt und priorisiert werden. 2. Sprint Backlog: Liste von Anforderungen, die in einem Sprint (ein Zyklus im Scrum) umgesetzt werden sollen; eine Teilmenge des Product Backlog. PO und Team vereinbaren, welche Anforderungen in den Sprint Backlog kommen. Menge ist dabei abhängig von der Velocity (s. 3.); während der Bearbeitungszeit eines Zyklus wird der Sprint Backlog nicht verändert. 3. Velocity: teamspezifische Kennzahl, die den Umfang der von einem Team in einem Zyklus umgesetzten Funktionen kennzeichnet. Sie bildet einen Anhaltspunkt dafür, wie viele und welche Anforderungen ein Team sich für die Dauer eines Zyklus in das Sprint Backlog laden sollte.

Question 183

Skizzieren sie grob den Ablauf von Scrum. (9.3)

Answer 183

1. Aus dem Product Backlog wird für jeden Sprint (Zyklus in Scrum) das Sprint Backlog erstellt. 2. Sprint (ca. 30 Tage): Umsetzung der Anforderungen aus dem Sprint Backlog. Tägliche Besprechung „Daily Scrum“ oder auch „Standup Meeting“ (max. 15 Minuten), indem jeder berichtet, was er gerade bearbeitet 3. Vorstellung der im Sprint erstellten Erweiterung (zurück zu 1.) nach Abschluss des Sprints

Question 184

Beschreiben Sie den Ablauf eines Scrum-Sprints. (4 Nennungen) (9.3)

Answer 184

Aufteilung in vier Phasen 1. Sprint Planning: a. PO stellt die Anforderungen vor, die er vorgesehen hat. Einschätzung des Teams (Umsetzungaufwand für jede Anforderung) b. Befüllung des Sprint Backlog nach Prio des PO und Velocity des Teams c. Team plant die Umsetzung der Anforderung (wer für was) 2. Sprint-Durchführung a. Umsetzung durch das Team b. PO bereitet die Anforderungen für den nächsten Sprint vor. c. Menge der Anforderung wird (im Regelfall) nicht verändert. d. Scrum Master beseitigt Hindernisse bei der Durchführung und achtet auf ordnungsgemäße Durchführung des Dailys. 3. Sprint Review a. Präsentation der Ergebnisse vor Stakeholdern b. Feedback der Stakeholder c. Abnahme des Ergebnisses durch den PO d. Dokumentation von Änderungen und noch nicht umgesetzten Anforderungen im Product Backlog 4. Sprint-Retrospektive a. PO, Team und Scrum Master reflektieren den eigenen Arbeitsprozess – Was lief gut? Was muss verbessert werden?