sweGL

anna.vonflue
Mind Map by anna.vonflue, updated more than 1 year ago
anna.vonflue
Created by anna.vonflue over 6 years ago
31
0

Description

nicht nach Thema
Tags

Resource summary

sweGL
1 Wissen
1.1 Kernaktivität - Ziele
1.1.1 Requirements Engineering - Die Anforderungen der Kunden & Enduser erheben und analysieren
1.1.1.1 1. Spezifikation der Anforderungen (unmissverständlich & eindeutig)
1.1.1.2 2. Anfo (FA/NFA), die beschreiben, was das zu entwickelnde System können muss
1.1.1.3 3. Kundenvertrag
1.1.2 Software Design - Wie sieht die technische Lösung aus? Wie soll die Software werden?
1.1.2.1 1. Vorgaben vom RE werden umgesetzt
1.1.2.2 2. Entwurfsprinzipien um die Qualität zu steigern
1.1.2.3 3. Management Apsekt: Verteiltes, paralleles Arbeit im Team
1.2 Tätigkeiten des SWE
1.2.1 1. Requirements Eng. | RE-Elicitation & Analysis
1.2.2 2. Design | System- & Detaileddesign
1.2.3 3. Implementation | Programming
1.2.4 4. Integration & Test | Validation
2 Requirements Elicitation
2.1 Funktionale Anforderungen
2.1.1 Was soll das Sys können?
2.1.2 Schnittstellen
2.1.2.1 Wie soll das Sys interagieren? Die kommuni. von/mit User oder die externe Interaktion mit Server/ Bank
2.2 Nicht-Funktionale-Anfo.
2.2.1 Funktionalität
2.2.1.1 Angemessenheit, Richtigkeit, Sicherheit
2.2.2 Zuverlässigkeit
2.2.2.1 Reife, Fehlertoleranz, Wiederherstellbarkeit
2.2.3 Benutzbarkeit
2.2.3.1 Verständlichkeit, Erlernbarkeit, Bedienbarkeit
2.2.4 Effizienz
2.2.4.1 Zeitverhalten, Verbrauchsver.
2.2.5 Wartbarkeit
2.2.5.1 Modifizierbarkeit, Stabilität, Analysierbarkeit, Prüfbarkeit
2.2.6 Übertragbarkeit
2.2.6.1 Anpassbarkeit, Installierbarkeit, Austauschbarkeit
2.3 RE-Elicitation Vorgehen
2.3.1 1. Akteure iden.
2.3.2 2. Szenarios iden.
2.3.3 3. Usecases id.
2.3.4 4. Zusammenhänge zw. Usecase & Akteuren
2.3.5 5. NFA iden.
3 Requirements Analysis
3.1 Zweck Modellierung
3.1.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
3.2 AnalyseObjektModel (Bilder-Seite)
3.3 Verhaltensmodelle (Bilder-Seite)
4 System Design
4.1 Entwurfsprinzipien
4.1.1 Geheimnisprinzip
4.1.1.1 Was nicht zwingend (extern) kommuniziert werden muss, bleibt Private. "Need to know"-Prinzip.
4.1.1.1.1 Ein Subsystem erbringt eine klar definierte Leistung.
4.1.1.1.2 Andere Subsystem nutzen diese Leistung ohne zu wissen wie sie erbracht wird.
4.1.1.1.3 ich kaufe einen Käse ohne zu wissen wie der Käse genau hergestellt wurde
4.1.1.2 Viele Teile eines Sys können geheim sein, wenn alle Geheim -> System läuft nicht mehr
4.1.2 Nutzung v. vorhandenem
4.1.2.1 Wenn möglich können vorhandene Lösungen wiederverwendet werden
4.1.2.1.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.
4.1.3 Modulariät
4.1.3.1 Kohäsion
4.1.3.1.1 Je höher die Koh. desto besser die Module
4.1.3.1.1.1 Hohe Kohäsion: Viele Klassen die mite. in Bezieh. stehen und ähnlich Aufgaben erfüllen
4.1.3.1.1.2 Geringe Kohäsion: Zahlreiche Klassen, die nicht mitein. in Beziehung stehen
4.1.3.2 Kopplung
4.1.3.2.1 Mass für die Stärke der Abhängigkeit zw. zwei Modulen. Je geringer die wechsels. Kopplung, desto besser die Modulari.
4.2 Architekturstile
4.2.1 Client/Server
4.2.1.1 Stärken
4.2.1.1.1 Eff. Nutzung von vertl Sys. (Netzwerk), Billige Client HW (Laptop), leichte Erweiterung (Upgrade), Availability: Mehrere Server -> hohe Verfügbarkeit(Redundanz)
4.2.1.2 Schwächen
4.2.1.2.1 Datenaustausch erschwert, versch. Dateiformate, Netzwerk & Serverprobleme
4.2.1.3 Varianten
4.2.1.3.1 Thick/Fat Client
4.2.1.3.1.1 Client übern. viel arbeit (Lo&Be), leitet nur wenige Daten an Server weiter (Speicherung)
4.2.1.3.1.2 +: Netzwerke nicht stark beansprucht -> niedrige HW anfo.
4.2.1.3.2 Thin Client
4.2.1.3.2.1 Client übern. wenig arbeit, Hauptarbeit vom Server (Logik, Berechnung)
4.2.2 Peer2Peer, Repository, ModelViewController, Pipes&Filters, Layered Arch.
4.3 Subsystem Zerlegung (2Seite)
5 Detailed Design
5.1 Spezifikationen
5.1.1 Subsystem wählen
5.1.1.1 1. Attribute, Methoden ergängen anpassen (Typen, Sig)
5.1.1.1.1 2. Sichtbarkeit spez.
5.1.1.1.1.1 3. Randbedingungen spez.
5.1.1.1.1.1.1 4. Ausnahmefälle spez.
5.1.1.1.1.1.1.1 Exceptions
5.1.1.1.1.1.2 Vor-, Nachbedingungen & Invarianten
5.2 Zugriff
5.2.1 '#' Protected: Können nur von Klasse & deren Subklassen verwedent werden
5.2.2 '-' Private: Können nur von eigener Klasse aufgerufen werden
5.2.3 '+' Public: Für alle sichtbar
5.3 Information Hiding
5.3.1 s. Geheimnispr.
5.3.1.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).
6 Softwaretesting
6.1 Zielsetzungen
6.1.1 Ziel ist es, Testfälle zu identifizieren, mit denen die höchste Wahrscheinlichkeit gegeben ist festzustellen, ob das Softwaresystem korrekt funktioniert
6.1.2 Ein guter Test hat möglichst hohe funktionale oder nichtfunktionale Abdeckung
6.1.3 Ein Test ist dann erfolgreich, wenn er einen Fehler gefunden hat (dasselbe gilt für eine Testerin / einen Tester)
6.2 Testaktivitäten
6.2.1 Unit-Testing
6.2.1.1 Test einer einzelne Komponente (Subsystem oder Klasse)
6.2.1.1.1 Zielsetzung: Fehler in einzelnen Komponenten finden
6.2.2 Integration Testing
6.2.2.1 Test einer Gruppe von Subsystemen (allenfalls das gesamte System)
6.2.2.1.1 Zielsetzung: Fehler im Zusammenspiel oder den Schnittstellen von Subsystemen finden
6.2.3 System Testing
6.2.3.1 Test des gesamten Systems
6.2.3.1.1 Zielsetzung: Abweichungen des Gesamtsystems von den funktionalen und nicht funktionalen Anforderungen identifizieren
6.2.4 User Acceptance & Usability Testing
6.2.4.1 Evaluation des Endprodukts (Übergabe)
6.2.4.2 Die Kundschaft testet
6.2.4.2.1 Zielsetzung: Erkennen welche Akzeptanzkriterien das System (noch) nicht erfüllt
6.3 TestMethoden
6.3.1 Black Box Testing
6.3.1.1 Grundlage: Kompo-Spez
6.3.1.1.1 Aufdecken; Fehler im Vergelich zur Spez
6.3.1.1.2 Aufdecken: Fehler in Spez oder Unvollstän.
6.3.1.1.3 Fokus auf die Zielerreichung der Software (Funktionalität)
6.3.2 Whitebox Testing
6.3.2.1 Grundlage: Code
6.3.2.1.1 Aufdecken: Fehler in Teilkompnenten
6.3.2.1.2 Aufdecken: Fehler in Teilkom. lokalisieren
6.3.2.1.3 Debugging ist auch ein Beispiel für White Box Testing
Show full summary Hide full summary

Similar

sweGL - Modelle
anna.vonflue
CHEMISTRY C1 5
x_clairey_x
CUMULATIVE FREQUENCY DIAGRAMS
Elliot O'Leary
Computer Systems
lisawinkler10
GCSE REVISION TIMETABLE
neharaniga
Study Tips to Improve your Learning
miminoma
Acids and Bases
Sarah Egan
Using GoConqr to study science
Sarah Egan
General questions on photosynthesis
Fatima K
1PR101 2.test - Část 14.
Nikola Truong