c2b_default

Moderne Softwareentwicklung

MSE

MSE

18
0.0 (0)
Roger Kral
Roger Kral

Fichier Détails

Cartes-fiches 18
Langue Deutsch
Catégorie Informatique
Niveau Université
Crée / Actualisé 13.01.2014 / 13.01.2014
Lien de web
https://card2brain.ch/box/moderne_softwareentwicklung4
Intégrer
<iframe src="https://card2brain.ch/box/moderne_softwareentwicklung4/embed" width="780" height="150" scrolling="no" frameborder="0"></iframe>
Étudier

4 Merkmale "Guter" Software

  • Wartbarkeit: Impelementation von Software so, dass auch veränderte

              Kundenbedürfnisse eine Anpassung der Software ermöglichen

  • Zuverlässigkeit: Vermeiden von körperlichen und wirtschaftlichen Schäden durch den

             Einsatz der Software (darunter fallen: Verlässlichkeit, Zugriffsschutz, Betriebssicherheit etc.)

  • Effizienz: Effiziente Nutzung der Systemressourcen z.B. Auswirkungen auf Verarbeitungszeit, Reaktionszeit usw.
  • Benutzerfreundlichkeit: Softwareprodukt ohne unangemessene Anstrengungen des Nutzers

               verwendbar. Hierzu zählt auch eine ausreichende Dokumentation der Bedienoberfläche.

Risikomanagements

  • Risikoanalyse: Abwägung der Risiken hinsichtlich ihrer Wahrscheinlichkeiten und Auswirkungen. Ergebnis ist eine tabellarische Aufstellung der gefundenen Risiken und ihrer Bewertung
  • Risikoplanung:
    • Vermeidungsstrategie: Auftreten des Risikos minimieren
    • Minimierungsstrategie: Auswirkungen des Risikos minimieren
    • Notfallpläne: Einstellen auf das schlimmste Szenario und planen wie mit diesem umzugehen ist
  • Risikoüberwachung:
    • regelmäßige Überwachung (fortlaufender Prozess) der erkannten Risiken
    • haben sich die Wahrscheinlichkeiten der Risiken verändert?
    • haben sich die Auswirkungen der Risiken verändert?
    • sind neue Risiken hinzugekommen?

Welche Phasen sind im Spiralmodell enthalten und wie oft werden diese durchlaufen?

4 Phasen, die zyklisch durchlaufen werden:

 

  • Festlegung der Ziele
    • Ziele und Anforderungen an das (Teil-)Produkt
    • Lösungsvarianten
    • Nebenbedingungen und Einschränkungen
  • Beurteilung von Alternativen, Risikoanalyse
    • Erarbeitung und Beurteilung von Lösungsvarianten
    • Erkennen und beseitigen von Risiken
  • Entwicklung und Testen
    • Entwicklung und Validierung des Produkts der nächsten Stufe
  • Planung des nächsten Zyklus
    • Einverständnis über nächsten Zyklus herstellen

Welche Inhalte haben die 9 Teile des V-Modells-XT in Ihren Worten*** 1-4

  • Grundlagen des V-Modells: Dieser Teil führt in die zentralen Grundkonzepte des V-Modells ein und beschreibt das Zusammenspiel unterschiedlicher V-Modell-Projekte. Ferner werden Anwendungsrichtlinien eingeführt, welche die Umsetzung des V-Modells in konkreten Projekten regeln.
  • Eine Tour durch das V-Modell: Zeigt in Ausschnitten, wie das V-Modell im Rahmen eines konkreten Beispielprojektes angewendet wird.
  • V-Modell-Referenz Tailoring: Beschreibt die Projekttypen, Projektvarianten und Projektmerkmale, mittels derer ein für das jeweilige Projekt spezifisches Anwendungsprofil erstellt wird. Ferner stellt sie die wesentlichen Inhalte der mit dem V-Modell möglichen Projektdurchführungsstrategien und Vorgehensbausteine dar. Darüber hinaus werden die im V-Modell verfügbaren Entscheidungspunkte vorgestellt.
  • V-Modell-Referenz Rollen: Vermittelt einen Überblick über alle im V-Modell vorgesehenen Rollen. Neben einer detaillierten Rollenbeschreibung wird für jede einzelne Rolle festgehalten, für welche Produkte und Aktivitäten die Rolle verantwortlich ist und wo sie mitwirkt.

