TU Wien:Software Engineering und Projektmanagement VO (Grechenig)/Prüfung 2008-01-30 Ausarbeitung

Dies ist eine Ausarbeitung der Pruefung vom 30.1.2008 nach den Folien die auf der HP der LVA gefunden werden koennen.

Theorieteil (60 Punkte)

Beschreiben der Grundcharakteristik des Unified Process (6 Punkte)

Aus SEPM-SE-Prozesse1.pdf, S. 16ff:

• Prinzipien der Objektorientierung: Datenkapselung, Objektidentitaet, Vererbung, Polymorphismus
• Eigenschaften der Objektorientierung: Zuverlässigkeit, Erweiterbarkeit, Wiederverwendbarkeit, Portabilität, Effizienz

Anwendungsfall-gesteuert

• Verfolgbarkeit

Architektur-zentriert

• Wesentlicher Erfolgsfaktor eines Software-Systems
• Auswirkungen für gesamtes System (Effizienz ...)
• Schnittstellen

Iterative und inkrementell

• kleine Schritte
• geringes Risiko
• kleine Rückschläge

Definierte Inhalte in den 4 Phasen (Beginn, Ausarbeitung, Konstruktion, Umsetzung) und 5 Arbeitsschritte (Anforderungen, Analyse, Entwurf, Implementierung, Test), verwendet UML zur Darstellung der Modelle®.

Anmerkung: Hilfreich ist auch dieser Wikipedia-Link.

Entscheidungskriterien: Agile vs. Plan-driven (6 Punkte)

• Kurze Graphik bei: Vorlesung 03 (SE Anforderungen.pdf), S. 2
• Vorlesung 03 (SE Anforderung.pdf), S. 41ff
• Vorlesung 04 (Prozesse 1), S. 16ff
• Vorlesung 04 (Prozesse 1), S. 62

Wikipedia:

• Agile Softwareentwicklung

Beschreiben des Review-Prozesses nach IEEE. Wieso sind Reviews in der Praxis so wichtig? (3 Punkte)

Review-Prozess nach IEEE

In SEPM-SE-Qualitaetssicherung_Betrieb_Wartung.pdf, S. 31, findet sich ein Graph der folgendes beschreibt: Zuerst wird ein Review vom Leiter erstellt und initialisiert. Die Reviewer erstellen anschliessend Problemberichte (in der individuellen Vorbereitung). In einer Team-Sitzung werden die Problemberichte kontrolliert und bewertet. Sind die beschriebenen Probleme behoben, werden die Berichte geschlossen, ansonsten werden die Probleme vom Author bearbeitet (und hoffentlich geloest).

Warum wichtig?

Dazu wird in den Folien nix explizit gesagt. Wohl aber primaer weil es die Qualitaet der einzelnen Entwicklungsstufen sicherstellt und ein "Aufbauen auf Fehler" verhindert.

Erklaeren von MDD. Was ist der Unterschied zwischen PSM und PIM? (3 Punkte)

MDD steht fuer Model Driven Development. In den Folien wird MDD eigentlich nicht erklaert, es gibt aber Model-driven architecture und Model-driven engineering auf Wikipedia. Anscheinend gehts eben darum zuerst ne Spezifikation zu schreiben, dann plattform-unabhaengige Modelle zu erzeugen aus denen dann schliesslich die plattform-abhaengigen Modelle erzeugt werden. Meistens wird fuer solche Modelle UML verwendet.

“	PIM's (Platform Independent Model) vollkommen unabhängig von einer plattformspezifischen Syntax PSM (Platform Specific Model) und Interface-Definitionen beschreiben, wie das Basismodell auf verschiedenen (Middleware-)Plattformen implementiert wird.	”
—SEPM-SE-Realisierung_Integration.pdf, S. 17

Es gibt dort auch noch ein nutzloses Diagramm davon.

Was sind funktionale, nicht-funktionale und Domain-Anforderungen? Was gibt es fuer Anforderunge (6 Punkte)

