sweGL

sweGL

Wissen
1. Kernaktivität - Ziele
  1. Requirements Engineering - Die Anforderungen der Kunden & Enduser erheben und analysieren
    1. 1. Spezifikation der Anforderungen (unmissverständlich & eindeutig)
    2. 2. Anfo (FA/NFA), die beschreiben, was das zu entwickelnde System können muss
    3. 3. Kundenvertrag
  2. Software Design - Wie sieht die technische Lösung aus? Wie soll die Software werden?
    1. 1. Vorgaben vom RE werden umgesetzt
    2. 2. Entwurfsprinzipien um die Qualität zu steigern
    3. 3. Management Apsekt: Verteiltes, paralleles Arbeit im Team
2. Tätigkeiten des SWE
  1. 1. Requirements Eng. | RE-Elicitation & Analysis
  2. 2. Design | System- & Detaileddesign
  3. 3. Implementation | Programming
  4. 4. Integration & Test | Validation
Requirements Elicitation
1. Funktionale Anforderungen
  1. Was soll das Sys können?
  2. Schnittstellen
    1. Wie soll das Sys interagieren? Die kommuni. von/mit User oder die externe Interaktion mit Server/ Bank
2. Nicht-Funktionale-Anfo.
  1. Funktionalität
    1. Angemessenheit, Richtigkeit, Sicherheit
  2. Zuverlässigkeit
    1. Reife, Fehlertoleranz, Wiederherstellbarkeit
  3. Benutzbarkeit
    1. Verständlichkeit, Erlernbarkeit, Bedienbarkeit
  4. Effizienz
    1. Zeitverhalten, Verbrauchsver.
  5. Wartbarkeit
    1. Modifizierbarkeit, Stabilität, Analysierbarkeit, Prüfbarkeit
  6. Übertragbarkeit
    1. Anpassbarkeit, Installierbarkeit, Austauschbarkeit
3. RE-Elicitation Vorgehen
  1. 1. Akteure iden.
  2. 2. Szenarios iden.
  3. 3. Usecases id.
  4. 4. Zusammenhänge zw. Usecase & Akteuren
  5. 5. NFA iden.
Requirements Analysis
1. Zweck Modellierung
  1. Entwurfsprozess zur Planung von SW. Prozess ist wichtig, um die Komplexität, welche die meisten Programme aufweisen, für die Entwickler handhabbar zu machen & das Risiko von Fehlentwicklungen zu verringern - UML
2. AnalyseObjektModel (Bilder-Seite)
3. Verhaltensmodelle (Bilder-Seite)
System Design
1. Entwurfsprinzipien
  1. Geheimnisprinzip
    1. Was nicht zwingend (extern) kommuniziert werden muss, bleibt Private. "Need to know"-Prinzip.
      1. Ein Subsystem erbringt eine klar definierte Leistung.
      2. Andere Subsystem nutzen diese Leistung ohne zu wissen wie sie erbracht wird.
      3. ich kaufe einen Käse ohne zu wissen wie der Käse genau hergestellt wurde
    2. Viele Teile eines Sys können geheim sein, wenn alle Geheim -> System läuft nicht mehr
  2. Nutzung v. vorhandenem
    1. Wenn möglich können vorhandene Lösungen wiederverwendet werden
      1. Untersuchen: Ist eine Wiederverwendung “leicht”, d.h. ein Subsystem einzubetten ohne gravierende Änderungen am Gesamtsystem vorzunehmen. - Ist ein Subsystem abgeschlossen, z.B. ein Datenbanksystem.
  3. Modulariät
    1. Kohäsion
      1. Je höher die Koh. desto besser die Module
        Hohe Kohäsion: Viele Klassen die mite. in Bezieh. stehen und ähnlich Aufgaben erfüllen
        Geringe Kohäsion: Zahlreiche Klassen, die nicht mitein. in Beziehung stehen
    2. Kopplung
      1. Mass für die Stärke der Abhängigkeit zw. zwei Modulen. Je geringer die wechsels. Kopplung, desto besser die Modulari.