Welche Inhalte haben die 9 Teile des V-Modells-XT in Ihren Worten*** 5-9

  • V-Modell-Referenz Produkte: Beinhaltet dem hierarchischen Produktmodell entsprechend alle Disziplinen, Produkte und Themen des V-Modells. Dabei werden explizit auch die Zusammenhänge zwischen den einzelnen Produkten durch sogenannte Produktabhängigkeiten beschrieben.
  • V-Modell-Referenz Aktivitäten: Beinhaltet dem hierarchischen Aktivitätenmodell entsprechendalle Aktivitäten und Arbeitsschritte des V-Modells. Dabei wird insbesondere die Abwicklung dereinzelnen Arbeitsschritte im Rahmen einer Aktivität beschrieben
  • V-Modell-Referenz Konventionsabbildungen: Als Basis organisationsweiter Entwicklungsprozesse muss das V-Modell kompatibel mit aktuellen (Quasi-)Standards, Normen und Vorschriften sein, wie zum Beispiel zur ISO 9001:2000, zur ISO/IEC 15288 und zum CMMI. Für jede dieser Konventionen enthält die V-Modell-Referenz Konventionsabbildungen eine Abbildung der Begriffe aus der entsprechenden Konvention in die Begriffswelt des V-Modells
  • Anhang: Beinhaltet eine Reihe von Verzeichnissen und Nachschlagewerken, wie zum Beispiel Methodenreferenzen, Werkzeugreferenzen, Glossar, Abkürzungsverzeichnis und Literaturangaben.
  • Vorlagen: Beinhaltet Vorlagen für die einzelnen Produkte in Form von RTF-Dokumenten. Diese Vorlagen können im Rahmen eines Projektes direkt eingesetzt oder gegebenenfalls zuvor angepasst und dann eingesetzt werden.

Wofür steht „Extreme Tailoring“ beim V-Modell-XT und nennen Sie Beispiele.

Extrem Tailoring steht für projektspezifische Anpassung des V-Modells. Das Tailoring beschränkt sich auf:

  • die Auswahl eines Projekttyps und in Anschluss
  • der Auswahl einer der möglichen Projekttypvarianten und
  • der Belegung mit Werten der dazugehörigen Projektmerkmale

 

Man unterscheidet dabei zwischen

  • Statischen Tailoring: Das Anwendungsprofil wird am Anfang eines Projektes definiert und bleibt während der Projektlaufzeit stabil.
  • Dynamisches Tailoring: Bestimmte Projektmerkmale ändern sich während der Projektlaufzeit

z.B. können in einem Projekt, das zunächst auf reine SW-Entwicklung ausgelegt war, im Projektverlauf noch HW-Anteile identifiziert werden. Auch die Abläufe in der Projektdurchführungsstrategie können angepasst werden

Scrum– Artefakte

Scrum– Artefakte

  • Vision (Idee)
  • ProductBacklog: Alle noch zu liefernden Funktionalitäten (eine vom ProductOwner nach Geschäftswert geordnete Liste von Produktanforderungen)
  • ProductBacklog Item: Die zu liefernden Funktionalitäten, die in einem ProductBacklog aufgelistet sind
  • Sprint Goal: Ziel des Sprints (festgelegt von Team und ProductOwner)
  • Selected ProductBacklog: Für diesen Sprint ausgewählte Backlog Items (entsteht im Sprint Planning Meeting 1)
  • Aufgaben: alles was getan werden muss, um das Ziel des Sprints zu erreichen
  • Sprint Backlog: Täglich aktualisierte Liste von offenen Backlog Items des akt. Sprints (entsteht im Sprint Planning Meeting 2)
  • Releaseplan: Übersichtsplan (informativ) der Backlog Items und Ihrer zugehörigen Sprints (zeigt, in welchem Sprint welches Backlog Item vom Team geliefert werden kann)
  • ImpedimentBacklog: Liste aller Blockaden, die ausgeräumt werden müssen

Scrum – Das Team

  • Forming: Das Team kommt zusammen und die Mitglieder des Teams kennen sich noch nicht
  • Storming: Erste Ideen werden gemeinsam entwickelt und auch die eine oder andere Sackgasse beschritten. Hierbei lernt das Team sich kennen
  • Norming: Die ersten Regeln innerhalb des Teams werden vereinbart. Die vom Team übernommen Verantwortung nimmt zu.
  • Performing: Das Team beginnt auf einem intuitiven Level miteinander zu arbeiten. Die Fähigkeiten der Teammitglieder werden nun voll genutzt.