Zitat aus SEPM-SE-Anforderungen.pdf, S. 12:

Funktionale Anforderungen

Beschreibung der Funktionen/Services, die das System zur Verfügung stellen soll, wie das System auf bestimmte Eingaben reagieren soll und wie das System in welchen Situationen operieren soll.

Nichtfunktionale Anforderungen

Anforderungen an die Funktionen/Services die nicht deren Verhalten sondern Vorgaben an Qualitätseigenschaften, Entwicklungsprozess, einzuhaltende Standards und Normen, gesetzliche Rahmenbedingungen etc beschreiben.

Domainen Anforderungen

Anforderungen, die von der Domaine des Systems definiert werden und die besonderen Eigenschaften/Einschränkungen dieses Gebietes darstellen. Domainen-Anforderungen sind oft inhärent und nicht explizit im Projekt vertreten.

Die typen nicht-funktionaler Anforderungen werden in der Folgefolie als hierarchischer Graph beschrieben:

• Product requirements
  • Usability requirements
  • Efficiency requirements
    • Performance requirements
    • Space requirements
  • Reliabilty requirements
  • Portability requirements
• Organisational requirements
  • Delivery requirements
  • Implementation requirements
  • Standards requirements
• External requirements
  • Interoperability requirements
  • Ethical requirements
  • Legislative requirements
    • Privacy requirements
    • Safety requirements

Was sind die wesentlichen Qualitaetsanforderungen zur Verifikation von Software-Anforderungen (6 Punkte)

Aus SEPM-SE-Anforderungen.pdf, S. 33:

Vollständig

alle Anforderungen des Kunden müssen explizit beschrieben sein, es darf keine impliziten Annahmen des Kunden über das zu entwickelnde System geben.

Eindeutig definiert / abgegrenzt

präzise Definitionen helfen, Missverständnisse zwischen Entwickler und Auftraggeber zu vermeiden.

Verständlich beschrieben

damit sowohl der Auftraggeber als auch der Entwickler mit vertretbarem Aufwand die gesamte Anforderung lesen und verstehen können.

Atomar

es darf nur eine Anforderung pro Abschnitt oder Satz beschrieben sein.

Identifizierbar

jede Anforderung muss eindeutig identifizierbar sein (z. B. über eine Kennung oder Nummer).

Einheitlich dokumentiert

die Anforderungen und ihre Quellen sollten nicht in unterschiedlichen Dokumenten stehen oder unterschiedliche Strukturen haben.

Notwendig

Sind gesetzliche Vorschriften unabdingbar.

Nachprüfbar

die Anforderungen sollten mit Abnahmekriterien verknüpft werden, damit bei der Abnahme geprüft werden kann, ob die Anforderungen erfüllt wurden (Ableitung von Testfällen aus den Abnahmekriterien).

Rück- und vorwärtsverfolgbar

damit einerseits erkennbar ist, ob jede Anforderung vollständig erfüllt wurde und andererseits für jede implementierte Funktionalität erkennbar ist, aus welcher Anforderung sie resultiert, also nicht Überflüssiges entwickelt wird.

Erklaerung des komponenten-basierten Systementwurfs und seine Bedeutung fuer die Wartung. (6 Punkte)

• eventl. geht es da um "Modularisierung", VO 06 (Design/Architektur), Seite 101. Spaeter ist von einer Komponenten-checkliste die rede
• auch bei Design/Architektur, S. 75 gibts ploetzlich ein paar nutzlose graphen zu "Component based software engineering".

Was ist Refactoring und was sind dessen Vor- und Nachteile? (6 Punkte)

Aus SEPM-SE-Realisierung_Integration.pdf, S. 28ff:

Definition Refaktorisierung

Eine Änderung an der internen Struktur einer Software, um sie leichter verständlich zu machen und einfacher zu verändern, ohne ihr beobachtbares Verhalten zu ändern.

Definition Refaktorisieren

Eine Software umstrukturieren, ohne ihr beobachtbares Verhalten zu ändern, indem man eine Reihe von Refaktorisierungen anwendet.

