• Softwareentwicklung (Softwaretechnik) WS19/20

Es gibt eine Hausarbeit zum Fach, die dir ermöglicht, Bonuspunkte zu sammeln. Die Abgabe kann bis zu 10% Bonuspunkte ( prozentual zur maximalen Klausurpunktzahl) erbringen. Diese werden aber nur bei Bestehen der Prüfung drauf addiert.

Sowohl die Übungsaufgaben als auch weitere Informationen zur Hausarbeit sind im Moodle zu finden.

Als Hilfsmittel ist ein einseitig handbeschriebener A4 Zettel erlaubt.

1. Was versteht man unter Software? Warum ist Software so schwer zu entwickeln?

• Software → Programme + Daten
  • Kunden: Funktionalität, Zuverlässigkeit, Effizienz, Bedienbarkeit

• Softwareprodukt → Software + Entwicklungsartefakt
  • Entwickler: Wartbarkeit, Portierbarkeit

• Probleme:
  • hohe Komplexität
  • moralischer Verschleiß → Evolution
  • immateriell → Konsistenz der Artefakte
  • fehlerbehaftet

2. Erläutern Sie die Ursachen für die s.g. Softwarekrise?

• rasante Leistungssteigerung preiswerter Hardware
  • Software muss an neue Hardware angepasst werden
  • Leistungssteigerung weckt neue Wünsche und Möglichkeiten
    • moralischer Verschleiß → Evolution nötig
    • neue Anforderungen → Komplexität
    • Innovation → … time-to-market

• Entwicklungsmethoden halten damit nicht Schritt
  • Nachfrage wird nicht qualitativ befriedigt

3. Ziel des Softwaretechnik ist die ingenieurmäßige Softwareentwicklung! Welche Basiskonzepte wurden von den Ingenieuren übernommen?

• saubere Anforderungsspezifikationen
• Systemanalyse (Zerlegung, Strukturierung) und Systemmodellierung
• systematisches, methodisches und möglichst automatisiertes Vorgehen

4. Was versteht man unter dem Software-Lebenszyklus? Wie kann man die Stilllegung einer langlebigen Software möglichst vermeiden?

• Produktvision
  • Softwareentwicklung ist teuer
    • ständige evolutionäre Weiterentwicklung durch Grafik siehe Skript
  • iterative Wartung
    • (Anpassung, Verbesserung, Korrektur)

• Softwareänderung greift in die Softwarearchitektur ein
  • mangelndes Verständnis des Altsystems und die Zerstörung der Architektur kann zur Stilllegung führen (keine Wartbarkeit)

• Stilllegung kann vermieden werden
  • Dokumentation und Re-engineering (Reverse-engineering und Re-structuring)

5. Was ist der Fokus der vier großen Teildisziplinen der Softwaretechnik? 4 Teilsysteme

• Entwicklung:
  • lauffähiges Produkt schaffen
• Qualitätssicherung:
  • Fehler vermeiden, Fehler finden im Vergleich zur Spezifikation
• Wartung:
  • lebensfähiges Produkt erhalten, kontrolliert Fehler beseitigen und Software an neue Anforderungen anpassen
• Projektmanagement:
  • Produkterfolg durch Organisation sichern, Produktivität steigern

→ vier eng verzahnte Prozesse

1. Was ist der Unterschied zwischen einem Vorgehensmodell und einem Prozessmodell? Wie wird eine Prozessmodell festgelegt?

• Vorgehensmodell: beschreibt ALLGEMEIN Art und Anordnung von Aktivitäten
• Prozessmodell: Vorgehensmodell für KONKRETES Projekt
  • Definition abhängig vom Projekttyp / Unternehmenspolitik
  • Aktivitäten müssen durch Werkzeuge / Methoden unterstützt werden
  • Abhängig vom Vorgehensparadigma
• Festlegung des Prozessmodells
  • 1. Definition der Aktivitäten (wer, wann, was, wo, wie)
  • 2. Auswahl der Methoden/Werkzeuge (hier eventuell nochmal nachlesen :) )

2. Was ist das Prinzip bei sequenziellen, phasenorientierten Vorgehensmodellen? Nennen Sie Vor- und Nachteile!

• Prinzip: (siehe Arbeitsblätter Bild 2.1)
  • Rückkopplung nur zwischen benachbarten Phasen
  • definierte Aktivitäten und Ereignisse
  • Aktuelle Phase Liefert Input für nachfolgende Phase
• (Charakteristika:)
  • Aktivitäten (Phasen?!)müssen beendet werden bevor die nächste beginnt
  • Reihenfolge der Phasen muss eingehalten werden
• Vorteile:
  • Vereinfacht Projektmanagement, wenn …
    • … Input in eine Phase immer vollständig ist
    • … Anforderungen stabil und vollständig erfasst sind

→ beides in Praxis unrealistisch

• Nachteile:
  • Reaktion auf Anforderungsveränderungen schwer
  • bürokratisch, unflexibel

Erklären Sie den Unterschied zwischen leicht- und schwergewichtigen Vorgehensmodellen? Nennen Sie Beispiele! Was verstehen Sie unter „Tailoring“ von Prozessen? (im aktuellen Script (2010/11) weggefallen)