Scrum – Der Sprint

  • Estimation Meeting
  • Sprint Planung, Sprint Goal
    • Spezifisch
    • Messbar
    • Attraktiv
    • Realistisch
    • Termin
  • Sprint Planning 2 – Design
  • Daily Scrum
    • Was habe ich erreicht?
    • Was will ich erreichen?
    • Was steht mir dabei im Weg?
  • Sprint Review

Anforderungsanalyse – Anforderungen (allgemein)***

  • Benutzeranforderungen: Spezifikationen in natürlicher Sprache und Diagrammen, zur Beschreibung der Funktionen des Softwaresystems und der Rahmenbedingungen in denen es betrieben werden soll
  • Systemanforderungen: Funktionen und Einschränkungen detaillierter festgelegt. Hieraus lässt sich z.B. das Pflichtenheft erstellen
  • Spezifikation des Softwareentwurfs: Abstrakte Beschreibung des Softwareentwurfs. Grundlage für exakten Entwurf, mit Details für Spezifikation des Softwareentwurfs.

Beispiele:

  • Benutzeranforderung: Die Software muss über Mittel zur Darstellung externer, von anderen Werkzeugen erzeugten Dateien verfügen und auf sie zugreifen können
  • Systemanforderungen:
    • Benutzer sollte über Möglichkeiten zur Definition externer Datentypen verfügen
    • Jeder externe Datentyp kann eine damit verknüpfte Anwendung besitzen, mit der die Datei bearbeitet wird
    • Jeder externe Dateityp kann als best. Symbol auf dem Bildschirm des Anwenders dargestellt werden

Funktionale Anforderungen***

Funktionale Anforderungen sind Anforderungen, die sich direkt auf die Funktion(en) des Systems beziehen.

Beispiele:

  • Der Benutzer soll die gesamte anfängliche Menge der Datenbank durchsuchen oder eine Teilmenge davon auswählen können
  • Das System soll geeignete Betrachtungswerkzeuge bieten, damit der Benutzer Dokumente aus dem Dokumentenspeicher lesen kann
  • Jeder Bestellung soll ein eindeutiger Bezeichner zugeordnet werden und der Benutzer soll diesen in den permanenten Speicher seines Kontos kopieren können

Arten Nichtfunktionaler Anforderungen***

  • Produktanforderungen: Anforderungen an das Verhalten des Produkts (z.B. Leistungsanforderungen, Zuverlässigkeitsanforderungen usw.)
  • Unternehmensanforderungen: Anforderungen aus dem Unternehmen heraus an das Produkt (z.B. Vorschriften für die Entwicklung, Entwurfsmethode, Anforderungen an Doku)
  • Externe Anforderungen: Alle Anforderungen außerhalb des Systems und des Entwicklungsprozesses (z.B. Kompatibilitätsanforderungen, gesetzliche Anforderungen)

Beispiele:

  • Produktanforderungen: Es soll möglich sein, dass die gesamte nötige Kommunikation zwischen den Applikationen und dem Benutzer durch den ADA-Standardzeichensatz ausgedrückt wird
  • Unternehmensanforderungen: Der Systementwicklungsprozess und lieferbare Dokumente sollen dem Vorgehen und den Ergebnissen entsprechen, die in XYSCo-SP-STAN-95 definiert sind
  • Externe Anforderungen: Das System soll den Benutzer des Systems keine persönlichen Informationen über den Kunden preisgeben, abgesehen vom Namen und der Referenznummer

User-Stories***

In Alltagssprache formulierte Systemanforderungen

Beispiele:

  • Als Betreiber der Software möchte ich jedem Besucher Werbung einblenden, um Geld zu verdienen
  • Als Datenschutzbeauftragter möchte ich, dass die gespeicherten Daten anonymisiert werden
  • Als Admin möchte ich, dass die IP-Adressen vor der Speicherung anonymisiert werden, um den Anforderungen des Datenschutzbeauftragen gerecht zu werden

