KategorienEingabedaten, Abfragen, Ausgabedaten, VoraussetzungEinsetzen wenn Anforderungen Vorteile Nachteile Requirementsmanagement Begriffe

Datenbestände, Referenzdaten bekannt sind (Lastenheft), Gesamtes Produkt soll Produktanforderungen sind Ausgangspunkt, An Nur Gesamtaufwand schätzbar, In Originalform Ist die systematische Vorgehensweise um alle Prinzip (Objektorientierung),Methode (OOA)
Schritte:1Anforderungen Kategorie zuordnen, 2Klassifizierung im Blickfeld stehen, Aus sich des Auftraggebers verschiede Bereiche anpassbar, An neue Techniken personalintensiv nicht automatisierbar, Zu stark Anforderungen zu Definieren, Spezifizieren, Konzept (Objekt, Klasse), Notation (UML)
Einfach mittel komplex, 3Eintrag in Berechnungsformular, Anzahl bearbeiten, Bewertung durch Mitarbeiter mit anpassbar, An unternehmensspezifische Verhältnisse funktionsbezogen, Qualitätsanforderungen verifizieren, Analysieren, Verarbeiten und Werkzeug (Rational Rose), Prozess
der Ausgaben in Anzahl eintragen und multiplizieren 4Bewertung Wissen zur Produktanforderung, Ist-Aufwand muss anpassbar, Festgelegte methodische Schritte werden nicht berücksichtigt, Mischung von einem Projekt zuzuweisen, Im Projekt zu (Anforderungsanalyse),Modell (Analyse Modell)
der Einflussfaktoren 5Berechnung der bewerteten Function- ermittelbar sein Leicht erlernbar, Gute Transparenz Projekt- und Produkteigenschaften verfolgen und Änderungen zu vereinbaren
Points 6Ablesen des Aufwands in MM 7Aktualisierung der Daten
Kernanforderung ermitteln Projektvision: Leitlinie für Schritte Brainstorming, Analyse der Anforderungen Spezifikationen Anforderungsspezifikation, Regeln Anforderungen sind nicht stabil, Zu lange Analyse führt zu
Risiken
ein Projekt, Definierte und vereinbarte Ziele, Stimme des (Zusammenhänge und Einschränkungen verstehen), Vorläufige Systembeschreibung der Lösungsspezifikation, Beschreibung Paralyse, Nur ein zügiger Projektabschluss kann die
Kritische Anforderungen werden übersehen, Nur funktionale
Kunden verstehen Klassifikation in offensichtlich versteckt überflüssig, Finden von wie die Lösung aussieht, Systemmodell Logische Sicht  Sicht Anforderungsfluktuation begrenzen
Anforderungen werden beachtet, Kunden sind unzureichend
nicht erwähnten Funktionen, Herausarbeiten von des Benutzers, Prozesssicht  Zusammenwirken System und
repräsentiert, Unkontrollierte Änderungen von
Techniken Ziel: Alle gewünschten Eigenschaften, Einschränkungen, Entscheidungen als Vereinbarungen Teilsystem, Implementierungssicht, Installationssicht, Anforderungen ermitteln Ideen im Team finden und diskutieren,
Anforderungen, Beschreibung von Anforderungen als Entwurf,
Funktionen Einschränkungen und Erwartungen ermitteln festlegen und unterzeichnen, Prioritäten festlegen Strukturierte Spezifikation, Modellierung des Problemraums, Beobachten, Befragen, Altsysteme analysieren,
Anforderungen werden nicht geprüft
Modellierung und Beschreibung des Lösungsraums Wiederverwendung
Perfektionierung von Anforderungen und Spezifikation
An die Technik Workshops, Mind Mapping  Systemmodelle Wie sieht die Systemumgebung aus?, Wie Vom Satz zur Anforderung Problem der Anforderungsanalyse, Ausgangsmaterialien (Lastenheft, Interview SOPHIST-Group Regelwerk zur Textanalyse, Aufspüren von
Strukurierung, Kategorisierung, Hirarchisierung, Use Case soll sich das System verhalten?, Wie soll das System Ergebnisse …), Interpretation der sprachlichen Äußerungen notwendig, Also Kommunikationsproblem!!!, Notwendig sprachlichen Problemen, Tilgung Unvollständig spezifizierte
Modellierung  Abstrakte Sicht des Systems, Data Dictionary strukturiert werden?, Modellierung der Systemumgebung  Analyse der verwendeten Sprache, Prozesswörter, Modaloperationen der Möglichkeit, Unvollständige
 Formale Beschreibung der Datenstruktur, CRC Karten  Use Case Diagramme, Modellierung des Verhaltens Vergleiche, Modaloperationen der Notwendigkeit, Implizierte Annahmen