2. Architekturstile
  1. Client/Server
    1. Stärken
      1. Eff. Nutzung von vertl Sys. (Netzwerk), Billige Client HW (Laptop), leichte Erweiterung (Upgrade), Availability: Mehrere Server -> hohe Verfügbarkeit(Redundanz)
    2. Schwächen
      1. Datenaustausch erschwert, versch. Dateiformate, Netzwerk & Serverprobleme
    3. Varianten
      1. Thick/Fat Client
        Client übern. viel arbeit (Lo&Be), leitet nur wenige Daten an Server weiter (Speicherung)
        +: Netzwerke nicht stark beansprucht -> niedrige HW anfo.
      2. Thin Client
        Client übern. wenig arbeit, Hauptarbeit vom Server (Logik, Berechnung)
  2. Peer2Peer, Repository, ModelViewController, Pipes&Filters, Layered Arch.
3. Subsystem Zerlegung (2Seite)
Detailed Design
1. Spezifikationen
  1. Subsystem wählen
    1. 1. Attribute, Methoden ergängen anpassen (Typen, Sig)
      1. 2. Sichtbarkeit spez.
        3. Randbedingungen spez.
        4. Ausnahmefälle spez.
        Exceptions
        Vor-, Nachbedingungen & Invarianten
2. Zugriff
  1. '#' Protected: Können nur von Klasse & deren Subklassen verwedent werden
  2. '-' Private: Können nur von eigener Klasse aufgerufen werden
  3. '+' Public: Für alle sichtbar
3. Information Hiding
  1. s. Geheimnispr.
    1. Information hiding is a technique for reducing the dependencies between modules: • The intended client is provided with all the information needed to use the module correctly, and with nothing more • The client uses only the (publicly) available information (Interface).
Softwaretesting
1. Zielsetzungen
  1. Ziel ist es, Testfälle zu identifizieren, mit denen die höchste Wahrscheinlichkeit gegeben ist festzustellen, ob das Softwaresystem korrekt funktioniert
  2. Ein guter Test hat möglichst hohe funktionale oder nichtfunktionale Abdeckung
  3. Ein Test ist dann erfolgreich, wenn er einen Fehler gefunden hat (dasselbe gilt für eine Testerin / einen Tester)
2. Testaktivitäten
  1. Unit-Testing
    1. Test einer einzelne Komponente (Subsystem oder Klasse)
      1. Zielsetzung: Fehler in einzelnen Komponenten finden
  2. Integration Testing
    1. Test einer Gruppe von Subsystemen (allenfalls das gesamte System)
      1. Zielsetzung: Fehler im Zusammenspiel oder den Schnittstellen von Subsystemen finden
  3. System Testing
    1. Test des gesamten Systems
      1. Zielsetzung: Abweichungen des Gesamtsystems von den funktionalen und nicht funktionalen Anforderungen identifizieren
  4. User Acceptance & Usability Testing
    1. Evaluation des Endprodukts (Übergabe)
    2. Die Kundschaft testet
      1. Zielsetzung: Erkennen welche Akzeptanzkriterien das System (noch) nicht erfüllt
3. TestMethoden
  1. Black Box Testing
    1. Grundlage: Kompo-Spez
      1. Aufdecken; Fehler im Vergelich zur Spez
      2. Aufdecken: Fehler in Spez oder Unvollstän.
      3. Fokus auf die Zielerreichung der Software (Funktionalität)
  2. Whitebox Testing
    1. Grundlage: Code
      1. Aufdecken: Fehler in Teilkompnenten
      2. Aufdecken: Fehler in Teilkom. lokalisieren
      3. Debugging ist auch ein Beispiel für White Box Testing

Siguiente

Descripción

Resumen del Recurso

Similar

	Creado por anna.vonflue hace más de 10 años