Aufbau eines Use Case***

  • Name und Identifier: Eindeutiger Name und Identifikationsnummer
  • Beschreibung: Kurze Beschreibung, was im Case passiert, 2-3 Zeilen
  • Beteiligte Akteure: Beteiligte Personen oder Systeme, z.B. Anwender, Kunde, System etc.
  • Status: Status der Bearbeitung des Use Case, in Arbeit / bereit zum Review / im Review / abgelehnt / abgenommen
  • Verwendete Use Case: Greift der Case Use auf andere Case Use zurück werden diese hier aufgeführt
  • Auslöser: Fachlicher Grund dafür, das dieser Use Case ausgeführt wird
  • Vorbedingungen: Bedingungen, die vor der Ausführung diese Cases erfüllt sein müssen
  • Nachbedingungen / Ergebnis: Zustand, der nach einem erfolgreichen Durchlauf des Use Case erwartet wird
  • Invarianten: Bedingungen, innerhalb und durch den Use Case nicht verändert werden dürfen
  • Standardablauf: Typisches Szenario. Am Ende steht das Ziel des Use Case durch den Akteur. Nummerierung der Schritte. Beschreibung in strukturierter Sprache. Bei UML: Aktivitätsdiagramme oder Sequenzdiagrammen
  • Alternativer Ablauf: Szenarien außerhalb des Standardablaufs. Am Ende steht Misserfolg, Zielerreichung des Akteurs oder Rückkehr zum Standardablauf
  • Hinweis: Kurze Erklärungen zum besseren Verständnis. Hinweise zu Nebeneffekten, etc.
  • Änderungsgeschichte: Versionierung, Name des Autors, Datum

Prüfungen für Anforderungen im Pflichtenheft***

  • Gültigkeitsprüfung: Sind alle Funktionen enthalten? Haben sich aus den Anforderungen heraus neue Funktionen ergeben? Sind einzelne Anforderungen zu streichen, weil sie nicht von genügend Nutzern benötigt werden?
  • Konsistenzprüfung: Sind die Anforderungen im Dokument Widerspruchsfrei?
  • Vollständigkeitsprüfung: Sind alle durch den Systembenutzer erwarteten Funktionen und Einschränkungen im Anforderungsdokument enthalten?
  • Realisierbarkeitsprüfung: Ist das Zielsystem mit der aktuellen Technologie innerhalb der Budget- und Zeiteinschränkungen realisierbar?
  • Verifizierbarkeitsprüfung: Sind die Anforderungen aus dem (Vertrags-) Dokument konkret verifizierbar im Zielsystem?

Methoden zur Anforderungsvalidierung***

  • Anforderung-Review: Team von Gutachtern analysieren systematisch die Anforderungen
  • Prototypen: Der Endbenutzer/Kunde überprüft die geforderten Anforderungen an einem funktionsfähigen Prototyp.
  • Testfallerzeugung: Für die Überprüfung der Anforderungen im Zielsystem wird ein Testfall erarbeitet, um die korrekte Umsetzung zu überprüfen
  • Automatische Konsistenzprüfung: Werden die Anforderungen in einer formalen Notation ausgedrückt, so können sie mittels CASE-Werkzeugen automatisch auf Konsistenz geprüft werden.

Anforderungs-Reviews***

  • Verifizierbarkeit: Ist die Anforderung überprüfbar?
  • Verständlichkeit: Wurde die Anforderung richtig verstanden bei der Beschreibung durch den Endbenutzer / Kunden?
  • Nachvollziehbarkeit: Ist der Ursprung einer Anforderung und die auf sie aufbauenden Anforderungen klar erkennbar? Wichtig für die Abschätzung von Folgen einer Änderung.
  • Anpassungsfähigkeit: Kann die Anforderung ohne große Auswirkungen auf neue Systemanforderungen hin geändert werden?

Anforderungsmanagement***

  • Anforderungsidentifikation: Eindeutige Identifikation der betroffenen Anwendung
  • Ablauf des Änderungsmanagements: Aufgaben und Auswirkungen (Kosten / Zeitplanänderungen etc.), die sich aus der Änderung ergeben
  • Richtlinien zur Nachvollziehbarkeit: Definieren Verbindungen zwischen Anforderungen untereinander und zwischen Anforderungen und dem Systementwurf
  • Unterstützung durch CASE-Werkzeuge: Im Anforderungsmanagement treten große Informationsmengen auf, diese können mit verschiedenen Werkzeugen verwaltet werden. Von speziellen Systemen, bis hin zum einfachen Texteditor / Tabellenkalkulationsprogramm

Management für Anforderungsänderungen

Étudier