Auffinden von Klassen bei Objektorientierter Analyse State-Machine Sequenzdiagramm, Modellierung der Struktur ChomskyOberflächen und Tiefenstruktur der Sprache ,Form/Bedeutung eines Satzes, Mehrdeutigkeit, Generalisierung Universalquantoren, Unvollständige spezifizierte
(Komposition, Klassifikation) Synonymität, ProblemSätze werden anhand persönlicher Wirklichkeit interpretiert, Individuelle Zuordnung Bedingungen, Substantive oder Bezugsindex, Verzerrung
ERD oberflächenstruktur zu Tiefenstruktur, Transformation Zuordnung Oberflächenstruktur/Tiefenstruktur und Nominalisierungen, Funktionsverbgefüge,,
Analyse von Tilgung Regeln 1Anforderungen im Aktiv formulieren, 2Prozesse durch vollverben ausdrücken, 3Unvollständig umgekehrt, OberflächenstrukturForm eines Satzes, TiefenstrukturBedeutung eines Satzes, Tilgung Vermeidung von unklaren Formulierungen
spezifizierte Prozesswörter aufdecken, 4Unvollständige vergleiche und steigerungen ermitteln, 5Mögliches und unmögliches klären, Selektive Wahrnehmung / Auf dem Weg von der Tiefenstruktur zur Oberflächenstruktur Elemente weglassen,
6Modaloperator der notwendigkeit auf benötigte ergänzung prüfen, 7Implizite annahmen finden, 8Beziehungen zwischen objekten Generalisierung  Erfahrung zu einer allgemeinen Vorstellung erweitern, VerzerrungTatsachen, Realität, Design Verallgemeinert: zusammenwirken der Komponente eines
als anforderung formulieren, 9Universalquantoren bestimmen, 10Nur definierte quantitative Angaben verwenden, 11Ermitteln von Erfahrungen umgestalten oder verfälschen komplexen systems, Einflussfaktoren Einsatzbedingungen
unvollständig spezifizierten Bedingungen, 12Substantive ohne bezugsindex hinterfragen, 13Substantive immer in der einzahl
Anforderungen, Umgebungs/randbedingungen  zielplattform,
verwenden, 14Artikel ggf. je nach bedeutung durch jeder, alle oder genau ein ersetzen, 15Unbestimmte artikel nur vor substantiven Anforderungsschablonen Definitionslisten: Nicht-funktionale anforderungen, Qualitätsanforderungen,
das gerade damit definiert wird, 16Bestimmter artikel vor schon definierten substantiven, 17Nominalisierung hinterfragen, Legt bauplan der syntaktischen struktur einer einzelnen Anforderung an, Anforderungsschablonen
18Funktionsverbgefüge durch einfache, direkte vollverben ersetzen, 19Redundanz beseitigen Ziel Gut formulierte anforderungen verfassen, Regeln 1Bestimmen des Konstuktionsprinzipien, Allgemeine Architekturkonzepte Generische  allgemeingültige
prozesses, 2Die aktivität des systems charakterisieren, 3Festlegen der Bedeutung liegt in inhalten, ansätze, Frameworks  Grundgerüst, Referenzarchitekturen 
Architekturtypen BasistypenShared data - repository Shared service  client/server model, ServerAnbieter von verbindlichkeit, 4Objekte und ergänzungen der objekte hinzufügen falls Vermeidung von inkonsistenz durch Muster für Architekturen als Ganzes, Entwurfsmuster  Muster für
model, Zentrale Datenbasis, Steht allen teilsystemen zur leistung, Client  nutzer von leistung, Normalerweise erforderlich, 5Randbedingung unter der eine anforderung erfüllt werden soll benutzung definierter begriffe einzelne probleme
verfügung, Vorteile Effizient, Administration zentralisiert, Client/server auf versch rechnern, Vorteile Dienste ergänzen
Abstract machine  layered model, Zerlegung in schichten: präsentation 
Komponenten bei nutzung unabhängig, Nachteile unabhängig, Dienste leicht integrierbar, In netzwerken Verteilte systeme VorteileResource sharing, Offenheit, Nebenläufigkeit,
applikationslogikDatenbasis, Strenges modell jede schicht benutzt nur die darunterliegende
Strukturabhängigkeit der Komponente, Verteilung großer reps. einfache verteilung der dienste, Nachteile Keine gem. Skalierbarkeit, Ausfallsicherheit, Nachteile Komplexität, Sicherheit, Administrationsaufwand,
schicht, Kann performance probleme verursachen, Zugriffe über mehrere Schichten nur in
Auf mehrere rechnersys datenstruktur, Spezifische datenbasis je server, Zeigt Vorhersagbares verhalten, 2 wesentl erscheinungsformen Cleint/sever, Verteilte objekte
ausnahme, Auseinanderhalten, Schichtenmodell  aufteilung der aufgaben, Aufteilung auf
verteilung von aufgaben auf prozessoren
Prozessoren  leistungsanforderung, physikalische verteilung, Vorteil Unterstütz schrittweise
Urspr. 2-tier client/server
Verteilte Objekte Ziele Unterscheidung C/S aufheben, Service Oriented Archticture Anwendungsübergreifend entwicklung, Teststubs verwendbar, Austausch der implementierung mögl
Öffentl schnittstellen anbieten, Objekte/ dienste integrieren, definierte schnittstellen, Registrierung von Service-Angeboten,
MiddlewareKommunikation der Objekte, Objekte hinzufügen Bereitstellung von Services, Beispiel : Web Services, Vorteile Referenzarchitecturen Data-processing applications, Transaction-processing applications Oft in form von Event processing systems Reagieren auf ereignisse, Erzeugen
entfernen, Software bus, Vorteile Flexibel und skalierbar, Öffentliche Beschreibung der Services, verzögerte Bindung Einfache meist sequentielle strukt, Input, process, output, einer reaktion durch ereignisinterprätation, Ereignisquellen,
informationssystemen, Datenbereitstellung, Aktualisierung,
Verteilung der Objekte anpassbar, Neue Objekte nach bedarf, Bis zur Auslieferung, Bis zur Ausführung, Ermöglicht Wechsel Komplexität der datenstruktur nicht der applikationslogik Systemumgebung, benutzerschnittstellen, Realtime geforderte
Benutzeranforderungen (Transaktionen), Informationssystem
Dynamische (re-)konfiguration mögl des Providers zur Laufzeit des Systems, Abrechnungsmodelle antwortzeiten, Oft bestandteile anderer systeme
Bereitstellung von unterschiedlichen informationen,
Kommunikationsstandards SOAP (Simple Object Access Protocol
Regelwerk, Abfragen, Ressourcenverwaltung, Transaktionen
Entwurf von Softwarearchitekturen Es gibt keine Vollständigkeit Schnittstelle einer Fundamentale entwurfsprinzipien Abstraktion  idealisierung generalsirung Speicherung, Komponenten, UI, Ressource delivery, ressource Language processing systems Verarbeiten formale syntax,
wunderwaffe, Kriterien für korrekten entwurf, Kopplung Komponente deckt Verantwortungsbereich ab, Kapselung  schnittstellen, verborgene implementierung policy control, ressource mngmt, ressource allocation Transformieren sie nach regelwerk, Regelwerk auch formal
Abhängigkeit von Komponenten, Ziel: minimal, Kohäsion Ziel: Vollständigkeit in minimaler form, Modularität  sinneinheiten spezifiziert
Innerer zusammenhalt von komponenten, Ziel: maximal, Einfachheit Zulängliche funktionalität im Hirarchie  strukturen(enthalten in, oder besteht aus), generalisirung(Verbung)
HeuristikenLösungsverfahren für: Projektumfeld, Anforderungen hinterfragen, Von anderen systemen inspirieren lassen,
Zugänglichkeit Erfüllung der anforderung durch komponente, vergleich zu angemessenen schnittstellen, Ziel: Konzeptuelle integrität durchgängige anwendung von entwurfsentscheidung
Kommunizieren, feedback, Entwurf So einfach wie möglich / angemessen komplex modellieren, verantwortlichkeit beachten/
Ziel: erfüllung mit mögl. Geringem Aufwand größtmögliche einfachheit Ziel: komplexität beherrschen, semantischen inhalt jeder information erhöhen
konzentration auf schnittstellen/verantwortungsbereich einer komponente beachten, Beherrschung von komplexitätTeile und
herrsche/ details verstecken/risiken kapseln, Funktionalität und kontrolle trennen, Fachlogik und infrastruktur trennen,
Architekturprinzipien Entwurfsmuster ArbeitsmethodikDie schwierigsten teile zuerst, Prototypen verwenden nach einsatz beseitigen, Entscheidungen dokumentieren
Prinzip der
Jedes Muster beschreibt ein in unserer Umwelt beständig
-losen kopplungvermeidung zirkulärer abhängigkeiten ErzeugungsmusterFabrikmethode : definiere Schnittstelle zur Strukturmuster : Brücke Entkopplung von Abstraktion und
-hohen kohäsion wiederkehrendes Problem und erläutert den Kern der Lösung für
Objekterzeugung, überlasse Einzelheiten den Unterklassen Implementierung, so daß beide unabhängig voneinander
-entwurf für veränderung erwartbare vs. Nicht erwartbare veränderung dieses Problem, so daß Sie diese Lösung beliebig oft anwenden
können Abstrakte Fabrik : definiere Schnittstelle zur Erzeugung von geändert werden können, Kompositum : Zusammenfassung von
-seperation of concerns  trennung von aufg bereichen, zerlegung in subsystems
-Information hiding  auch zur strukt größerer systeme, dient umsetzung loser koppl Familien von Objekten, überlasse Einzelheiten den Unterklassen Objekten zu Baumstrukturen, um Teil-Ganzes-Hierarchien zu
-Abstraktion spezialfall von seperations of … , un-/wichtiges unterscheiden Singleton : stelle sicher, dass es nur eine Instanz einer Klasse gibt repräsentieren, Proxy : Kontrolle über ein Objekt auf einen
-Modularität wohldefinierte bausteine, leichte austauschbarkeit, wiederverwendba MVC: unterteilung in 3 komponente aufgabenteilung, vorgelagerten Stellvertreter verschieben
-Rückverfolgbarkeit arch.ansatz aus code erkennbar sein, designentsch nachvollzieh konsistenz sciherstellung
-Inkrementalitätarchänderung in kleinen schritten, einsatz prototypen Data access pattern
Active Domain Object
-Muster zur anwendbarkeit bei interaktion mit datenbasen
-Decoupling pattern, bindeglied zwischen applikation und datenbasis
Verhaltensmuster : Vermittler Kapselung des Zusammenspiels Publish subscriber:Ziel: interaktion zwischen komponenten ohne -Bereiche
-Decoupling patterns  strukturierung mit ziel entkopplung -Vorteile code-vereinfachung, entkopplung, einfache gruppierung
einer Menge von Objekten, Beobachter (Observer) Eintreten von sich zu kennen, Bestandteile observer mutter, publisher
-Resource patterns effizienten einsatz ressourcen d. ADO in kompo
Ereignissen an registrierte Objekte übermitteln, Zustand ermöglicht notifications/events, Motivation monitoring von
einem Objekt sein Verhalten zu ändern, wenn sich sein innerer netzwerkkomponenten, Benachrichtigung über auftretende -Input/output patternsvereinfachung des datenaustauschs -Nachteilverantwortung der db-zugriffe wird verteilt
Zustand ändert; Zustände auf Klassen abbilden, Besucher (Visitor) ereignisse nicht vorhersagbar, unterschied oft, 1. -Cache patterns verwaltung von puffern
Kapselung einer auf Elementen einer Objektstruktur Lösungsansatzdirekte kommunikation, vermittler,observer, -Concurrency patterns implementierung von nebenläufigkeit
auszuführenden Operation Bestandteile event, publisher, subscriber, eventservice,filter,class
Vorteile publiseher u. subscriber effizient koppelbar, ggf je PagingIterator Software-Qualität : Gesamtheit der
Object/Relational map Input/output pattern zugriffe auf ergebnismenge einer abfrage Merkmale und Merkmalswerte eines Software-Produkts, die sich
eventtyp ein service, 2. Lösungsansatz publisher verwalten direkt
Decoupling pattern, abbildung von klassen auf db tabellen Vorteil geringer speicherbedarf da ggf akt seite gespeich, auf dessen Eignung beziehen,
eine subscriberliste, Publisher meldet seine veröffentlichung,
Zu beachten obj.identität, verwaltung aggregation, abbildung v. effizienter datentransfer festgelegte oder vorausgesetzte Erfordernisse zu erfüllen
eventservice verwaltet zuordnungsliste, eventservice reicht referenz
vererbungsstruktur bei registrierung von subs an den passenden publsisher weiter Nachteile seitenweise bearbeitung bei client berücks, db
ressourcen werden beleg Was erzielt man Qualität ?
Siedersleben Konsequenzen Qualitätsbegriff kein absolutes Maß für Qualität,
Persistenz nur in Bezug auf Erfordernisse,
-Denken schnittstellen u. komponenten komposition(Zusammenbau), Konfig(kompon verb)
-Schnittstelle zum Anwendungskern Messung von definierten Merkmalen, Merkmalswerte als Maßstäbe
-Finden von komponenten und kontrolle der abhängigkeiten zwischen komp und schnittstelle
-Poolanlegen u. löschen persistenter objekte für Qualität
-Softwarekategorien(Blutgruppen), trennung von anwendung(A) und Technik(T)
-Queryausführung von abfragen „Vermeiden, Erkennen, Beheben“ Regelkreis
-Kategorie 0 alles im sys zur verfügung stehende Wird umgesetzt im
-Keine abhängigkeit von bestimmten db-implem beim anw.kern
-Kategorie A befasst sich mit fachlicher Anwendung, ist frei von technik -Transaktionsmngmtbestätigen oder rücksetzen der änderungen an objekten Qualitätsmanagement(prozess)Qualitätsplanung,
-Kategorie T unabhängig von anwendung, durch implementierungstechnik bestimmt Qualitätslenkung, Qualitätssicherung, Qualitätsverbesserung
-Querydefiner verwalten von abfragedefinitionen
-Kategorie R Repräsentationen ohne verarbeitung
-Modeldefiner verwalten von db-schema
-Komponenten gehören zu keiner Kat.  komplexität steigt mit anz. Kategorien a und t komplexer als 0 komponenten
-Pobleme 1obj-1datensatz, !vollst. lesen von obj, vererbung
-Unreine software vermischung von A- und T komplexere abh, schwer wartbar, kaum reuse, vermeiden!!! Qualitätsmanagement (1)
-Struktur des persistenzmanager Umfaßt »alle Tätigkeiten der Gesamtführungsaufgabe,
-5 regeln
-Connectionmngr dbverbindung verwalten wiederverwenden wiederherst welche die Qualitätspolitik, Ziele und Verantwortungen
-Systemaufteilung nach kategorien vornehmenabh u. importbeziehung betrachten
-Poolnpools erzeugung mit poolfactory, nur obj, commit/rollback lebenszyk festlegen sowie diese durch Mittel wie Qualitätsplanung,
-Jede einfache komponente gehört zu einer kat
-Querymanager ausführen verwalten von anfragen, kapselung der implementierung in – Qualitätslenkung, Qualitätssicherung und
-Software mit diff. Kat. Durch 0-schnittstellen oder r-software verbinden
verschiedene anfragesprachen Qualitätsverbesserung im Rahmen des
-Unreine komponente vermeiden -Mappingmngr transformation zwischen objekten und tabellen Qualitätsmanagementsystems verwirklichen«
-Möglich viel software der kat 0 entwickeln
-Mehrschichtarchitekturen
-Anwendungskern stellt leistungen zur verfügung, importiert leistungen Mappingmngr: Qualitätssicherung (QS)
-Benutzerschnittstellen, schnittstellen zu nachbarsystemen -Bestandteile: »Alle geplanten und systematischen Tätigkeiten, die
-Persistenz(+db) oo ansatz im kern, rel dbs, transformation erforderlich, bereitstellung schnittstellen typ 0, bereitstellung allg. -Modelmngrverwaltet angaben zur abbildung oorelational innerhalb des Qualitätsmanagementsystems verwirklicht
abfrageschnittstelle -Statementmngrgeneriert und verwaltet alles sql anweisungen sind, und die wie erforderlich dargelegt werden, um
-Aufbau anwendungskernenthält a-komponente -Objecttrafotransformation von obj in die sql darstellung angemessenes Vertrauen
-Kompositionsmngr stellt ausführungskontext zur verfügung, führt ausnahme behandlung durch, steuert transaktionen, konfigt db- -Ablaufpool holt bei statemngr auszuführende sql anweisung u. übergibt --- zu schaffen, daß eine Einheit die Qualitätsforderung erfüllen
-connectionmngrconnectmngr benutzt schnittst zu objtrafo zur wird«
zugriffsrechte
-Wiederverwendbarkeit mögl. Wenig annahmen, strategien(z.b ausnahmebehandl) umsetzung von sql anweisung connmngr setzt sql anweisung ab

Qualitätslenkung Analyse Kontrollfluss (1)

Die »Arbeitstechniken und Tätigkeiten, die zur Erfüllung der Qualitätsforderungen angewendet
werden«
Analytische QM / Überblick (1)
Oft : 80% der Probleme in 20% des Codes, Analyse : finde die problematischen 20% !, Analyse
: bringt in das Produkt oder den Entwicklungsprozeß keine Qualität per se, Messung des
existierenden Qualitätsniveaus, Ausmaß und Ort der Defekte können identifiziert werden, Das
Ziel ist die Prüfung und Bewertung der Qualität der Prüfobjekte.
Statische Analyseverfahren :
Identifizieren Teile mit fragwürdiger Qualität, Ergeben Hinweise auf potentielle Fehler,
Erfordern keine (vollständig) ausführbaren Programme, Können frühzeitig und während der
gesamten Entwicklung eingesetzt werden
Qualitätsplanung
Qualitätsanforderungen an den Prozeß und das Produkt in überprüfbarer Form festlegen
• Auswahl oder Aufstellung eines Qualitätsmodells, Festlegung von Soll-Qualitätsstufen für die
Qualitätsindikatoren, Durchgehende Instrumentierung des Entwicklungsprozesses mit
Meßpunkten zur Vorhersage der definierten Qualitäts-ziele sowie die Auswahl geeigneter
Methoden und Werk-zeuge zur Erfassung der Meßwerte
Qualitätslenkung und –sicherung
Setzt die Qualitätsplanung um, Steuert überwacht und korrigiert den Entwicklungsprozeß mit
dem Ziel, die vorgegebenen Anforderungen zu erfüllen, Die Überwachung der
Qualitätsprüfung nach Plan ist Teil der Qualitätslenkung, Die Auswertung der Ergebnisse
basiert auf einem Vergleich der
Soll- und Istwerte, Werden Anforderungen nicht erfüllt, dann müssen korrektive
Maßnahmen ergriffen werden.
Qualitätsprüfung
Führt die im Rahmen der Qualitätsplanung festgelegten Maßnahmen zur Erfassung von
Qualitäts-Istwerten durch, Überwacht ob die konstruktiven Maßnahmen umgesetzt wurden
Kontrollstruktur der Testlinge bestimmt den Testablauf, Ermittelt wird die Überdeckung, d.h. in welchem Grad werden Kontrollstrukturen korrekt ausgeführt, Unterschiedliche Arten
der Überdeckung z.B. : Anweisungsüberdeckung, Zweigüberdeckung, Pfadüberdeckung, Darstellung eines Programms als Kontrollflussgraph, Anweisungsüberdeckungstest (C0-Test) :,
Ausführung aller Anweisungen prüfen, Geringe Fehleridentifizierungsquote,
Zweigüberdeckungstest (C1-Test) :, Ausführung aller Zweige prüfen : fordert für Entscheidungen beide Wahrheitswerte, Mittlere Fehleridentifizierungsquote, Gilt als minimales
Testkriterium,
Pfadüberdeckungstest (C2-Test) :, Fordert die Ausführung aller unterschiedlichen Pfade eines Programms, Kaum praktikabel aufgrund der hohen Anzahl möglicher Pfade,
insbesondere durch die Wiederholung von Subpfaden in Schleifen, Vereinfachte Verfahren im Einsatz : Verzicht auf die wiederholte Auswertung von Subpfaden,
Bedingungsüberdeckungstest : Erforderlich bei komplexen Bedingungen, da dann Zweigüberdeckung nicht ausreichend aussagekräftig ,
Einfache Bedingungsüberdeckung :
Jede Bedingung muss mindestens einmal den Wert true und einmal zu false ergeben,
Mehrfach-Bedingungsüberdeckung : Auch die Kombinationen bei Mehrfach-Bedingungen berücksichtigen
Funktionale Testverfahren (1)
Ableitung der Testfälle aus der Programmspezifikation, Programmstruktur nicht sichtbar („Black Box“), Ziel : Bestimmung der „funktionalen Überdeckung“, Werden die spezifizierten
Funktionen korrekt ausgeführt ?, Testplanung : aus Programmspezifikation Testfälle möglichst vollständig herleiten, Funktionale Äquivalenzklassenbildung, Grenzwertanalyse, Test
spezieller Werte
, Zufallstest, Test von Zustandsautomaten
Äquivalenzklassen
Ziel der Äquivalenzklassenbildung ist es, Äquivalenzklassen zu bilden und so eine hohe Fehlerentdeckungsrate mit einer möglichst geringen Anzahl von Testfällen zu erreichen. Die
Äquivalenzklassen sind also bezüglich Ein- und Ausgabedaten ähnliche Klassen bzw. Objekte, bei denen erwartet wird, dass sie sich gleichartig verhalten. So sind beispielsweise in
einem Programm zur Verwaltung eines Fuhrparks Fahrzeuge äquivalente Klassen („Ferrari“ und „BMW“ sind vergleichbar, „Ferrari“ und „Mitarbeiter“ nicht).
Whiteboxtest
eine Methode des Software-Tests, bei der die Tests mit Kenntnissen über die innere Funktionsweise des zu testenden Systems entwickelt werden, Zeilenüberdeckung: Ausführung
aller Quellcode-Zeilen,Anweisungsüberdeckung : Ausführung aller Anweisungen
blackboxtest
bezeichnet eine Methode des Softwaretests, bei der die Tests ohne Kenntnisse über die innere Funktionsweise des zu testenden Systems entwickelt werden. Er beschränkt sich
auf funktionsorientiertes Testen, d. h. für die Ermittlung der Testfälle werden nur die Anforderungen, aber nicht die Implementierung des Testobjekts herangezogen. Nur nach außen
sichtbares Verhalten fließt in den Test ein.
Begriff „Software Life Cycle“ soll wie in Schritte der SoftwareEntwicklung Wasserfall-Modell (linear) Evolutionäres Modell (linear) Prototypen Modell (Nicht linear)
anderen 1.Analyse 2. Spezifikation der Anforderung Charaketristika Produktkern entworfen/implementiert -> Test vom Probleme von lin. Modellen:
(technischen) Disziplinen beschreiben, dass 3.Grobentwurf, Spezifikation der Module -Top Down , sequentiell Auftraggeber (ATG) Anforderungen könen nicht zu Beginn formuliert werden
- Software erfunden und geschaffen 4.Feinentwurf 5. Codierung und Modultest -Benutzerbeteiligung ATG -> erweitert Anforderungen für nächste version -> Anweder nur am anfang einbezogen
- genutzt 6. Integration, Test, Abnahme 7. Betrieb und Wartung - Einfach zu implementieren Struktur stark überarbeitet => repeat Lösungen nicht immer klar bzw durchführbar
- und außer Betrieb genommen wird Nachteile Charakter
4 Arten von Prototypen Vorteile alle Prototypen Strenge sequentielle Abfolge Produkt stufenweise entwickelt Alternative: Prototypen
Demonstrationsprototyp Frühzeitige Klärung von Problemen und Dokumentationsaufwand groß Pflegeaktivitäteten = neue version Sofware Prototyp vs Prototyp
• Durchführbarkeit demonstrieren Alternativen  Berücksichtigung von Rikisikofaktoren schwierig Codegetrieben ( konzentration auf teilprodukte) Unterschiede:
• Rapid prototyping Fördert Kommunikation Entwickler / Vorteile Software: kein Vorserienmuster, zeigt ausgewählte
• Nach Verwendung verwerfen Anwender  Iterative Entwicklung / Modell Benutzbar in kurzer Zeit Eigenschaften des Zielprodukts im prak. Einsatz
Prototyp i.e.S. Gut integrierbar in andere Entwicklung in geplanten kontrollierten Arbeitsschritte überschaubar Gemeinsam:
• Parallel zur Modellierung des Anwendungsbereichs Prozessmodelle Interrationsschritten Kombinierbar mit Prototypen Modell Anforderungen / Entwicklungsprobleme klären
• Aspekte der Benutzungsschnittstelle oder Teile der Nachteile Bei jeder Iteration: Ergebniss bewerten, Mängel Nachteile: Diskussionsbasis
Funktionalität veranschaulichen Zusätzlicher Aufwand (Werkzeuge / beseitgen , Verbessern Evo. Richtung nicht erkennbar zu Begin Entscheidungshilfe
• Anwendungsbereich analysieren Erstellung)  Tätigkeiten Analysieren, Entwerfen, Codieren, Umfangreich bei neuen Evo. Stufen Verwendung für experimentelle Zwecke
• Provisorisches, ablauffähiges Software-System Prototypen dürfen nicht das Produkt Testen bei jeder Iteration durchführen Kosten / Zeit/ Qualität nicht planbar Sammeln von prak erfahrungen
Labormuster ersetzen  
• Soll konstruktionsbezogene Fragen und Alternativen Prototypen dürfen nicht die Vermeidung der Nachteile im rein evolutionären Variante: V-Modell
beantworten Dokumentation ersetzen Modell :
Treppenmodell Überlappung der Bearbeitung Erweiterung Wasserfallmodell mit
• Demonstriert die technische Umsetzbarkeit des Anforderungen an das zu entwickelnde Produkt einzelner Ausbaustufen Qualitätsicherung
Produktmodells werden möglichst vollständig erfaßt und Phasenmodell : Wasserfallmodell mit definierten
Agile Modelle / XP Verifikation / Validation € V-Modell
• Nicht für Endbenutzer bestimmt modelliert Phasen und Meilensteinen
eXtreme Programming (XP) Veri: Überprüfung der Übereinstimmung
• Sollte technisch mit dem späteren Produkt vergleichbar Nur ein Teil der Anforderungen wird entworfen
5 Grundprinzipien: Cleanroom Development zwischen einem SoftwareProdukt und seiner
sein  unmittelbares Feedback
und implementiert V-Modell Spezifikation
Pilotsystem Anschließend wird die nächste Ausbaustufe Agile Modelle Spezielle evolutionäre /
Streben nach Einfachheit »Wird ein korrektes Produkt entwickelt?«
• Kern eines Produkts realisier
inkrementelle Weiterentwicklung inkrementelle Verfahren Vali: Eignung bzw. der Wert eines Produktes
• Prototyp = Endprodukt Vorteile:
Änderungen willkommen heißen bezogen auf seinen Einsatzzweck
• Pilotsystem ist für die Benutzung in der Einsatzumgebung Kernsystem frühzeitig verfügbar und bewertbar
Qualitätsarbeit leisten  Cleanroom Development »Wird das richtige Produkt entwickelt?«
entworfen und nicht nur unter Laborbedingungen Schwachstellen können frühzeitig erkannt und Hohe Anforderunge an Spezifikation / Design/
12 Praktiken für 3 Bereiche der
behoben werden Implementierung => Fehler vermeiden
Entwicklung:
Kurze Entwicklungszeiten je Inkrement, Umfassend :  Projektmanagement 
Agile Modelle Projektzyklus /Aufdecken Softwareentwicklung  Qualitätsmanagement 
„bewegliche Entwicklung“ Fehlerbeseitigungskosten geringer Gestestet: Teilsysteme , keine
Entwicklungszyklus Konfigurationsmanagement
Unterstützende Praktiken Einzelkomponenten Darin :  Festlegung von Produkten  Festlegung
4 Werte Der Entwicklungszyklus Benötigt frühzeitige vollständige Planung von Aktivitäten  Festlegung von Rollen
Konzentration auf Individuen und deren Der Projektzyklus Einfaches Design
Zusammenarbeit Beim Kunden vor Ort • einfachste Entwicklung der aktuellen Funktionalität  Unterstützende Praktiken
Vorteile 
• "Einzelpersonen und Interaktion sind uns Kurze Inkremente • kein 'vorausschauendes Design' Gemeinsame Verantwortlichkeit = der Code 'gehört'
Gut geeignet für große Projekte 
wichtiger als Prozesse und Werkzeuge" Planungsspiel Programmieren in Paaren allen Entwicklern = jeder veranwortlich
Integriert verschiedene Aspekte (PM, SWE, QM,
frühzeitig lauffähige Software • Priorisierung Anwendungsfälle mit • grundsätzlich 2er-Teams Programmierstandards • einheitliche Konventionen
Kunden KM) 
• "Laufende Systeme sind uns wichtiger als • statt nachträglicher Inspektionen oder Reviews Fortlaufende Integration • getesteter neuer Code wird
• Aufwandsschätzung Möglichkeit der Anpassung (Tailoring)
umfangreiche Dokumentation" Entwicklertests in das Gesamtsystem integriert
Abnahmetests • Tests schreiben bevor der Code geschrieben wird Metapher (Redefigur) • Symbolisierung des Systems Nachteil: Für kleine und mittlere Projekte zu
Einbindung des Kunden
• "Zusammenarbeit mit dem Kunden ist uns • Festlegung durch den Anwender • automatische Tests Nachhaltiges Tempo • angemessene Arbeitszeit - keine bürokratisch
wichtiger als Vertragsverhandlungen" Refactoring Stressphasen
Änderungsfreudigkeit statt Planungsverfolgung Scrum-Prozess:  Agile Modelle / Scrum
• Design-Vereinfachungen sofort durchgeführt Einflußfaktoren
• "Die Fähigkeit, auf Änderungen zu reagieren, ist Initialer Anforderungsworkshop Scrum – gedränge Dokumente Entwicklungsprozesse
uns wichtiger als das Verfolgen eines Plans„ => Product Backlog  Zum Management von Product Backlog = Anforderungen ; Aufgaben, prioritisiert nach Schätzungen =! Produktionsprozesse (Ansätze zur
Product Backlog Entwicklungsprozessen Sprint Backlog = Anforderungen Umgesetzt im Sprint, Täglich aktualisiert Verbesserung sind anders)
Kein reguläres Anforderungsmanagement Sprint-Planung => Sprint-Backlog Rollenbasiert Sprint Burndown Report = Aufwandskontrolle (aktueller Aufwand, Restaufwand vom Kreative Kontruktionsprozesse
keine Kostenplanung möglich Release-Planung  Interativer Prozess / Inkrementelle Sprint) (frühzeitige erkennent von Problemen) (Meistens als Chart) Fähigkeiten der Individuen entscheidend
Nicht für große Projekte geeignet Sprint Entwicklung ("Sprint") Release Plan = Welche Sprints, Aktualisiert nach Sprints. Produktqualität wird bestimmt durch
Erfordert leistungsfähiges Projektmanagement Max. 30 Tage Selbstorganisiertes Team Release Burndown Report = Aufwandskontrolle insgesamt von mehreren Sprints => Prozessqualität
Frühzeitig Auseinanderlaufen von Soll- und Ist- "Daily Scrum" Endziel im Auge betrachten Technologien + Werkzeuge zur Entwicklung
Aufwand erkennen Sprint Burndown
Fähigkeiten der Beteiligten
Review & Retrospektive Softwareentwicklungsprozesse (Prozesse) Verbesserungsprozess Bereitstellung ausreichender
Rollen: Budget /Kosten
Produktinkrement Komplex Eigenschaften quantifizieren Ressourcen zwingend Zeit / Planung
Produkt Owner
Aktualisierung Product Backlog Vielzahl einzelner Aktivitäten (messen) erforderlich
Repräsentiert Auftraggeber
Prozessverbesserung (steigerung Qualität, defektrate) Prozess analysieren Ressourcen häufig ungenügend Ablauf der Prozessverbesserung
Kennt Anforderungen
Bedeutung von Einflußfaktoren abhängig Prozess ändern => Qualität wird geopfert vor (Bild aus swe_prozessverbesserung.000.pdf
Führt Product Backlog
von der Projektgröße Eigenschaften Prozessen: Beginn Seite 9)
Legt Anforderungen für Sprint fest
Beurteilt Umsetzungen Probleme Großes Projekt: Understandability (definierung verständlich?) CMM/CMMI : Framework zur
Integration Visibility (Sind Ergebnisse eindeutig sodaß Prozess ersichtlich?) Prozessverbesserung (1)
Klassendiagramm :
Scrum Team: Projektmanagement Supportability (Sind CASE Tools benutzbar zur Unterstützung v. Prozess?) CMM(I) : Capability Maturity Model
Klassendiagramme stellen die
Kein leiter Kommunikation Acceptability (Ist Prozess akzeptierbar und Benutzbar vom veranwortlichen Engineer?) (Integration)
Reliability (Ist Prozess fehlerlos oder fehlerbehaftet bevor Entwicklung Produkts?) statische Struktur eines Systems
Selbsorganisiert -> Zusammenarbeit Laufzeit (mehrere Jahre) CMM: Modellierung der Reife der Fähigkeiten
Robustness (Kann Prozess weiterlaufen wenn Fehler auftritt?) dar. Sie zeigen die Klassen, die
Ständig wechselndes Personal => Prozess von Prozessen / Organisationen
Eigenschaften der Klassen
Scrum Master: bestimmt Qualität Maintainbility (Kann Prozess sich entwickeln bei änderlichen Anforderungen / CMMI Weiterentwicklung von CMM
Verbesserung?) (Attribute), das Verhalten
Unterstützt Team und Owner (intergriert)
(Operationen) der Klassen und
Überwacht Regeln , beseitigt Hindernisse Probleme kleines Projekt: Rapidity (Wie Schnell kann Prozess Ergebniss liefern)
die Beziehungen zwischen den
Organisiert Daily Scrums, Aktualisiert Qualität der Entwickler entscheidend Darstellungen :
Objektdiagramm: Klassen.Sie sind der zentrale
Dokumente Stufenförmige Darstellung(staged)
Objektdiagramme werden eingesetzt um einen Diagrammtyp der UML und
WIchtigstige Rolle, Projekterfolg abhängig (Bewertung Reife durch Stufen 1-5)
Was kann man tun? Schnappschuss eines Systems zur Laufzeit werden in allen Phasen der
Kontunierliche Darstellung
• man muss bereit sein, Zeit und Geld zu investieren => in Phase 2 tun darzustellen. Es werden die zur Laufzeit Softwareentwicklung
CMMI : Staged Version Stufen: (Detailliertere Klassifikation der Fähigkeiten
• Refactoring: existierenden Objekte, Attribute und eingesetzt.
Probleme in Stufe 1 : einzelner Prozessgebiete)
XP (Extreme Programming) Beziehungen angegeben.
Ungenügende Projektsteuerung
Unklare und / oder wechselnde Innere Struktur erneuern ohne die Schnittstellen nach außen zu ändern
Komponentendiagramm Paketdiagramm
Anforderungen in vielen kleinen Schritten durchführen, nicht zu viele Änderungen auf Eine Komponente ist laut UML-Spezifikation eine austauschbare Pakete werden verwendet um Mengen von Modellelementen zu
Unvollständige, unrealistische Planung einmal ◦ modulare Einheit eines Software-Systems mit definierten Gruppen zusammenzufassen. Sie dienen der Strukturierung von UML-
Starke Abhängigkeit von einzelnen zu jedem Schritt passende Tests entwickeln und durchführen Schnittstellen. Eine Komponente kann Schnittstellen anbieten, bzw. Modellen in überschaubare Einheiten. Pakete definieren einen
Mitarbeitern  Redesign: Innere + äußere Gestaltung ändern => beim Produkthöhepunkt erfordern. Eine Komponente ist innerhalb eines Modells austauschbar. Namensraum. Paketdiagramme stellen die Pakete und die
Übergang zu Stufe 2 : (Phase 2) angehen! Der interne Aufbau einer Komponente ist verborgen. Beziehungen (Abhängigkeiten) zwischen den Paketen eines Modells
Etablieren der wesentlichen Zu beachten ist der "Second - System- Effect": Komponentendiagramme geben Auskunft darüber aus welchen dar.
Managementprozesse • man will alles besser machen! Komponenten ein System besteht, welche Schnittstellen die
Übergang zu Stufe 3 : Aktivitätsdiagramm
• man will viele neue Features einbauen (evlt auslassbar diese passagen) Komponenten bereritstellen und erfordern und wie die Teile eines Aktivitätsdiagramme sind Diagramme zur Flussmodellierung. Sie
Einheitliche Prozesse für die gesamte • man will rückwärtskompatibel bleiben. Systems zusammenarbeiten.Eine Komponente setzt sich intern
Organisation einführen  stellen die Aktivitäten eines Systems dar, die Aktionen, aus den die
Das "2." System wird dann von vorneherein mit Anforderungen meistens aus mehreren Klassen zusammen.
Übergang zu Stufe 4 : Aktivitäten sich zusammensetzen und den Fluss durch die Aktivitäten.
überfrachtet, wird dann zu groß, zu teuer, u schlecht. Es kann Kontrollfluss und Datenfluss modelliert werden. Mit
Nutzung von Metriken und Kennzahlen zur
gezielten Prozessverbesserung  Aktivitätsdiagrammen können komplexe Abläufe in einem System
Kommunikationsdiagramm modelliert werden (Geschäftsprozesse, Workflows). Da Aktivitäten aus
In Stufe 5 :
In Kommunikationsdiagrammen wird die Interaktion zwischen Aktionen und deren zeitlicher Verknüpfung bestehen, können sie auch
Kontinuierliche Verbesserung aufgrund
Objekten dargestellt. Sie geben die Beziehungen zwischen den zur Modellierung der internen Logik komplexer Operationen
systematischer Analysen Objekten an und die Nachrichten, die übertragen werden. Sie verwendet werden und somit Algorithmen visualisieren.
können alternativ zu Sequenzdiagrammen verwendet werden. Aktivitätsdiagramme können in Verantwortungsbereiche gegliedert
Software-Lebenszyklus Dabei steht der Überblick der Kommunikationsstruktur im werden. Damit können die Aktionen bestimmten Modellelementen,
Software-Alterung / Software-Fäulnis • Vordergrund. Die Darstellung der zeitlichen Reihenfolge, in der wie Klassen oder Komponenten zugeordnet werden.
3 Phasen die Nachrichten gesendet werden, kann durch eine
1. Entwicklung & Etablierung Nummerierung vorgenommen werden.
Use-Case
2. Expansion & Diversifizierung => viele In Use Case Diagrammen wird das externe Systemverhalten aus
Änderungen! Anwendersicht beschrieben. Use Case Diagramme stellen das geplante
3. Alterung & Degeneration System, die Akteure, die Verwendung des geplanten Systems
Detailprobleme: ◦ (Anwendungsfälle) und die Beziehungen zwischen Akteuren und
Verweilzeit der Entwickler: Anwendungsfällen dar. Use Case Diagramme geben Auskunft darüber,
3 Jahre in einem "Job" (USA) was ein geplantes System aus Sichtweise der Benutzer leisten soll.
(
Zustandsdiagramm
10 Jahre Produktzyklus => bis zu 4 Entw.gen.
Zustandsautomaten (state machines) sind Diagramme zur Spezifikation
somit: Verlust an implizitem Wissen
des Verhaltens von Classifiern (Elementen). Cassifier können sein:
Notiz: (Vllt alles zusamenfassten als Verlust an Klassen, Komponenten, Systeme, u. a..
impl. Wissen da lebenszyklus lang)) Zustandsautomaten beschreiben das Verhalten der Elemente während
bei längerem Produktzyklus: ihres Lebenszyklus durch Darstellung der möglichen Zustände und
Verschmelzen mit anderen Produkten Zustandsübergänge. Die UML 2.0 unterscheidet behavioral state
gravierende (interne) Änderungen machines, die Verhalten von Instanzen einer Klasse, Systemen oder
Kompabilität zu bisher nicht unterstützen Systemteilen beschreiben, und protocol state machines, die
Schnittstellen. Protokolle, die von einemSystemelement realisiert werden,
modellieren. Zustandsautomaten werden häufig zur Darstellung des
Software-Degeneration Lebenszyklus von Objekten benutzt
• weitere interne Schnittstellen:
◦ als Wrapper um bereits bestehende Schnittstellen
Sequenzdiagramm
◦ zur Kaschierung von Fehlern
Sequenzdiagramme beschreiben die Kommunikation zwischen
◦ zur "Vereinfachung" der Nutzung
Objekten in einer bestimmten Szene. Es wird beschrieben welche
◦ zur (angeblichen) Vermeidung von doppelten Code. Objekte an der Szene beteiligt sind, welche Informationen (Nachrich-
Kaschieren statt Reparieren ten) sie austauschen und in welcher zeitlichen Reihenfolge der
• mangelndes Verständnis für die innere Qualität von Software Informationsaustausch stattfindet. Sequenzdiagramme enthalten eine
-> es werden nur außen beobachtbare Q-Kriterien verwendet implizite Zeitachse. Die Zeit schreitet in einem Diagramm von oben
• Zeitdruck nach unten fort. Die Reihenfolge der Pfeile in einem Sequenzdiagramm
->einfache" Lösung statt korrekter/gründlicher Lösung. gibt die zeitliche Reihenfolge der Nachrichten an
"Rückwärtskompatibilität"
• bei Entwickler: eher nicht, lieber neue Sachen entwickeln
• Marketing: keine Kunden verlieren, es ergeben sich Anforderungen, die neuen Entwicklungen entgegen stehen