• Schwergewichtige Prozesse:
  • Aktivitäten, ihre Reihenfolge, entstandene Produkte und Dokumente streng vorgegeben
  • bürokratisch, unflexibel
  • Beispiel: Wasserfallmodell
• Leichtgewichtige Prozesse
  • Aktivitäten, ihre Reihenfolge, und Produkte sind an das Projekt anpassbar
  • unbürokratisch, agil
  • Beispiel: V-Model → durch Tailoring (= Anpassung an Projekt!!)

3. Wodurch erweitert das V-Modell das Wasserfallmodell? Was ist das besondere am V-Modell XT?

• Erweiterung durch
  • Projektmanagement (PM)
  • Qualitätssicherung (QS)
  • Konfigurationsmanagement (KM)
• Besonderheit des V-Modells XT: Tailoring nach Projekttyp
  • Projekttypen:
    • Projekt eines Auftraggebers
    • Projekt eines Auftragsnehmers
    • Vorgehensmodel Einführungen (Stand so im Skript →kA)
      • Anmerkung: Vielleicht meinte sie: „Vorgehensmodell einführen“ (also eigenes Vorgehensmodell erstellen)

4. Erläutern Sie die prinzipiellen Phasen und Produkte eines Softwareentwicklungsprozesses!

• Planung (Grobe Anforderungsanalyse)
  • Ziel: Projektdurchführung ja oder nein
  • Ergebnis: Lastenhaft
  • Problem: korrekte Aufwandschätzung

• Anforderungsanalyse
  • Ziel: Vertrag zur Projektdurchführung
  • Ergebnis: Pflichtenheft
  • Problem: korrekte, vollständige Anforderungen

• Entwurf
  • Ziel: Festlegung der Systemspezifikationen
  • Ergebnis: Systemmodell
  • Problem: geeignete Architektur entwickeln

• Implementierung und Test
  • Ziel: Codierung
  • Ergebnis: lauffähiges Modul
  • Problem: „lesbarer“ strukturierter Code

• Integration und Systemtest
  • Ziel: Freigabe des Produktes
  • Ergebnis: übergabefähiges Produkt
  • Problem: geeignete Integrationsstrategie und Testfälle

• Betrieb und Wartung
  • Ziel: Evolution
  • Ergebnis: einsatz- und lebensfähiges System
  • Problem: Erhalt einer wartbaren Architektur

5. Welche grundlegenden Probleme treten in den Phasen der Softwareentwicklung auf und wie kann man ihnen prinzipiell begegnen?

• 1. Problem: korrekte Aufwandsschätzung (Planung)
  • Lösung: LOC, Function Points Methode oder COCOMO-Methode
• 2. Problem: korrekte vollständige Anforderungen (Anforderungsanalyse)
  • Lösung: Feedback vom AG, Textschablonen zur Anforderungserfassung
• 3. Problem: geeignete Architektur entwickeln (Entwurf)
  • Lösung: Ingeneursmäßiges vorgehen
    • Top Down Zerlegung
    • Zerlegung in Teilsysteme
    • Modellierung
• 4. Problem: „lesbarer“ strukturierter Code (Implementierung und Test)
  • Lösung:
    • Glossar
    • Absprache für gemeinsame Richtlinien ( Variablennamen etc)
    • Egoless Programmieren ( einfache Lösung ist verständlicher als komplexe )
• 5. Problem: geeignete Integrationsstrategien und Testfälle (Integration und Systemtest)
  • Lösung:
    • systematische, redundanzarme, representative Testfälle
    • häufen sich an Grenzstellen (siehe eins der letzten Kap.: Frage zu Testfällen)
• 6. Problem: Erhalt einer wartbaren Architektur (Betrieb und Wartung)
  • Lösung: Re-Engineering
  • Konfigurationsmgmt

6. Was ist die Grundidee beim Prototyping? Welche Vorteile bringt das Protoytyping?

Grundidee Prototyping:

• Modell mit geringem Aufwand veränderbar / erweiterbar
• Modell weist nicht alle Eigenschaften des Zielsystems auf, aber …
• … Anwender kann vor Implementierung wesentliche Eigenschaften ausprobieren

7. Welche Idee wird mit der evolutionären Softwareentwicklung verfolgt? Welche Qualitätsmerkmale sind bei evolutionären Systemen besonders zu beachten? Was ist der Unterschied zwischen Iteration und Inkrement?

Idee:

• Produkt entsteht in mehreren Entwicklungszyklen durch Implementierung weiterer Anforderungen
• Unterschied zwischen Prototyp und Zielsystem wird langsam beseitigt
• Endarchitektur ist am Anfang unbekannt
  • ständiger abgleich mit Anforderungen notwendig
  • ständiges Re-Structuring

Unterschied Iterativ / Inkrementell:

• Iterativ: es werden jedes mal die selben Schritte des Prozesses durchlaufen (Stichwort „Schleife“)
• Inkrementell: Prozess wird ständig erweitert

Qualitätsmerkmale: (der nächste bitte!) Versuch einer Antwort:

• Archivierung alter Versionen notwendig
• Re-Engeneering ständig nötig
• Wartbarbeit (einfache Algorithmen und Beziehungen herstellen, nicht zu verschachtelt)!
• Skalierbarkeit, Flexibilität, Portierbarkeit(!)
  • die Software sollte später vllt auch auf anderer Hardware, Betriebssystemem laufen
    • =⇒ nicht ZU spezielle lösungen