• Vorteile
  • Erhöhung der Wartbarkeit
  • Erhöhung der direkten und indirekten Wiederverwendbarkeit
  • Erhöhung der Verständlichkeit
  • Indirekte Code Inspektion
  • oft durch IDEs automatisiert
• Nachteile
  • Nutzen oft nicht direkt messbar
  • Veränderung kann unerwünschte Seiteneffekte beinhalten
  • Refaktorisierung nicht immer anwendbar
  • Verschiedene Refaktorisierungsstrategien anwendbar

Was ist der Unterschied zwischen Bottom-Up- und Top-Town-Integration? Wo liegen die jeweiligen Vor- und Nachteile, was wird eher in der Praxis eingesetzt und weshalb? (6 Punkte)

• Es gibt eine nette Graphik dazu in SEPM-SE-Realisierung_Integration.pdf, S. 13, zwei Folien davor werden Integrationsstrategien im Allgemeinen beschrieben. Ueber die jeweiligen Vor- und Nachteile wird in den Folien kein Wort verloren.

Bottom-Up Integration

Es werden zuerst die 'feineren' Systemteile (also Klassen, die nachher von anderen Klassen verwendet werden) entwickelt. Vorteile/Nachteile werden z.B. hier ganz gut zusammengefasst. Weiters: gut wen der Code viel wiederverwendet wird.

Top-Down Integration

Es werden zuerst die Ueberklassen entwickelt. Vorteile/Nachteile werden z.B. hier ganz gut zusammengefasst.

Welche Typen von Software-Wartung gibt es? Wieso ist die Unterscheidung so wichtig? (6 Punkte)

Aus SEPM-SE-Qualitaetssicherung_Betrieb_Wartung.pdf, S. 41:

Präventive Wartung

Jene Maßnahmen, die ergriffen werden, um Fehler und damit weiteren Wartungsaufwand zu vermeiden, bevor sie auftreten.

Korrektive Wartung

Alle jene Änderungstätigkeiten, die aufgrund eines Fehlers im System unmittelbar notwendig sind.

Adaptive Wartung

Jene Anpassungen welche sich aufgrund der sich ändernden Systemlandschaft rund um das Softwareprodukt ergeben.

Perfektionierende Wartung

Jegliche Veränderung am Softwareprodukt, welche die Qualität des Produkts erhöhen soll.

Erklaeren der Unterschiede zwischen Stair- und Fork-Kontrollstil (6 Punkte)

In SEPM-SE-Design_Architektur_01.pdf, S. 34, findet sich dazu ein lustiger Graph. Es geht wohl darum, dass bei dem einen A mit B, B mit C, C mit D usw. kommuniziert, waehrend beim anderen A mit B, A mit C, A mit D usw. kommuniziert.

Aehnlich der Signanz kennt niemand (Google Suche) diese Begriffe.

Kreativteil (40 Punkte)

Aufgabentext: Entwickeln eines Parkhaus-Systems. der Original-Text fehlt leider in der Angabe. Die Prüfung vom 4.4.2008 hat aber die selben Fragen beim Kreativteil.

WBS gemaess der in der Vorlesung vorgestellten Struktur erstellen (15 Punkte)

Die Abkuerzung kommt in den Folien nicht vor, duerfte aber fuer Work breakdown structure stehen und ist damit (siehe deutsche Version des Artikels) der Projektstrukturplan.

Observer-Pattern erklaeren und seine moegliche Anwendung im System. (15 Punkte)

Das Observer-Pattern wird in SEPM-SE-Design_Architektur_01.pdf, S. 91, erklaert.

Beschreiben von 10 nicht funktionalen Anforderungen des Systems inkl. einer Einschaetzung ueber derren Wichtigkeit bei der Umsetzung (gering - mittel - hoch) und wie man zu dieser Einschaetzung kommt. (10 Punkte)

Was nicht funktionale Anforderungen sind wird auch hier erklaert.