• Korrektheit!

8. Neben dem V-Modell als Standard für Bundesbehörden hat sich der RUP-Prozess als Industriestandard etabliert. Erläutern Sie die Besonderheiten des RUP-Prozesses?

• ist inkrementell/ iterativ
• Anforderungen werden aus den Geschäftsprozessen abgeleitet (anwendungszentriert)
• Architekturentwurf beginnt frühzeitig mit den Anforderungen (architekturzentriert)

9. Wodurch zeichnet sich das agile XP-Vorgehen aus?

eXtreme Programming ist eigentlich kein Vorgehensmodell sondern eine Sammlung von Arbeitsprinzipien:

• Erzeugung kleiner Release-Versionen in kurzer Zeit
• Kontinuierliche Restrukturierung
• „pair programming“ → gemeinsame Ideen, Wissenssicherung
• AG-Beteiligung (on-side), gehört zum Team
• erträgliche Wochenarbeitszeiten von maximal 40 Stunden zum erhalt der Quallität
• kleine Teams mit gemeinsamer Verantwortung
• Einhalten gemeinsamer Richtlinien und Techniken

XP-Postulate:

• Einfachheit der Lösung
• Kontinuierliches Feedback zwischen Entwickler und Auftraggeber
• Courage zur Eigeninitiative
• Direkte Kommunikation aller Beteiligten

10. Welche zwei Besonderheiten sind beim Objektorientierten Vorgehen zu beachten?

1. Spezifikation, Entwurf, Implementierung wachsen zusammen

• bereits bei der Analyse wird mit Klassen gearbeitet
• Klassenstruktur wird im Entwurf verfeinert und mit objektorientierter Programmierung implementiert

2. Starker Fokus auf Wiederverwendung

• Klassen werden für und/oder mit Wiederverwendung entwickelt

—-

1. Erläutern sind Ziel-, Aufgaben und Ergebnis der groben und feinen Anforderungserfassung! Wie ist die Verantwortung verteilt? (Anmerkung: Ist vllt'n weng zu ausführlich geworden, aber ihr könnt euch ja rausschreiben was ihr braucht und Aufgabe 2 ist auch gleich mit dabei ;) ) Grobe Anforderungsanalyse: Ziel: Entscheidung Projektdurchführung ja/nein

• auf Basis: Sinnfälligkeit, Machbarkeit, Kosten (Aufwand/Nutzen)

Aufgabe:

1. Voruntersuchung des Zielprodukt's (Grobe Produktanalyse)

• Beschreibung der funktionalen Leistung
• Benennung nicht funktionaler Eigenschaften (Benutzeraspekte/ Qualitätswünsche)
• Anforderungen werden im Lastenheft festgehalten!
  • Basis für Projektausschreibung

2. Machbarkeitsanalyse

• technische Aspekte (SW-technische Realisierbarkeit)
• ökonomische Aspekte (Aufwandsschätzung)

⇒ grober Projektplan und Kosten =⇒ Kooperation Entwickler ↔ Projektmanagement Ergebnis: Lastenheft (beinhaltet:)

• Ziel, Produkteinsatz
• Produkteinsatz → Geschäftsprozess und Zielgruppe
• funktionale Anforderungen
• Produktdaten
• nicht funktionale Anforderungen
• Constraints → spezielle Anforderungen (Ich hoffe ich habs richtig geschrieben ^^)

⇒wird im Pflichtenheft konkretisiert feine Anforderungsanalyse: Ziel:

• Vertrag zwischen Auftraggeber und Auftragnehmer → Projektdurchführung
• Entscheidungsträger:
  • Auftraggeber / Anwender
  • Pojektmanagement, Analysten, Entwickler

⇒ liefern Produktspezifikationen Aufgaben: 1. Konkretisierung der Anforderungen

• funktionale und nicht funktionale Anforderungen
• Modellierung von Anforderungen

⇒ Übergang zur/zum Synthese/Grobentwurf ⇒ Kooperation Analyten, Auftraggeber 2. Systemspezifikation / Produktdefinition

• Feinprojektplan, Kosten-/Risikolanalyse

⇒ Kooperation Analysten/ Entwickler/ Projektmanagement Ergebnis: Pflichtenheft (=Verfeinerung des Lastenhefts):

• oft ergänzt mit grafischer Notation von Anforderungen im Fachmodell und einem Bedienkonzept
• Projektfeinplan → Kosten, Dauer, Aufgaben des Projektmanagements

2. Welche Informationen sind in der Regel in einem Lasten- bzw. Pflichtenheft mindestens enthalten? Siehe Aufgabe 1!!!

3. Die Personalkosten bilden den größten Posten bei der Bestimmung der erwarteten Projektkosten. Wie geht man bei der Aufwandsschätzung prinzipiell vor? Welche Schätzverfahren kennen Sie? Erläutern Sie das Teufelsquadrat nach Sneed!

• man versucht zu schätzen wie viele Monate eine Person für die Entwicklung benötigen würde –> Mannmonate MM
• LOC, Funcion Points, COCOMO
• Teufelsquadrat:
  • Erhöhung von Qualität/Quantität bewirkt Erhöhung von Dauer/Kosten und umgekehrt
  • Fläche bleibt immer gleich

4. Geg. ist eine geschätzte Programmgröße von 16000 LOC. Schätzen Sie den Personalbedarf und die Entwicklungszeit!

Lines of Code Methode:

Faustregel für MM:

• durchschnittliche Programmentwicklung liefert 350 LOC pro Monat (ohne Kommentare)
• durchschnittliche Produktivität pro Mitarbeiter liegt bei 3500 LOC/Jahr

Lösung:

• 16000/3500 = 4 Mitarbeiter/Jahr
• ⇒ MM = 4*12 = 48

5. Passen Sie die Aufwandsschätzung LH Bild 3.1. an, wenn zusätzlich bei einer Bestellung das Kundenpasswort geprüft und Waren bei einem Zulieferer abgerufen werden können!

• Unter Produktfunktionen hinzufügen:
  • /LF60/ Prüfung des Kundenpassworts
  • /LF70/ Waren beim Zulieferer abrufen
• Unter Produktdaten hinzufügen:
  • (optional)/LD40/ Kundenpasswort speichern (könnte auch unter LD10 gespeichert sein)

6. Bei der Feinanalyse werden Anforderungen vertragsrelevant konkretisiert! Welche kritischen Aspekte sind bei der Anforderungserfassung zu beachten? 1. Korrektheit, Vollständigkeit und Widerspruchsfreiheit einer Anforderung:

• Unterstützung durch Textschablonen, Modelle
• Validierung mit den Auftraggebern und Nutzern, Glossar

2. Stabilität von Anforderungen, Anforderungsänderungen

• Traceability im Lebenszyklus

3. Technische Realisierbarkeit von Anforderungen

7. Wie werden Softwareanforderungen prinzipiell ermittelt? 1. Use Case Ablauf analysieren 2. das System analysieren –> funktionale Requirements 3. der Kunde äußert Qualitätswünsche –> nichtfunktionale Anforderungen 4. Die Laufzeitumgebung oder rechtliche Aspekte können Anforderungen ergeben (z.B. Gesundheitskritisch, Datenschutz) –> Constraints 5. Anforderungen in muss, kann und soll klassifizieren und wenn nötig priorisieren. 6. Glossar anlegen und Anforderungen nochmals validieren. 7. Anforderungen in das Pflichtenheft eintragen

8. Wie können Anforderungen halbformal beschrieben werden? Welche Rolle spielt das Glossar? Halbformal:

• durch strukturierten Text (Anforderungs-Template)

Textschablonen:

• Konzept zur Konstruktion von natürlichen sprachlichen Anforderungen auf der Basis formal definierter Bestandteile
• –> erzwingen grad an Vollständigkeit
• es reichen zwei Textschablonen, um eine sehr große Anzahl von Anforderungen eundeutig und vollständig zu formulieren
  • Selbstständige Systemaktivität mit und ohne Bedingung
  • Nutzerinteraktion

Glossar:

• Begriffslexikon, Begriffsmodell
• –> Vermeidet, das Begriffe von den Projektbneteiligten unterschiedlich verstanden und verwendet werden.

Wichtigste bestandteile:

• Begriffe und Synonyme
• Erklärung (wann darf der Begriff verwendet werden und wann nicht)
• –> Unterstützung der Eindeutigkeit

9. Was ist das Analysemodell? Welche Rolle spielt dieses bei bei der Anforderungsanalyse?

10. Im Beispiel Zimmervermietung (siehe Vorlesung) verlangt der Auftraggeber plötzlich, das Kunden sich über ein Passwort anmelden sollen. (Es gibt bereits implementierte Use Cases für „PW vergessen“ und „Neukunde werden“! Modifizieren Sie das Use Case Diagramm und ermitteln Sie die funktionalen SW-Requirements und permanente Daten für den Normalbetrieb für das Pflichtenheft) [http://www.tu-ilmenau.de/fakia/fileadmin/template/startIA/prozessinf/typo3_neu_geschuetzt/swt/SWTAufgabe_10_Kap_3.pdf Musterlösung] BN und PW sind die üblichen

1. Erläutern Sie die Hierarchieidee der SA? Was sind die Aufgaben und Besonderheiten des Kontextdiagramms? Kontextdiagramm:

• Abgrenzung zur Umwelt
• Datenflüsse zwischen System und allen Quellen bzw Senken
• System als Black-Box: nur ein Prozess 0, keine Speicher

Hierarchieidee:

• Basis:
  • → Top-Down Zerlegung der Systemfunktion (Funktionsbaum)
  • → Verfeinerung der Datenflüsse von/zu Speichern

2. Was wird in einem Flussdiagramm im Vergleich zum DFD zusätzlich dargestellt?

• Datenfluss, spezifiziert im Daten Dictionary und
• Kontrollfluss, spezifiziert im Requierments Dictionary
• Zeitspezifikation auf dem Level Kontextdiagramm:
  • → Wiederholung von Ausgaben
  • → Reaktionszeit auf Eingaben
• Balkendiagramme für die Kontrollflüsse → Cspec

3. Welche Rolle spielt das Data- bzw. Requirements Dictionary in den Phasen der Softwareentwicklung und welche Informationen werden wie abgelegt?

• Spezifiziert alle im FD bzw. DFD enthaltenen:
  • permanenten Systemdaten (Speicher)
  • Daten- und Kontrollflüsse (FD) sowie Zeitangaben (FD)
• ist für die Phasen Analyse, Entwurf und Implementierung gültig
• Problem: Konsistenz und Vollständigkeit
  • → Datenintegrität sichern
  • → dafür keine Werkzeugunterstützung
• Daten werden in Backus-Naur-Form abgelegt
  • Äquivalenz: x=y+z
  • Sequenz(ohne Ordnung): 1+2
  • Alternative : [0|1] –> 0 oder 1
  • Wiederholung: {1} –> eine eins oder beliebig viele
    • Wiederholung von A bis B: A{}B zB.: x=1{z}50
  • Option: () zB.: x=z+(y)
    • x=z v x=z+y
  • Kommentar: *Text*

4. In welcher Weise werden Kontrollflüsse im DFD bzw. FD berücksichtigt?

• Datenflussdiagramme beschreiben keinen Kontrollfluss
• der Kontrollfluss der Elemtarfunktion der letzten Ebene wird durch Pseudokode spezifiziert (Minispezifikation)
• im FD werden Kontrollflüsse verfeinert, jedes FD erhält in Balkennotation die Ein- bzw ausgehenden Kontrollsignale, deren Wirkung in der Cspec konkretisiert wird
• die Minispezifikation wird durch Prozessaktivierungsangaben erweitert Pspec

5. Wann und wie finden die Konzepte ERM und Entscheidungstabelle ET in der SA ihre Anwendung?

• ERM: wenn Beziehungen zw Speichern existieren
• ET: wenn komplexe, verschachtelte Bedingungen in der Minispezifikation auftreten

6. Wie erfolgt eine Kontrollflussspezifikation Cspec bei RT/SA?

• Zustandsdiagramm
• und/oder Prozessaktivierungstabelle
• und einer Pspec

7. Was wird durch die Prozessspezifikation Pspec beschrieben und wie können prinzipiell Prozesse gesteuert werden?

• Minispezifikation wird erweitert
  • → zusätzlich Informationen, ob der Prozess
• 1. bei Ereignis startet und sich selbst beendet (issue)
• 2. bei Ereignis startet und bei Zustandsübergang endet
• 3. kontinuerlich über die Laufzeit aktiv ist
  • → 1,2 erscheinen in der Prozessaktivierungstabelle

8. Modellieren Sie ein Code-Schloss als Mealy-Automat. Um das Schloss zu öffnen müssen drei Ziffern in der richtigen Sequenz eingegeben werden.

• verschlossen (Ziffer 1 ok) → warten auf Ziffer 2 (Ziffer 2 ok) → warten auf Ziffer 3 → offen
• erweitern: Timeout/Fehler_melden, Tür_zu (offen → verschlossen)

9. Ist die nachfolgende Tabelle eine Ein- oder Mehrtrefferentscheidungstabelle? Prüfen Sie die Vollständigkeit! Kann man die Tabelle optimieren?

• Eintreffer-Tabelle
• Vollständigkeit erfüllt, bei 3 Bedingungen 8 Regeln
• Optimierung: R1+R3,R2+R4,R7+R8

10. Versuchen Sie die Lösung zur Aufgabe 10 zu Kap. 4, die in den Arbeitsmaterialien vorgegeben ist, nachzuvollziehen! [http://www.tu-ilmenau.de/fakia/fileadmin/template/startIA/prozessinf/typo3_neu_geschuetzt/swt/SWTAufgabe_10_Kap4.pdf Musterlösung] BN und PW sind die üblichen

11. Erläutern Sie die Grundidee der UML im Zusammenhang mit den Begriffen Struktur und Verhalten!

• Idee: Modellierung unterschiedlicher Sichten

• Statische Sicht, Struktur: Klassenmodell
• Klasse:
  • Methode, Attribute
  • Beziehungen:
    • zwischen Ober-Unter-Klassen → Vererbung
    • zwischen gleichrangigen Klassen → Assoziation
• Assoziation:
  • → Aggregation: schwache part-of-Abhängigkeit
  • → Komposition: starke part-of-Abhängigkeit

• Dynamische Sicht: Verhaltensmodelle
• Objekt, Prozess, Zustand, Botschaft
  • Modellierung der Kommunikation
    • → Sequenzdiagramm, (Use Case Diagramm)
  • Modellierung des Ablaufs (Methode, Use Case, Geschäftsprozess)
    • → Aktivitätsdiagramm

• Anwendersicht: Black-Box-Verhalten
• Use Case Diagramm

12. Ordnen Sie die UML-Analysediagramme den Aktivitäten und Teilprodukten der Softwareentwicklung zu!

• Grafische Spezifikation funktionaler Anforderungen
  • → Use Case Diagramme (Kommunikation mit der Systemumgebung)
  • → Aktivitätsdiagramme (Ablauf der Use Case)
• Systemanalyse, Grobentwurf
  • → Klassendiagramme (statisches Fachmodell)
  • → Verhaltensdiagramme (ausgewählte dynamische Aspekte zum Fachmodell)
• Fachmodell ist Bindeglied zur Feinanalyse (Entwurf)

• Zusammenhang zwischen Entwicklungsartefakten:
• Pflichtenheft → Daten → Klassen
• Use Case Modell —> Klassenmodell (Attribute, Methoden)
• Use Case Szenario als Aktivitätsmodell —> Objektknoten → Klassen * Klassenmodell (Attribute,Metoden)—> Zustandsmodell (einer, mehrerer Klassen) * (Objekte, Methodenaufrufe)–> * Interaktionsmodell als Sequenzdiagramm 13. Versuchen Sie die Beispieldiagramme auf den Bildern 4.4.-4.8. zu verstehen und zu erläutern! 14. Lösen Sie die im Arbeitsmaterial enthaltene Aufgabe 14 zuKap. 4! Die Lösungsstruktur ist teilweise vorgegeben. [http://www.tu-ilmenau.de/fakia/fileadmin/template/startIA/prozessinf/typo3_neu_geschuetzt/swt/SWTAufgabe_14_Kap4.pdf Musterlösung] BN und PW sind die üblichen —- ==== Feinentwurf, Design ==== 1. Erläutern Sie die Begriffe SW-Architektur und Komponente? Softwarearchitektur: * die Bausteine (Komponenten, units) * und deren Beziehungen Komponente: * ist ein Baustein für einen abgrenzbaren Systemteil * ist eine Funktion/Prozedur oder ein abstrakter Datentyp oder Klasse 2. Nennen Sie Ziel und Aufgaben des Designs (Feinentwurf)!

Welche Grundsatzentscheidungen müssen getroffen werden? Ziel: Das Fachmodell unter Beachtung auch nichtfunktionaler Anforderungen und Randbedingungen auf eine Softwarearchitektur abbilden. Aufgaben:

• Identifikation und Spezifikation aller Komponenten
• Identifikation und Definition aller Schnittstellen
• Strukturierung und Modellierung der verschiedenen Sichten auf die Architektur

Grundsätzlich muss man entscheiden ob der Entwurf strukturiert oder objektorientiert erfolgen soll.

3. Welche Rolle spielen Strukturdiagramme beim Entwurf?

• grafische Darstellung der Zusammenarbeit funktionaler Abstraktionen
• → Prozedur, funktionale Module
• → funktionale Datenabstraktionen
• ein oder mehrere Prozesse im Datenflussmodell ergeben funktionale Module im Strukturdiagramm

4. Erläutern Sie Gemeinsamkeiten und Unterschiede beim strukturierten und modularen Entwurfsvorgehen! Gemeinsamkeiten:

• Gruppierung von ähnlichen und zusammenhängenden Blöcken mit definierten Schnittstellen.
• Top-Down-Zerlegung

Unterschiede:

• funktionale Module besitzen kein „Gedächnis“, objektorientierte schon
• modulares Entwurfsvorgehen baut auf OOA auf, strukturiertes auf SA

5. Das typische objektorientierte Vorgehen basiert auf der Zerlegung des Systems in Subsysteme und dem darauf folgenden Feinentwurf der Subsysteme. 5.a.Was ist bei der Zerlegung in Subsysteme zu beachten?

• Trennung von Vererbung und Kompositionsbeziehungen ist verboten
• möglichst geringe Abhängigkeit → lose Kopplung
• möglichst hohe (fachliche) Zusammengehörigkeit → Kohäsion
  • ⇒ vereinfacht Wartung und Verständlichkeit

5.b.Welche Wiederverwendungskonzepte können eingesetzt werden

• vorgefertigte, implementierte Klassen
• bewährte Lösungskonzepte

6. Architekturmuster bieten Lösungskonzepte für ähnliche Anwendungen. Nennen Sie Ihnen bekannte Architekturmuster und deren Anwendungsbereich!

• Schichtenarchitektur
• → für hierarchische Dienstleistungssysteme

• Model View Controller (MVC)
• → für interaktive Systeme

• Plug-in Architektur
• → für Systeme mit variabler Funktionalität

• Client-Server-Architektur
• → für entkoppelte Datenhaltung

• Peer-to-Peer-Architektur
• → für verteilte Systeme, Multiagenten

• Repository-Architektur
• → für Systeme mit intensiven Datenaustausch

7. Erklären Sie die Idee der MVC-Architektur! Model View Controller (MVC)

• Model:
  • enthält das Fachwissen (Daten und Funktionen der Anwendungen

• View:
  • Nutzerpräsentation (mehrere views möglich)

• Controller:
  • steuert Nutzereingabe an Nutzer-view bzw. an das model; view wird über Datenänderungen informiert

8. Erläutern Sie den Unterschied der Wiederverwendung von Klassen bzw. Frameworks! Klassenbibliotheken:

• Menge von Klassen mit einem bestimmten Zweck
• Kommerzielle Klassen
  • GUI, DB-Anbindung
• Spezielle Klassen
  • Einsatz in ähnlichen Anwendungen
  • Block Box Prinzip, kein Kontrollfluss vorhanden
• –>Aufwand kann hoch werden

Frameworks:

• Wiederverwendung von Code, Architektur und Kontrollfluss
• Menge von Klassen, die Grundgerüst für Problem bilden
  • Verhalten und Kernfunktionalität (frozen spots)
  • adaptierbare Klassen (hot spots)
  • Spezialisierung durch Unterklassen & Methodenüberschreibung ( White Box Verhalten, sehr gut anpassbar)
    • gute interne Kenntnisse notwendig!!
  • Blak Box anwendung eher unwahrscheinlich, da man so alles übernehmen müsste
  • –> sehr unflexibel

9. Erläutern Sie die Anwendung von abstrakten Klassen, Knotenklassen und Schnittstellenklassen bei Integration von Klassen? Knotenklassen und Schnittstellenklassen sind die Möglichkeiten abstrakte Klassen zu nutzen. Knotenklassen dienen dazu Methoden mit vorgegebener Schnittstelle für die erbenden Klassen festzulegen. Schnittstellenklassen verbinden Methodenimplementierer und Methodennutzer indem sie eine Schnittstellenmethode implementieren über welche die beiden „kommunizieren“ können.

10. Was beschreiben Entwurfsmuster und wo können Sie eingesetzt werden?

• Architekturmuster beschreiben die Struktur und Interaktionen zwischen Teilen eines Softwaresystems
• sind Lösungskonzepte für die Verfeinerung von Systemteilen und ihren Relationen
• beschreiben interagierende Objekte und Klassen für die Lösung eines immer wiederkehrenden Entwurfsproblems in einem bestimmten Kontext

11. Erläutern Sie die Merkmale und die Anwendung von Komponenten! Komponenten sind wiederverwendbar, vorgefertigt, kapseln eine gewisse Funktionalität (Klasse, Klassenverbund oder ganzes Subsystem) und werden als ganze Einheit über Schnittstellen genutzt. Komponenten dienen der Wiederverwendung bei ähnlichen Anwendungen.

1. Nennen Sie Ziel, Aufgaben und Ergebnis der Implementierung!

• Ziel: lauffähiges System
• Aufgaben:
  • Transformation Entwurfsmodell in die Programmiersprache
  • Dokumentation erstellen und Testen
• Ergebnis: Software+Dokumentation+Testfälle

2. Welche Prinzipien sind bei der Implementierung zu befolgen? Was kann dabei Unterstützung leisten?

• Grundsatz: Egoless implementieren
  • Verbalität zur Selbsterklärung → Glossar
  • Integrierte (schritthaltende Dokumentation)
  • Verständlichkeit bewahren → Richtlinien und Konventionen

3. Nennen Sie die Aufgaben der Softwarewartung?

• Fehlerkorrektur
• Verbesserung von Qualitätsmerkmalen
• Weiterentwicklung (neue bzw. veränderte Anforderungen)
• Anpassung (neue Hardware, Betriebssysteme, ..)

4. Warum ist ein Änderungsmanagement notwendig? Welche Aufgaben hat das Änderungsmanagement?

• Bedeutung:
  • vermeidet Architekturzerfall
  • bewahrt die Konsistenz der Produktartefakte
  • erhält die Wartbarkeit
• Aufgaben:
  • Prüfung der Sinnfälligkeit einer Änderung
  • Prüfung der technischen und wirtschaftlichen Machbarkeit (Erfassung aller betroffenen Artefakte)
  • Auftragserteilung, Überwachung, Archivierung

5. Erläutern Sie den Zusammenhang zwischen der Änderung einer Software, dem Re-Engineering bzw. Restructuring und dem Architekturzerfall?

• Re-Engineering: Verstehen der Alt-Architekur → wo und wie kann etwas verändert werden

• Re-Structuring: Veränderung der Architektur, um eine Änderung vorzunehmen und dabei die Wartbarkeit zu erhalten

• Architekturzerfall: die Struktur der Software wurde aufgrund vieler Änderungen „zerstört“ und kann ohne Folgefehler nicht mehr gewartet werden

1. Erläutern Sie die Phasen des Projektmanagements (Ziele und Ergebnisse) und den Bezug zum Softwareentwicklungsprozess!

• Start: Ziel: Projekt Stop/GO verzahnt mit: Planung
• Ergebnis: Grobplan, Lastenheft

• Planung: Ziel: Vertragsabschluss verzahnt mit: Anforderungsanalyse
• Ergebnis: Feinplan, Pflichtenheft

• Durchführung: Ziel: Projektkontrolle parallel: Systemanalyse, Design, Implementierung
• Ergebnis: Planabgleich, Maßnahmen

• Abschluss: Ziel: Produktübergabe parallel: Abnahme, Einführung
• Ergebnis: Wartungsvertrag, Projektanalyse

2. Welche allgemein auftretenden Risiken sind bei einem ITProjekt zu beachten?

• Instablibe Anforderungen:
  • unklare, falsche Anforderungen
  • → Fehlerfortpflanzung
  • neue, veränderte Anforderungen
  • → Architekturzerfall

• Personen (people ware):
  • Anzahl, Funktion
  • Qualifikation
  • Motivation
  • Teamfähigkeit

• weitere Faktoren:
  • Marktsituation, Konkurrenz
  • Technologie
  • Qualität der Planung

3. Welcher Zusammenhang besteht zwischen Risiko, Gewinn und Verlust?

• Risiken gibt es immer → Frage: Wie weit geht die Risikominimierung
• Risikominimierung → Kosten, Zeit steigt
  • z.b. mehr Personal, Schulungen, neue Technologie,…
• Hohe Risiko → hoher Gewinn, aber Projekterfolg? → Verlust
  • zu hohe Planungskosten wiederum können den Kunden verprellen

4. Wie erfolgt prinzipiell die Festlegung der Projektstruktur? Welche Aspekte werden in welcher Reihenfolge geplant?

• Teil 1:
  • Projektgrobstruktur: Arbeitspakete aus den Anforderungen
    • → Projektgrobablauf: Abhängigkeiten der Arbeitspakete
    • → erste Personalplanung
    • —–> Erstes Ganntdiagramm mit Arbeitspaketen

• Teil 2:
  • Aufwandsabschätzung für die Arbeitspakete: Mannmonate → Entwicklungszeit
    • → Projektfeinablauf: Kompromiss Personal (-Kosten), Zeit → Ganntdiagramm, Terminplan (Personen, Dokumente, Meilensteine)
    • → Kostenplanung
    • —–> Vertragsabschluss

5. Erläutern Sie den Regelkreis zur Projektsteuerung! Wieso bezeichnet man die Planung eines Softwareprojektes als iterativ? * Ist-Daten erfassen → Kosten, Termine, Qualität (Berichte, Reviews) * Ist-Soll-Datenvergleich → aktueller Projektplan * Regelmaßnahmen ableiten → Maßnahmenplan * Plankorrektur → angepasster Projektplan

• Planiteration: Grobplan, Feinplan, Planaktualisierung

6. Wenden Sie die COCOMO II-Methode für 190 UFP in JAVA zur Aufwandsschätzung an für eine Anwendung im Versicherungswesen und bewerten Sie Ihr Ergebnis!Randbedingungen: a. sie haben ein erfahrenes Team, aber ihre zwei besten Programmierer sind ausgefallen, dafür sind ihre Analysten Spitze b. sie haben bereits für Versicherungen einige kleine Projekte bearbeitet c. die Anwendung soll in die AG-eigene Architektur integriert werden, die einer Schichtenarchitektur entspricht d. an die Zuverlässigkeit werden sehr hohe Anforderungen gestellt Benötigte Formeln: 4 empirische Konstanten nach Böhm: A=2.94, B=0.91, C=3.67, D=0.28 [Formel] Size=190*53=10070 SLOC=10,07 KSLOC Erfahrung SF1=2 Flexibilität SF2=1 Teamstärke SF3=2 Architekturkompetenz SF4=3 Prozessreife SF5=2 Summe=10 E=0.91+0.01*10=1.01 EM1: RCPX (RELY 6, DATA 6, sonst 3) 1.91 EM2: PERS (ACAP 5, PCAP 3, PCON 2) 0.83 EM3: PREX (AEXP 4, PEXP 4, LTEX 3) 0.87 Produkt=1.38 MM=2.94*10.07^1.01*1.38=41.8 timeTodevelop=TDEV=C*MM^F F=D+0.2(E-B)=0.3 TDEV=3.67*41.8^0.3=11.25 Monate

7. Erläutern Sie den Unterschied zwischen konstruktiven und analytischen Maßnahmen zur Qualitätssicherung! Nennen sie Beispiele!

• Konstruktiv zur Fehlervermeidung:
  • organisatorisch → Projektmanagment, Qualitätssicherung, Konfigurationsmanagement
  • technischen → Prozessmodell, SW-Entwicklungsumgebung
  • psychologisch → Motivation, Qualifikation, Führungsstil, Klima

• Analytisch zur Fehlererkennung:
  • statisch, begutachten → Reviews von Dokumenten
  • dynamisch, testen → Black-box-Test, White-box-Test
• Modul, Integration, System

8. Nennen Sie Voraussetzungen und Testaspekte für die Phasen im Testprozess!

• siehe Skript, Tabelle: Modultest – Integrationstest – Systemtest - Abnahmetest
  • Für jede Phase müssen systematisch Testfälle erstellt werden
    • phasenbezogene Testfälle
    • ökonomisch Testen
  • ⇒ Entwicklung und Test personell trennen!!!

• Voraussetzungen
• Modulspezifikation, Implementierung – Funktionale Anforderungsanalyse für Teilsysteme – System-Anforderungsspezifikation – Abnahmekritierien im Pflichtenheft
• Testaspekte
• Funktion, Struktur – Funktionalität des Teilsystems – Funktion- und Qualität, Systemgrenzen – Erfüllung des Pflichtenheft

9. Welche Anforderungen werden an Testfälle gestellt?

• Testfälle systematisch entwerfen
  • → repräsentativ, fehlersensitiv, (vollständig)
• Testfälle systematisch reduzieren
  • → ökonomisch, redundanzarm
  • → Testzielorientiert

10. Geg. ist die Spezifikation einer Modulfunktion: Für Eingabewerte im Bereich von 100-200 soll die definierte Modulfunktion ausgeführt werden und das Resultat ausgegeben werden, ansonsten Fehlermeldung! Geben Sie Testfälle für den Black-Box-Test an!

• Eingabeäquivalenzklassen: 100⇐x⇐200 (gültig). X>200, X<100 (ungültig)
• Ausgabeäquivalenzklassen: Y=f(X) oder Fehlermeldung
• Testfälle: X=100 → Y=f(X); X=200 → Y=f(X)
  • X=99 → Fehler; X=201 → Fehler