Requirements Engineering

Größe: px
Ab Seite anzeigen:

Download "Requirements Engineering"

Transkript

1 Software Engineering Projekt WS03/04 Requirements Engineering Leitung: Stephan Herrmann Ausarbeitung: Elena Martel

2 Inhaltsverzeichnis 1 Motivation Definitionen und Grundbegriffe Requirements Engineering Prozess Tätigkeiten Domänenanalyse Ist-Analyse Zielanalyse Task-Analyse Rollen Anforderungsanalyse Gewinnung von Anforderungen Definition von Anforderungen Klassifikation von Anforderungen Spezifikation von Anforderungen Ausgewählte Spezifikationsnotationen Vor- und Nachteile formaler und informaler Notationen Prüfung von Anforderungen Viewpoints Pflichtenheft Eigenschaften eines Pflichtenheftes Normen eines Pflichtenheftes Validierung und Verifikation (V&V) eines Pflichtenheftes Schlussfolgerung Abbildungsverzeichnis Literaturverzeichnis Internetquellen:

3 1 Motivation Die Kriterien Softwarequalität und Kundenzufriedenheit sind oft für den Erfolg eines Unternehmens ausschlaggebend. Je höher die Softwarequalität ist, desto geringer können die Wartungskosten für ein Produkt gehalten werden. Um auch noch ein hohes Maß an Kundenzufriedenheit zu errechnen, müssen Anforderungen, Erwartungen und Wünsche der Kunden erfüllt werden. Der Softwareentwicklungsprozess kann nur dann erfolgreich verlaufen, wenn am Anfang die Anforderungen an das Endprodukt in eindeutiger Form vorliegen. Somit ist dies die Zielsetzung und Aufgabe von Requirements Engineering: ausgehend von einer (vagen) Problemvorstellung oder einer gegebenen Aufgabenstellung, Anforderungen an das zu entwickelnde System, das sog. Zielsystem, zu erheben und eine Spezifikation zu erstellen. Es soll durch eine inhaltlich umfangreiche und eindeutige Beschreibung eines gewünschten Produktes erreicht werden, dass das Produkt am Ende den Wünschen entspricht. Die Requirements- Engineering- Phase gilt als die wichtigste Phase in der Software-Entwicklung überhaupt. Welchen Nutzen hat es, ein nach Informatik-Gesichtspunkten perfektes System zu entwickeln, wenn es nicht das System ist, das die Kunden wünschen? 2 Definitionen und Grundbegriffe Am Anfang einige wichtige Definitionen und Grundbegriffe: Die erste Definition ist stets eine mehr technische, welche sich an die Definition von Software Engineering in IEEE anlehnt und die zweite, eine mehr menschenorientierte. Requirements Engineering (Anforderungstechnik): 1.Das systematische, disziplinierte und quantitativ erfassbare Vorgehen beim Spezifizieren, d.h. Erfassen, Beschreiben und Prüfen von Anforderungen an Software. 2.Verstehen und Beschreiben, was die Kunden wünschen oder brauchen. Requirements(Anforderung): 1.Eine Bedingung oder Fähigkeit, die eine Software erfüllen oder besitzen muss, um einen Vertrag, eine Norm oder ein anderes, formell bestimmtes Dokument zu erfüllen. (IEEE ). 2. Eine Bedingung oder Fähigkeit, die von einer Person zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird. Im folgenden gilt, dass alle Aussagen, die Wünsche der Kunden und sonstiger Personen (siehe Kapitel 4) oder die zu realisierenden Aspekte des Zielsystems betreffen, als Anforderungen bezeichnet werden. 3

4 3 Requirements Engineering Prozess Wie schon oben erwähnt, gilt die Requirements Engineering- Phase als die wichtigste Phase in der Software-Entwicklung überhaupt. Aus der Abbildung 1, die den gesamten Prozess der Software Engineering wiederspiegelt, kann man deutlich erkennen, dass der Prozess von Requirements Engineering in den früheren Phasen des Software Engineering Prozesses stattfindet. Die bedeutendste Aufgabe der Requirements Engineering Phase ist die Ermittlung von Anforderungen, als weitere Aufgabe kann die Systemmodellierungsphase gesehen werden, die als Übergangsphase zur Entwurfsphase gilt. Analyse Entwurf Implementierung Test Wartung Anforderungsermittlung Systemsmodellierung Abbildung 1. Software Engineering Prozess - Phasen Aber nicht nur das zu erstellende Produkt ist wichtig, sondern auch der Prozess der Erstellung selbst. Im Zuge des Requirements Engineering Prozesses sollten mindestens folgende Punkte unterstützt werden: Problemanalyse Durchführbarkeitsstudie Anforderungsanalyse Von besonderer Bedeutung ist, dass das schrittweise Vorgehen für einen Requirements- Engineering- Prozess vorausgesetzt wird. Ziel der Problemanalysephase ist es, die Anforderungen und Rahmenbedingungen aus Sicht der Kunden zu erfassen. Es dürfen durchaus noch Inkonsistenzen und Vagheiten vorhanden sein, die dann in der Anforderungsanalyse-Phase beseitig werden sollen. Am Ende dieser Phase entsteht ein Dokument als Hauptergebnis: das Problemanalysedokument oder Lastenheft. Bei der Durchführbarkeitsstudie bzw. Machbarkeitsstudie stellt man sich primär die Frage, ob die vorliegenden Ziele mit der verfügbaren Technologie erreicht werden können. Dies erfolgt unter der Auflage, dass die Budgetkosten nicht überschritten werden. Auf die Anforderungsanalyse-Phase wird in den weiteren Kapiteln präziser eingegangen. 4

5 3.1 Tätigkeiten Neben den bisher beschriebenen Tätigkeiten des Requirements Engineering Prozesses kann es, je nach Projekt, sinnvoll sein, weitere Tätigkeiten durchzuführen. Im folgenden werden die Tätigkeiten Domänenanalyse, Ist-Analyse, Zielanalyse und Task- Analyse kurz vorgestellt Domänenanalyse Häufig ist es sinnvoll, nicht nur die Anforderungen für ein spezielles Zielsystem zu sammeln, sondern darüber hinaus auch anwendungsbereichspezifisches Wissen. Das Sammeln und Modellieren von Anforderungen für einen Anwendungsbereich wird Domänenanalyse genannt. Die Domänenanalyse liefert ein Domänenmodell, das für alle (bzw. viele) Systeme aus dem Anwendungsbereich Gültigkeit haben soll. Ein Domänenmodell enthält typischerweise Daten und generische Anforderungen, die für konkrete Systeme vervollständigt oder angepasst werden müssen. Das Domänenmodell kann als Referenzwissen und Ausgangsbasis für die Diskussion über neue Systeme aus dem gleichen Anwendungsbereich benutzt werden. Durch das Domänenmodell wird eine gemeinsame Basis geschaffen, durch die die Kommunikation zwischen verschiedenen Personen mit unterschiedlichem Kenntnisstand über den Anwendungsbereich erleichtert werden kann Ist-Analyse In den meisten Fällen soll durch ein Projekt der Softwareentwicklung eine Verbesserung des aktuellen Zustands erreicht werden: Manuelle Tätigkeiten sollen automatisiert werden. Ein schon vorhandenes System soll ersetzt oder erweitert werden. Werden Informanten(sieh Kapitel 4) nach ihren Anforderungen befragt, so treffen sie oft Aussagen der Art so wie bisher, aber.... Damit diese Aussagen richtig verstanden werden können, muss die aktuelle Situation bekannt sein. Die Tätigkeit, in der die aktuelle Situation(Ist-Zustand) in einem Unternehmen analysiert wird, wird Ist-Analyse genannt. Zur Beschreibung des Ist-Zustands gehören Aussagen über die aktuelle Arbeitsumgebung inkl. eines evtl. vorhandenen zu ersetzenden Systems, über die Arbeitsabläufe und die daran beteiligten Personen (bzw. deren Rollen(sieh Kapitel 4)) und über vorhandene Probleme. Im einzelnen sind im Rahmen der Ist-Analyse beispielsweise folgende Punkte relevant: Erfassen der Anwender-/Nutzerumwelt (Aufbau- und Ablauforganisation, Dienstvorschriften, Erlasse, Gesetze, Richtlinien und ähnliches mehr) Aufnehmen existierender Datenbestände, Programme Erfassen der vorhandenen IT- Ausrüstung Erfassen von Zeit- und Mengengerüst (derzeitige Bearbeitungszeiten, Durchlaufzeiten, Antwortzeiten, Wartezeiten, Datenmengen) Erfassen nicht beeinflussbarer fachlicher und technischer Faktoren Darstellen der Bedrohung und der Ausrüstungslücke, Feststellen von Schwachstellen Ermitteln der Ursachen der festgestellten Schwachstellen 5

6 3.1.3 Zielanalyse In der Requirements Engineering- Phase werden häufig falsche Annahmen getroffen bzgl. der Politik des Managements, Misstrauen und Widerstand gegen neue Systeme, eingeführter und bewährter Praktiken usw. In der Zielanalyse sollen die langfristigen Ziele einer Firma ermittelt werden, sowie die Bedingungen, die ein Erreichen der Ziele unterstützen oder behindern können, um möglichst früh Konflikte zu erkennen Task-Analyse In der Task-Analyse wird untersucht, wie das Zielsystem in die Arbeitsumgebung eingebettet werden soll. Folglich die Fragen beantworten: Welche Teile der zur Lösung des übergeordneten Problems notwendigen Arbeitsabläufe soll das Zielsystem übernehmen? Inwieweit dürfen die bisherigen Arbeitsabläufe durch das neue System geändert werden? Hierbei wird das Zielsystem nur als eine Komponente von vielen betrachtet. 6

7 4 Rollen An den Requirements- Engineering- Tätigkeiten sind in der Regel viele verschiedene Personen beteiligt. Eine wichtige Position nehmen die Systemanalytiker ein. Sie führen die Tätigkeiten selbst durch oder sorgen dafür, dass sie durchgeführt werden. Es ist ihre Aufgabe, Dokumente zu erstellen und zu pflegen. Die Anforderungen und sonstigen Informationen, die in das Pflichtenheft(sieh Kapitel 6) eingetragen werden sollen, sind keine Erfindungen der Systemanalytiker, sondern müssen erhoben werden. Alle Personen, die von dem Zielsystem positiv oder negativ betroffen sein können und alle Personen und Dokumente, die für die Entwicklung und den Gebrauch des Zielsystems relevante Informationen liefern können, sind potentielle Informationsquellen. Die Personen- Informationsquellen werden auch Stakeholder oder Informanten genannt. Bei Informanten sollte zwischen Personen und Rollen unterschieden werden. Wenn eine Anforderung von Peter Müller kommt, dann ist einerseits die konkrete Person von Interesse, andererseits aber auch die Rolle, die Peter Müller in dem Requirements Engineering- Prozess einnimmt, z.b. Benutzer des Zielsystems, Experte des Anwendungsbereichs oder Auftraggeber, der das Projekt finanziert. Zwei Informanten nehmen die gleiche Rolle ein, wenn sie für das Projekt ähnliche Informationen liefern können, eine ähnliche Sichtweise vertreten oder über ähnliche Befugnisse verfügen. Die Menge aller Informanten, die gleiche Rolle einnehmen, wird Partei genannt. Abbildung 2 gibt einen Überblick über typische Parteien in einem Requirements Engineering- Prozess. Abbildung 2. Typische Parteien in einem Software Projekt Wenn im Projektverlauf eine konkrete Person nicht mehr zur Verfügung steht, kann die Parteizugehörigkeit verwendet werden, um einen Ersatzansprechpartner zu ermitteln, der voraussichtlich ähnliche Informationen liefern kann. 7

8 In jedem Projekt gibt es Kunden und Entwickler. Die Kunden sind diejenigen, die Bedarf für ein neues oder geändertes System haben. Die Entwickler sind diejenigen, die das neue System realisieren sollen. Kunden und Entwickler können durchaus dieselben Personen sein. Darüber hinaus können sonstige Informanten, z.b. Rechtsexperten, Sicherheitsexperten oder Mitarbeiter von Behörden, Versicherungen oder Zertifizierungsstellen, für die Requirements- Engineering- Tätigkeiten relevant sein. In vielen Projekten können die Kunden unterteilt werden in Auftraggeber und Benutzer. Auftraggeber sind die Personen, mit denen der Vertrag geschlossen wird. Sie legen die Rahmenbedingungen fest und sind befugt, in Zweifelsfällen Entscheidungen zu treffen. Benutzer sind diejenigen, die später mit dem Zielsystem arbeiten werden. Das können»normale Anwender«sein ebenso wie Operateure oder Wartungspersonal. Auch die Entwickler können bei größeren Softwareprojekten weiter unterteilt werden, z.b. in Entwerfer, Codierer, GUI- Spezialist und Tester. Die Systemanalytiker nehmen eine zentrale Position im Projekt ein (Abbildung 3). Abbildung 3. Zentrale Rolle der Systemanalytiker Sie kommunizieren mit den Informanten, um Anforderungen zu ermitteln oder Entscheidungen zu treffen. Sie nehmen außerdem eine Vermittlerrolle ein. Wenn sie auf Widersprüche stoßen, müssen sie deren Lösung initiieren. In der Regel dürfen sie aber die Entscheidung, wie der Widerspruch zu lösen ist, nicht selbständig treffen. 8

9 5 Anforderungsanalyse Die Anforderungsanalyse Phase lässt sich wie folgend unterteilen: Anforderungen gewinnen Anforderungen definieren Anforderungen spezifizieren Anforderungen prüfen Anforderungen dokumentieren Bei der Anforderungsgewinnung erörtert man sämtliche Anforderungen an das System, wobei spezielles Augenmerk auf die Anforderungen gelegt wird, welche von den Stakeholdern(siehe Kapitel 4) an das System gestellt werden. Bei der Anforderungsdefinition geht man auf die endgültigen Anforderungen ein, und versucht diese in eine allgemeinverständliche Form zu bringen, sodass auch eventuelle Kunden keine Probleme mit der Verständlichkeit haben. Bei der Anforderungsspezifikation versucht man mit Hilfe einer ausgewählten Spezifikationsnotation(sieh Kapitel 5.4.1) Anforderungen darzustellen, um sie anschließend zu prüfen und in jedem Fall zu dokumentieren, was zu der Erstellung eines Pflichtenheftes(sieh Kapitel 6) führt. Die graphische Darstellung der Anforderungsanalyse - Phasen ist in der Abbildung 4 dargestellt. Anforderungen gewinnen Anforderungen definieren Anforderungen spezifizieren Anforderungen prüfen Anforderungen dokumentieren => Pflichtenheft Abbildung 4. Anforderungsanalyse - Phasen 9

10 An dieser Stelle ist zu beachten, dass es während der Anforderungsprüfungs- Phase auf die oberen drei Phasen (Anforderungsgewinnung, Anforderungsdefinition und Anforderungsspezifikation) zurückgegangen werden kann, falls das nötig ist. Zum Beispiel, wenn bei der Prüfung der Anforderungen festgestellt wurde, dass einige Anforderungen fehlen, müssen sie neu von den Informanten gewonnen werden, also muss man zu der Anforderungsgewinnungs- Phase zurückkehren, danach werden die neu gewonnenen Anforderungen definiert und spezifiziert, und anschließend wieder geprüft. Oder wenn bei einigen schon bestehenden Anforderungen in der Anforderungsprüfungs- Phase das Bedürfnis an einer besseren Definition oder Spezifikation der Anforderungen besteht, dann kann auf die anderen zwei Phasen (Anforderungsdefinition, Anforderungsspezifikation) zurückgegangen werden. 5.1 Gewinnung von Anforderungen Es stellt sich das Problem, dass bei der Gewinnung von Anforderungen meist folgende Schwierigkeiten auftreten: Unterschiedliche Vertreter des Kunden haben unterschiedliche Vorstellungen über das zu spezifizierende System. Häufig sind schon die Auffassungen und die Begriffsbildung im Anwendungsbereich nicht einheitlich. Requirements Engineering beinhaltet daher auch Konsensbildung zwischen divergierenden Vorstellungen der beteiligten Personen. Die Kundenvertreter haben zwar eine Vorstellung, was sie wollen, aber sie können ihre Vorstellung nicht formulieren. Manchmal,,lösen sie dieses Problem, indem sie anstelle ihrer eigentlichen Anforderungen bestehende Lösungen mit vergleichbaren Eigenschaften beschreiben. Die Kundenvertreter wissen nicht oder nur sehr vage, was sie eigentlich wollen. Es gibt unter anderem Fälle, wo Kundenvertreter sich noch gar keine Gedanken über das zu entwickelnde Zielsystem gemacht haben. Am Ende des Projektes, wo das Produkt schon fertig ist, stellen sie plötzlich fest, dass es gar nicht ihren Vorstellungen entspricht. Diese Probleme führen dazu, dass die Kunden in den Prozess immer einbezogen werden müssen. Es haben sich folgende vier Vorgehensweisen als mögliche Techniken zur erfolgreichen Anforderungsgewinnung entwickelt. Je nach Situation wird eine einzelne Technik oder eine Kombination von Techniken gewählt. Begriffe klären und ein Glossar mit Definitionen der wichtigen Begriffe des Anwendungsbereichs erstellen. Damit wird eine begriffliche Grundlage geschaffen, die sicherstellt, dass alle das Gleiche meinen, wenn sie vom Gleichen reden. Ein solches Glossar ist insbesondere dann wichtig, wenn schon die Kundenvertreter untereinander keine klare und einheitliche Begriffswelt haben. Soll- Prozessabläufe untersuchen. Feststellen, welche äußeren Ereignisse auf das zu spezifizierende System einwirken können und erfragen, wie das System auf welches dieser Ereignisse reagieren soll. Anwendungsszenarien bilden und durchspielen. Alle Interaktionen der Umgebung (seien dies Menschen oder Sensoren) mit dem zu spezifizierenden System werden in Form von Szenarien aufgeschrieben und durchgespielt. Szenarien eignen sich besonders gut zur interaktiven Gewinnung und Diskussion von Anforderungen mit den Kunden. Es ist außerdem hilfreich, den Kunden bei seiner Arbeit mit dem System zu beobachten, 10

11 falls das System verbessert werden soll. Das hilft festzustellen, welche Aktionen besonders oft benutzt werden. Auch die Arbeitsweise der Kunden verrät viele wichtige Informationen, die für die Entwickler bei der Weiterentwicklung oder Verbesserung des Zielsystems sehr wichtig sein können. Den Anwendungsbereich modellieren. Feststellen, welche Gegenstände der Anwendung für das zu spezifizierende System relevant sind. (Relevant sind diejenigen Gegenstände, über die das System Information speichern muss, damit es seine Aufgaben erfüllen kann.) Herausfinden, welche Eigenschaften der relevanten Gegenstände und welche Beziehungen der Gegenstände untereinander dem zu spezifizierenden System bekannt sein müssen. Um die gewünschten Informationen von den Vertretern des Kunden zu erhalten, können verschiedene Mittel eingesetzt werden. Mit folgenden Mitteln können oben erwähnte Techniken erfolgreich eingesetzt werden: In Interviews werden die Vertreter des Kunden einzeln oder in Gruppen zu höchstens drei Leuten befragt. Mit Fragebögen können Begriffswelt und Bedürfnisse einer größeren Gruppe von Kundenvertretern erfasst werden. In gemeinsamen Arbeitstagungen (manchmal auch Joint Application Development- Sitzungen genannt) kann eine Gruppe ausgewählter Kundenvertreter und Informatiker gemeinsam die Anforderungen an ein geplantes System erarbeiten. Die Ergebnisse der Analyse werden mittels geeigneter Methoden und Notationen dargestellt und bilden dann die Anforderungsspezifikation. 5.2 Definition von Anforderungen Das größte Problem im Zuge der Anforderungsdefinition ist, wie bereits eingangs erwähnt, die Vermeidung von Mehrdeutigkeiten. Beispiele für Mehrdeutigkeiten sind folgende: Fehlende Anforderungen Mehrdeutige Wörter Fehlende Anforderungen liegen vor, sobald Grundvoraussetzungen nicht behandelt werden. Meist geschieht dies, wenn Personen von einer unterschiedlichen Wissensbasis ausgehen und deshalb Dinge als selbstverständlich angenommen werden. In der Folge werden diese Annahmen aber nicht von allen Gruppenmitgliedern geteilt. Aber selbst wenn Anforderungen klar dargelegt werden, kann deren Bedeutung nicht für alle gleich sein. Es ist immer von Bedeutung in welcher Relation Wörter und Begriffe verwendet werden. Es gibt Beispiele, in denen gezeigt wird, dass Missverständnisse und Mehrdeutigkeiten sogar in vermeintlich einfachen natürlichsprachlichen Aussagen enthalten sein können. Man betrachte folgenden einfachen, aus einem bekannten Kinderlied entnommenen Satz: Mary had a little lamb. Auf den ersten Blick scheint der Satz unmissverständlich zu sein. In (Gause, Weinberg, 1989, S. 94ff) versuchte man mittels folgender Techniken, mögliche unterschiedliche Bedeutungen herauszufinden: Technik 1: Durch Betonung einzelner Wörter kann der Sinn des Satzes variiert werden. Betont man das Wort had, so bedeutet der Satz wohl eher, dass Mary ein Lamm hatte, 11

12 aber nicht mehr hat. Betont man statt dessen little, so könnte der Satz bedeuten, dass das Lamm überraschend klein ist. Technik 2: Die einzelnen Wörter werden im Lexikon nachgeschlagen. Alle möglichen Bedeutungen werden miteinander kombiniert. Das Wort have hat in einigen Fällen die Bedeutung have dinner. Damit könnte der Satz auch bedeuten, dass Mary das Lamm gegessen hat. Problematisch hierbei ist, dass die Mehrdeutigkeiten nicht durch unbekannte Wörter verursacht werden, sondern im ersten Fall durch die Art und Weise, wie ein Satz gelesen wird, und im zweiten Fall durch eine eher selten verwendete Bedeutung des Wortes have. Es ist ziemlich unwahrscheinlich, dass das Wort have in dem Glossar definiert wird. Das oben genannte Beispiel ist speziell konstruiert worden, um das Problem der Mehrdeutigkeiten möglichst gut zu verdeutlichen. Es gibt aber auch reale Fälle, in denen geläufige Wörter mit spezieller Bedeutung verwendet werden. Zum Beispiel: Der Referent eines Vortrags, der über seine Tätigkeiten in einem Rechenzentrum berichtete, benutzte regelmäßig das Wort drucken. Erst gegen Ende des Vortrags stellte sich heraus, dass er mit drucken eigentlich formatieren meinte. Somit konnte auch ohne Drucker gedruckt werden, z.b. in eine Datei oder auf den Bildschirm. Wie bereits gezeigt, ist eine Möglichkeit, um Mehrdeutigen weitgehend zu vermeiden, dafür zu sorgen, dass alle beteiligten Personen eine Gesprächsbasis haben. Oft ist dies mit einer, die Problemstellung betreffenden, gemeinsamen Wissensbasis verbunden. Wichtig ist auch, dass die Gruppenmitglieder ein Bild der Anforderungen haben. Im Konkreten bedeutet dies, dass Einigkeit darüber existiert, was an Wünschen und Anforderungen besteht. Ein Weg dies zu erreichen, liegt im Definieren der Nicht-Anforderungen. Damit werden in vielen Fällen auch Mehrdeutigkeiten beseitigt, die aufgrund einer unterschiedlichen Ausgangslage zu Stande kommen. Die unterschiedliche Ausgangslage und Wissensbasis darf jedoch nicht als negativ gesehen werden. Ganz im Gegenteil, denn erst dadurch wird eine vielseitige und innovative Lösung der Problematik ermöglicht. Es ist in diesem Zusammenhang wichtig, dass sowohl die Entwickler als auch die tatsächlichen Anwender am Prozess beteiligt werden. Von Bedeutung ist es jedoch, die unterschiedlichen Personengruppen, die am Requirements Engineering beteiligt sind, durch Wissensaustausch und Methoden und Werkzeuge des Requirements Engineering zu koordinieren. Erst durch eine erfolgreiche Kombination kann das Endprodukt sowohl das Kriterium der Kundenzufriedenheit als auch ein gutes Maß an Softwarequalität erfüllen. 5.3 Klassifikation von Anforderungen Als eine Hilfestellung zu dem im oberen Kapitel erwähnten Problem der komplizierten Definition von Anforderungen kann die Klassifizierung der Anforderungen angesehen werden. Es gibt verschiedene Arten von Anforderungen. Zunächst einmal wird zwischen Projekt- und Produktanforderungen unterschieden. Die Produktanforderungen wiederum gliedern sich in funktionale Anforderungen und Attribute (Abbildung 5). 12

13 Unter funktionalen Anforderungen versteht man alle Anforderungen, die sich auf die Funktionalität eines Systems beziehen, also, welche Ergebnisse aufgrund welcher Eingaben zu berechnen und / oder zu liefern sind. Also durch funktionale Anforderungen wird das Verhalten des Zielsystems beschrieben. Die Attribute oder auch nicht-funktionale Anforderungen genannt, spezifizieren die Art und Weise, in der diese Funktionalität zu erbringen ist. Leistungsanforderungen sind Forderungen bezüglich Zeiten, Mengen, Geschwindigkeiten, Raten. Besondere Qualitätsanforderungen sind Forderungen beispielsweise an Zuverlässigkeit oder Benutzerfreundlichkeit. Randbedingungen schließlich sind alle Forderungen, welche die Menge der möglichen Lösungen zusätzlich beschränken, z.b. Gesetze und Normen. Anforderungen Projektanforderungen Produktanforderungen funktionale nicht-funktionale = Attribute Leistungsanforderungen Qualitätsanforderungen Randbedingungen Abbildung 5. Klassifikation von Anforderungen Zusätzlich müssen die Anforderungen oft nach ihrer Wichtigkeit klassifiziert werden, z.b. in Muss-Anforderungen: sind unverzichtbar und müssen in jedem Fall erfüllt werden Soll-Anforderungen: sollten erfüllt werden, sind aber bei zu hohen Kosten verzichtbar Wunsch-Anforderungen: werden nur erfüllt, wenn es mit vertretbaren Kosten möglich ist. Eine solche Klassifikation nach Wichtigkeit ist vor allem in zwei Situationen nötig: 1. wenn die Entwicklungskosten eine harte Randbedingung darstellen. Dies ist unter anderem dann der Fall, wenn Software für den Markt entwickelt wird. 2. wenn die Anforderungsspezifikation als Grundlage für die Beschaffung eines Systems dient, weil dann die Lösung nicht nach Maß auf die Bedürfnisse zugeschnitten werden kann. 13

14 Zum besseren Verständnis einige Beispiele aus einem Bibliotheksystem für unterschiedliche Arten von Anforderungen und ihre Kategorien. 1. Das System soll Datensätze für alle Arten von Bibliotheksbeständen einschließlich Bücher, Serien, Zeitungen und Magazinen, Video- und Audiobändern, Abschlußberichten, Projektionsfoliensammlungen, Computerdisketten und CD-Rom verwalten. Allgemeine Anforderung, breit gefasste Systembeschreibung 2. Das System soll dem Nutzer die Suche nach einem Leihobjekt durch die Angabe von Titel, Autor oder ISBN ermöglichen. Funktionale Anforderung, welche die Funktion eines Teils des Systems definiert, hier Suche nach einem Leihobjekt. 3. Das Nutzerinterface des Systems soll mittels eines WWW-Browser implementiert werden. Qualitätsanforderung, welche die Art der Implementation festlegt. 4. Das System soll mindestens 20 Transaktionen in der Sekunde verarbeiten. Performanceanforderung, welche das Minimum einer akzeptierbaren Performance spezifiziert. 5. Die dem Nutzer zugänglichen Dienste sollen nach maximal 10 Minuten verfügbar sein. Verfügbarkeitsanforderung, welche die maximal zur Bereitstellung der Dienste notwendige Zeit festlegt (oder auch Sicherheitsanforderung genannt, also nichtfunktionale Anforderung) 5.4 Spezifikation von Anforderungen Man stellt sich die Frage Wozu eine Anforderungsspezifikation erstellen?. Die Erstellung einer Anforderungsspezifikation kostet Geld, ohne dass diesem Aufwand ein unmittelbar sichtbarer Ertrag in Form von Programmen gegenübersteht. Das Spezifizieren von Anforderungen ist also nur dann wirtschaftlich, wenn dem dafür zu treibenden Aufwand entsprechende Einsparungen gegenüberstehen. Requirements Engineering, das systematische Spezifizieren von Anforderungen, hat daher das klare Ziel, Kosten zu senken. Dass dieses Ziel realistisch ist, zeigt folgende Überlegung: Fehlerkosten, d.h. die Kosten für die Lokalisierung und Behebung von Fehlern, machen einen wesentlichen Teil der Gesamtkosten einer Systementwicklung aus. Anforderungsfehler sind dabei die teuersten Fehler, weil sie beim Fehlen einer Anforderungsspezifikation typisch erst bei der Abnahme oder im Betrieb gefunden werden und die Fehlerkosten exponentiell mit der Verweildauer der Fehler im System wachsen (Abbildung 6). Wenn man Requirements Engineering vernünftig betreibt, sind die Einsparungen bei den Fehlerkosten höher als der dafür notwendige Aufwand. Das heißt, das Spezifizieren von Anforderungen ist wirtschaftlich (Abbildung 7). 14

15 Abbildung 6. Kostenanstieg der Fehlerbehebung Abbildung 7. Wirtschaftlichkeit der Anforderungsspezifikation Um die Fehlerkosten zu senken, muss man folglich erreichen, dass 1) wenig Anforderungsfehler gemacht werden und 2) möglichst viele der dennoch gemachten Fehler möglichst früh gefunden werden. Dafür braucht man sowohl eine gute Anforderungsspezifikation als auch einen guten Spezifikationsprozess. Eine gute Spezifikation zeichnet sich durch folgende Eigenschaften aus: Adäquatheit - das beschreiben, was der Kunde will bzw. braucht Vollständigkeit - alles beschreiben, was der Kunde will bzw. braucht Widerspruchsfreiheit - sonst ist die Spezifikation nicht realisierbar Verständlichkeit - für den Kunden und für die Informatiker Eindeutigkeit - damit Fehler durch Fehlinterpretationen vermieden werden Prüfbarkeit - damit feststellbar ist, ob das realisierte System die Anforderungen erfüllt. Ein guter Spezifikationsprozess ist charakterisiert durch: Kundenorientierung Methodisches und zielgerichtetes Vorgehen Verwendung geeigneter Mittel Integration von Erstellung und Prüfung von Anforderungen. 15

16 5.4.1 Ausgewählte Spezifikationsnotationen Es existieren viele unterschiedliche Spezifikationsnotationen. Eine Möglichkeit, Notationen zu klassifizieren, besteht darin, sie anhand ihres Formalisierungsgrads zu unterscheiden (Abbildung 8). Abbildung 8. Klassifikation von Spezifikationsnotationen anhand ihres Formalisierungsgrads Bei den formalen Spezifikationsnationen kann zwischen optional- ausführbar- formalen- und mathematisch-formalen- Notationen unterschieden werden. Bei den ersten bedeutet es, dass Syntax und Semantik der Notationen definiert sind und die Anforderungsspezifikation ausgeführt werden kann. Bei den mathematisch-formalen Notationen sind Syntax und Semantik auch definiert, aber die Anforderungsspezifikation nicht unbedingt ausgeführt werden kann. Weiterhin gibt es auch semi-formale Notationen, bei denen die Syntax vollständig, aber die zugehörige Semantik nur höchstens teilweise definiert sind. Und als letztes die informale Notationen, wo Syntax und Semantik nicht oder höchstens teilweise definiert sind. Im folgenden werden die wichtigsten Notationen für die Problemanalyse und Spezifikation vorgestellt. Natürliche Sprache ist eine der wichtigsten und am häufigsten verwendeten Spezifikationsnotationen. Hierbei handelt es sich um eine informale, textuelle Notation, die nur durch den Wortschatz und die Orthographie- und Grammatikregeln der jeweiligen Sprache (z.b. Deutsch) eingeschränkt wird. Sie ist universell, d.h. sie kann in jedem Anwendungsbereich eingesetzt werden. Mittels natürlicher Sprache kann jeder Sachverhalt beschrieben werden. Einige Sachverhalte wie z.b. der Aufbau eines komplexen Datums lassen sich jedoch nur umständlich durch sie beschreiben. 16

17 Um komplexe Datenstrukturen zu beschreiben, werden teils graphische Notationen(semi-formal), z.b. ER- Diagramme und Klassendiagramme, teils textuelle Notationen, z.b. kontextfreie Grammatiken oder die dazu sehr ähnlichen Backus- Naur-Formen verwendet. Mittels ER- und Klassendiagrammen können beliebig aufgebaute Datenstrukturen beschrieben werden. Sollen die Zustände und die möglichen Zustandsänderungen eines Systems beschrieben werden, so bieten sich endliche Automaten bzw. Zustandsübergangsdiagramme an. Sie zählen zu den operational- ausführbar-formalen Notationen. Formale Notationen, die auf mathematischen Konzepten wie z.b. der allgemeinen Mengenlehre, temporaler Logik oder Prädikatenlogik erster Stufe basieren. Eine der bekanntesten formalen Spezifikationsnotationen ist Z. Grundlage ist der mathematisch wohldefinierte Begriff der Menge. Aufbauend auf einige als gegeben vorausgesetzte Mengen können weitere Mengen definiert werden. Relationen und Funktionen werden ebenfalls als Mengen aufgefasst. Der Zustandsraum und das Verhalten des Zielsystems werden durch Schemata beschrieben. Ein Schema fasst Mengen, Vor- und Nachbedingungen und Invarianten zusammen. Wird nur eine bestimmte Teilmenge der umfangreichen Syntax benutzt, können Z-Modelle ausgeführt (animiert) werden. In vielen Requirements- Engineering- Methoden werden einige der Basis -Notationen kombiniert, um möglichst viele relevante Aspekte ausdrücken zu können. Meistens steht dabei eine Notation klar im Vordergrund. Zum Beispiel in der Unified Modeling Language(UML) werden sehr viele verschiedene Notationen verwendet: Klassendiagramme, Sequenzdiagramme, Use-Case-Diagramme, Zustandsübergangsdiagramme usw. Wie auch in den meisten anderen objektorientierten Spezifikationsnotationen ist hier die Hauptnotation das Klassendiagramm Vor- und Nachteile formaler und informaler Notationen Durch ein Software Engineering Projekt soll immer ein in der realen informalen Welt vorliegendes Problem gelöst werden. Die Lösung des Problems, das Zielsystem, ist immer ein formales System. Irgendwann zwischen Erkennen des Problems und Fertigstellung des Zielsystems muss ein Übergang vom Informalen zum Formalen stattgefunden haben. Die Frage ist, wann dieser Übergang stattfindet oder stattfinden soll. Eine Möglichkeit besteht darin, ein formales Modell des Zielsystems zu erstellen. Eine andere Möglichkeit besteht darin, diesen Übergang erst in den Realisierungsphasen (Entwurf, Implementierung) zu vollziehen. Eine wichtige Aufgabe der Problemanalyse (sieh Kapitel 3) besteht darin, das informale Problem zu beschreiben. Zur Beschreibung unstrukturierter Probleme ist die natürliche Sprache konkurrenzlos gut geeignet. Es ist sehr schwer, informale Aspekte zu formalisieren. Durch welchen Formalismus lassen sich z.b. Benutzer sinnvoll beschreiben? Außerdem, Formale Notationen können nur dann sinnvoll eingesetzt werden, wenn das Problem vollständig verstanden wurde. In den meisten Fällen kann also nicht direkt mit formalen Notationen begonnen werden. Wird ein Konflikt entdeckt, so muss dieser Konflikt auf der informalen Seite gelöst werden. Das heißt, wird der Konflikt in einer formalen Anforderungsspezifikation entdeckt, muss er implizit oder explizit paraphrasiert werden. Insofern 17

18 sind informale Notationen für das Requirements Engineering von großer Bedeutung. Die Einführung von formalen Notationen in ein Unternehmen ist sehr teuer, weil sie in der Regel mit einem umfangreichen Schulungsprogramm und evtl. der Einstellung von hochbezahlten Notationsspezialisten verbunden ist. Es müssen nicht nur die Personen geschult werden, die Spezifikation erstellen sollen, sondern auch die Leser. Der Leserkreis einer Spezifikation kann sehr groß sein und Personen umfassen, die nicht zu dem Unternehmen gehören, die also nicht unbedingt geschult werden können oder wollen. Ein weiteres Problem ist der negative Ruf formaler Notationen. Es kann Jahre dauern, bis sie von den Mitarbeitern eines Unternehmens wirklich akzeptiert werden, zumal viel Praxis und Erfahrung vorhanden sein müssen, bevor sie produktiv eingesetzt werden können. In vielen Unternehmen gibt es Zweifel, ob die Notationen und zugehörigen Werkzeuge die notwendige Reife für große Projekte haben, oder ob sie für ihre Projekte prinzipiell nützlich sind. Was fehlt, sind für den jeweiligen Anwendungsbereich angemessene Werkzeuge und praxisrelevante Beispiele. Dem negativen Ruf, den die formalen Notationen bei den Personen haben, die sie anwenden sollen, steht ein positiver Ruf bei den Personen gegenüber, die Aufträge vergeben oder Unternehmen beurteilen wollen. Automatische Verifikation ist ein wichtiger Vorteil formaler Notationen, so das eine formale Spezifikation mittels mathematischer Methoden und evtl. sogar automatisch auf bestimmte Aspekte der Vollständigkeit und Konsistenz geprüft werden kann. Bestimmte Mängel können so sehr früh und ohne großen Aufwand gefunden werden. Es können aber nicht alle Mängel gefunden werden: Es kann z.b. nicht festgestellt werden, ob das spezifizierte System den Wünschen der Informanten entspricht oder ob alle Wünsche der Informanten berücksichtigt wurden. Angesicht der vielen Vor- und Nachteile sowohl formaler als auch informaler Notationen soll für jedes Projekt individuell entschieden werden, welche Notation zur Erstellung der Anforderungsspezifikation ausgewählt wird. 5.5 Prüfung von Anforderungen Prüfung von Anforderungen wird hier als Prüfung von bestehenden Anforderungsspezifikation verstanden. Beim Prüfen einer Anforderungsspezifikation geht es darum, Abweichungen von der geforderten Qualität der Spezifikation festzustellen. Mit anderen Worten, bei der Prüfung sollen möglichst viele Fehler, Lücken, Unklarheiten, Mehrdeutigkeiten etc. gefunden (und anschließend behoben) werden. Dabei haben nicht alle Qualitätsmerkmale das gleiche Gewicht. In erster Priorität sollte auf Adäquatheit, Vollständigkeit, Widerspruchsfreiheit und Verständlichkeit geprüft werden, in zweiter Priorität auf Prüfbarkeit und Eindeutigkeit und in dritter Priorität auf alle übrigen Merkmale. 18

19 Die Prüfung einer Spezifikation auf Adäquatheit, Vollständigkeit und Widerspruchsfreiheit wird auch Validierung genannt. Die Prüfung erfolgt sinnvollerweise unter Federführung von IT - Mitarbeitern, die insbesondere die verwendete Darstellung ohne fremde Hilfe interpretieren können. Zusätzlich müssen aber die Vertreter des Kunden zwingend in den Prüfprozess einbezogen werden, denn nur sie können schlussendlich die Adäquatheit und Vollständigkeit der Spezifikation beurteilen. Die abschließende Prüfung einer Spezifikation erfolgt zu einem Zeitpunkt, wo die Spezifikation fertig ist aber noch genug Zeit bleibt, die gefundenen Mängel zu beheben. Bei umfangreichen Spezifikationen sind zusätzlich Zwischenprüfungen, begleitend zur Erstellung der Spezifikation, erforderlich. Für die Prüfung einer Anforderungsspezifikation kommen vier Verfahren in Betracht Reviews Prüf - und Analysemittel in Werkzeugen Simulation Prototypen Ein Review ist eine formell organisierte Zusammenkunft von Personen zur inhaltlichen oder formellen Überprüfung eines Produktteils (Dokument, Programmstück, etc.) nach vorgegebenen Prüfkriterien. Reviews sind das Mittel zur Prüfung von Dokumenten. Prüf - und Analysemittel in Werkzeugen werden immer dann eingesetzt, wenn eine Spezifikation mit Hilfe von Werkzeugen erstellt wurde. Insbesondere Lücken und Widersprüche in der Spezifikation lassen sich mit solchen Prüfverfahren finden. Beispielsweise kann ein Werkzeug prüfen, ob jeder verwendete Datenname auch irgendwo definiert ist. Mit einer Simulation kann die Adäquatheit des Verhaltens des spezifizierten Systems in bestimmten Situationen untersucht werden. Ein Prototyp ist ein lauffähiges Stück Software, welches Teile eines zu entwickelnden Systems vorab realisiert. Er dient als Modell für die weitere Entwicklung oder für das zu schaffende Produkt. Ein Prototyp ist das mächtigste verfügbare Mittel für die Beurteilung der Ädäquatheit einer Spezifikation durch die zukünftigen Benutzer. Er ermöglicht in beschränktem Rahmen eine Erprobung des gewünschten Systems in seiner geplanten Einsatzumgebung. Aufgrund der im Vergleich zu anderen Prüfverfahren hohen Kosten für einen Prototyp muss in jedem Einzelfall entschieden werden, wie weit die Entwicklung von Prototypen für die Prüfung von Anforderungen aufgrund des Entwicklungsrisikos notwendig ist. 19

20 5.5.1 Viewpoints Sehr hilfreich bei der Anforderungsanalyse und der Prüfung von Anforderungen sind die Viewpoints. Viewpoints, oder unterschiedliche Sichten auf das System, sind die Vorraussetzung dafür, dass man alle relevanten System- Requirements während der Analysephase entdecken kann. Mit der Beachtung von Viewpoints wir das Risiko minimiert, unterschiedliche Interessengruppen und ihre Requirements, eventuell zu übersehen. Problem to be analysed Abbildung 9. Viewpoints und Interessengruppen Wie aus der Abbildung 9 ersichtlich ist, gibt es unterschiedliche Interessengruppen und daraus resultierende Viewpoints, die unterschiedliche Anforderungen an das zu entwickelnde System stellen und diese als Teile des zu lösenden Problems identifizieren. Würde man die Problemstellung bei der Requirements Analyse nur von einer einzelnen Perspektive aus betrachten, könnte sich das implementierte System, im Endergebnis, als unbrauchbar erweisen. Als nächstes werden die, unter Berücksichtigung verschiedener Viewpoints, gefundene Requirements im zu entwickelnden System identifiziert, womit sichergestellt wird, dass alle gefundenen Requirements später auch wirklich realisiert werden. Außer der Gefahr, dass bei Nichtbeachtung verschiedener Viewpoints, wichtige Requirements nicht gefunden werden, wird durch Viewpoints auch die Wahrscheinlichkeit verringert, dass sich mehrer Requirements überlappen und somit Redundanzen entstehen. Weitere Vorteile, die sich bei der Berücksichtigung von Viewpoints bei der Requirements Analyse ergeben, seien im Folgenden kurz zusammengefasst: Viewpoints führen zu vollständigeren Requirements Requirements Traceability, also Nachvollziehbarkeit woher die Anforderungen stammen, wird unterstützt, wenn Requirements mit Viewpoints assoziiert sind. 20

Requirements Engineering (Anforderungstechnik)

Requirements Engineering (Anforderungstechnik) 5 Requirements Engineering Einführung 5.1 Was ist Requirements Engineering? Erste Näherung: Requirements Engineering (Anforderungstechnik) ist das systematische, disziplinierte und quantitativ erfassbare

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

Requirements-Engineering Requirements-Engineering

Requirements-Engineering Requirements-Engineering -Engineering Copyright Chr. Schaffer, Fachhochschule Hagenberg, MTD 1 Was ist ein Requirement? IEEE-Standard (IEEE-726 83) A condition or capability needed by a user to solve a problem or achieve an objective.

Mehr

Prof. Dr.-Ing. Dagmar Meyer Software Engineering 2 ANFORDERUNGSANALYSE UND -MODELLIERUNG

Prof. Dr.-Ing. Dagmar Meyer Software Engineering 2 ANFORDERUNGSANALYSE UND -MODELLIERUNG 2 ANFORDERUNGSANALYSE UND -MODELLIERUNG "If you don't know where you are going, you are unlikely to end up there." Forrest Gump 2 Anforderungen bilden die Grundlage für jedes (Software-)Projekt sind die

Mehr

Grundlagen der Anforderungsanalyse. 28. Oktober 2014

Grundlagen der Anforderungsanalyse. 28. Oktober 2014 Grundlagen der Anforderungsanalyse 28. Oktober 2014 Überblick Wie analysiert man die Anforderungen an ein neues Softwaresystem? Welche Methoden und Techniken gibt es? Welche Probleme kann es bei der Anforderungserfassung

Mehr

Software-Engineering

Software-Engineering FH Wedel Prof. Dr. Sebastian Iwanowski SWE3 Folie 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 3: Softwareplanung FH Wedel Prof. Dr. Sebastian Iwanowski SWE3 Folie 2 Problem und Lösung Aufnehmen

Mehr

Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie

Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie Insert picture and click Align Title Graphic. Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie Dr. Dieter Lederer, Geschäftsführer Vector Consulting Services GmbH

Mehr

Projekt:

Projekt: <Hier den Namen des Projektes eingeben!> <Adresse> <Telefon / Fax> <Ansprechpartner> Pflichtenheft Die Aufgabe des Pflichtenheftes ist es zu beschreiben, was die zu entwickelnde Software für den Anwender leisten soll. Diese Vorlage basiert auf der aus TSE I bekannten Vorlage. Projekt:

Mehr

UML Diagramme. Aktivitätsdiagramm

UML Diagramme. Aktivitätsdiagramm Di, 15. April 2008 Thema: Requirements Techniken (Teil 3) Vorlesung von David Kurmann Autor: Oliver Röösli oliver.roeoesli@stud.fhz.ch UML Diagramme Aktivitätsdiagramm Das Aktivitätsdiagramm (engl. activity

Mehr

Validierung und Verifikation!

Validierung und Verifikation! Martin Glinz Thomas Fritz Software Engineering Kapitel 7 Validierung und Verifikation 2005-2013 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

15 Verwaltung von Anforderungen (Requirements Management)

15 Verwaltung von Anforderungen (Requirements Management) 15 Verwaltung von Anforderungen (Requirements Management) Was ist Requirements Management? Planung und Lenkung des RE-Prozesses Konfigurationsmanagement für Anforderungen Identifikation Änderungs- und

Mehr

Requirements Engineering

Requirements Engineering Seite 1 Requirements Engineering Seite 2 Zielsetzung Systematischer Ansatz, Anforderungen zu Ermitteln Analysieren Organisieren Dokumentieren Mittel, um gemeinsame Basis zwischen Kunde und Entwickler zu

Mehr

Universität zu Köln Institut für Historisch-Kulturwissenschaftliche Informationsverarbeitung Virtuelle Forschungsumgebungen Dozent: Prof. Dr. phil.

Universität zu Köln Institut für Historisch-Kulturwissenschaftliche Informationsverarbeitung Virtuelle Forschungsumgebungen Dozent: Prof. Dr. phil. Universität zu Köln Institut für Historisch-Kulturwissenschaftliche Informationsverarbeitung Virtuelle Forschungsumgebungen Dozent: Prof. Dr. phil. Manfred Thaller WS 2010/11 Referentin: Sanja Wiechmann

Mehr

Assembly Technology. des Entwicklungsprozesses

Assembly Technology. des Entwicklungsprozesses FRAUNHOFER-institut für produktionstechnologie IPT projektgruppe entwurfstechnik mechatronik Requirements Engineering Assembly Technology Ovidemporion porum quiae nemporro cone venderferia coris dio officia

Mehr

Einführung in die Informatik

Einführung in die Informatik Einführung in die Informatik Softwareentwicklung Probleme bei großer Software Life-Cycle-Modelle Teilphasen eines Software-Projekts Methoden und Werkzeuge 01101101 01011001 11010011 10011000 00000011 00011100

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.

Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch. Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.pdf Nachdem die Projekt-Vision und die Stakeholder bekannt sind,

Mehr

Informationssystemanalyse Requirements Engineering 10 1

Informationssystemanalyse Requirements Engineering 10 1 Informationssystemanalyse Requirements Engineering 10 1 Requirements Engineering Viele Probleme bei der Softwareentwicklung entstehen sehr früh im Entwicklungsprozeß. Im Rahmen des Requirements Engineering

Mehr

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

Mehr

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16 Probeklausur Lenz Belzner January 26, 2015 Lenz Belzner Probeklausur January 26, 2015 1 / 16 Definieren Sie Software Engineering in Abgrenzung zu Individual Programming. Ingenieursdisziplin professionelle

Mehr

Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System?

Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System? Der Entwicklungsprozess Oder wie entwickle ich ein eingebettetes System? Einleitung Problemstellung erläutern, Eine Entwicklungsprozess ist ein Prozess, der beschreibt, wie man eine Entwicklung anzugehen

Mehr

YAKINDU Requirements. Requirements Engineering, Management and Traceability with Eclipse. Lars Martin, itemis AG. itemis AG

YAKINDU Requirements. Requirements Engineering, Management and Traceability with Eclipse. Lars Martin, itemis AG. itemis AG YAKINDU Requirements Requirements Engineering, Management and Traceability with Eclipse Lars Martin, itemis AG Agenda YAKINDU Requirements Motivation: Warum Requirements Engineering? Grundlagen: Requirements

Mehr

(Titel des Berichts)

(Titel des Berichts) (Titel des Berichts) Praxissemesterbericht von (Vorname Name) aus (Geburtsort) Matrikelnummer Anschrift Telefon HTW Aalen Hochschule für Technik und Wirtschaft Betreuender Professor Abgabetermin Angaben

Mehr

Scrum und professionelles Requirements Engineering

Scrum und professionelles Requirements Engineering Scrum und professionelles Requirements Engineering Dr. Martin Mandischer (Prokurist, Professional Scrum Trainer) Jens Trompeter (Vorstand, Certified Scrum Professional) Gründung im Jahr 2003 Mehr als 160

Mehr

Das V-Modell: Produkte 1/5

Das V-Modell: Produkte 1/5 Das : Produkte 1/5 Problem-Beschreibung, Lastenheft Beschreibung des Problems/der Probleme, das/die gelöst werden soll Quellen: Markt-Analyse, Marketing, Kunden-Zirkel etc. Kunden-Anforderungen, Pflichtenheft

Mehr

1 Objektorientierte Software-Entwicklung

1 Objektorientierte Software-Entwicklung 1 Objektmodellierung 1 Objektorientierte Software-Entwicklung Prof. Dr. Heide Balzert Fachbereich Informatik Fachhochschule Dortmund Heide Balzert 2000 2 Lernziele Wissen, was unter objektorientierter

Mehr

Einführung in die SWE

Einführung in die SWE Einführung in die SWE Inhalte der Vorlesung Allgemeine Ziele der Lehrveranstaltung Entwickeln einer kleinen Applikation nach professionellem Vorgehensmodell Erlernen des objektorientierten Herangehens

Mehr

Musteraufbau eines Anforderungsprofils zur Einführung neuer Software

Musteraufbau eines Anforderungsprofils zur Einführung neuer Software Musteraufbau eines Anforderungsprofils zur Einführung neuer Software Ottostr. 15 96047 Bamberg Tel. +49/951/98046200 Fax +49/951/98046150 email: info@softcondev.de www: softcondev.de INHALT Vorwort Diese

Mehr

Optimieren von Requirements Management & Engineering

Optimieren von Requirements Management & Engineering Xpert.press Optimieren von Requirements Management & Engineering Mit dem HOOD Capability Model Bearbeitet von Colin Hood, Rupert Wiebel 1. Auflage 2005. Buch. xii, 245 S. Hardcover ISBN 978 3 540 21178

Mehr

Nichtfunktionaler Abnahmetest: Planung, Durchführung und Automatisierung

Nichtfunktionaler Abnahmetest: Planung, Durchführung und Automatisierung Nichtfunktionaler Abnahmetest: Planung, Durchführung und Automatisierung Uwe Hehn TAV Februar 2005 Hochschule Bremen Uwe.Hehn@methodpark.de Abnahmetest: Warum brauchen wir denn so etwas? Projektabnahme

Mehr

Experience. nr.52. ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen. märz 2012

Experience. nr.52. ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen. märz 2012 ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen Experience nr.52 märz 2012 RequIREMENTs EngINEERINg Ins Schwarze treffen Ins SchwARze treffen Requirements Engineering: die Grundlagen

Mehr

Anforderungsanalyse, Requirements Engineering

Anforderungsanalyse, Requirements Engineering Anforderungsanalyse, Requirements Engineering, Lastenheft, Pflichtenheft, Spezifikation, Zielgruppen Natürliche Sprache, Formulare Pflichtenheft, an ein Pflichtenheft von Funktionale, nicht-funktionale

Mehr

Systemen - Testen im Softwarelebenszyklus

Systemen - Testen im Softwarelebenszyklus P r a k t I s c h e Entwicklung und Test Testen von Software-Systemen Systemen - Testen im Softwarelebenszyklus Entwickler erstellen ihr System bzw. ihre Software und testen es/sie zur Entwicklungszeit

Mehr

Erstellung eines Pflichtenhefts (I)

Erstellung eines Pflichtenhefts (I) 2. Anforderungsanalyse Erstellung eines Pflichtenhefts (I) Annahme: Es liegt ein "gutes" Lastenheft vor Was fehlt noch? Details... gemeinsame Sprache Glossar gemeinsames Verständnis der Funktion Funkt.

Mehr

Qualität 1. 1 Qualität

Qualität 1. 1 Qualität Qualität 1 1 Qualität Nach dem Durcharbeiten dieses Kapitels sollten Sie die Qualität für ein Softwaresystem definieren können, typische Qualitätskriterien kennen, Qualitätskriterien messbar festlegen

Mehr

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

Mehr

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector 7.4 Analyse anhand der SQL-Trace 337 7.3.5 Vorabanalyse mit dem Code Inspector Der Code Inspector (SCI) wurde in den vorangegangenen Kapiteln immer wieder erwähnt. Er stellt ein paar nützliche Prüfungen

Mehr

Praktikum Software Engineering: Verfahren und Werkzeuge

Praktikum Software Engineering: Verfahren und Werkzeuge Praktikum Software Engineering: Verfahren und Werkzeuge Lehrstuhl für Software Engineering (Informatik 11) Verfahren und Werkzeuge Seite 1 Software Engineering Absichten, Aufgaben Systemnutzung Anforderungsspezifikation

Mehr

Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1

Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1 Test Dipl. Wirtsch. Ing. Alexander Werth 9-1 Phasen der Problemdefinition Anforderungsanalyse Spezifikation Entwurf Implementation Erprobung Wartung Methoden der 9-2 Software Test / Erprobung Messen der

Mehr

Programmierung, Algorithmen und Techniken. von Thomas Ohlhauser

Programmierung, Algorithmen und Techniken. von Thomas Ohlhauser Programmierung, Algorithmen und Techniken von Thomas Ohlhauser 1. Begriff Programmierung Entwicklung von Programmen inklusive der dabei verwendeten Methoden und Denkweisen. Ein Programm ist eine eine Zusammensetzung

Mehr

FUTURE NETWORK 20.11.2013 REQUIREMENTS ENGINEERING

FUTURE NETWORK 20.11.2013 REQUIREMENTS ENGINEERING 18/11/13 Requirements Engineering 21 November 2013 DIE GRUNDFRAGEN Wie erhält der Kunde den größten Nutzen? Wie kann der Kunde am besten spezifizieren, was er haben will? Welchen Detailierungsgrad braucht

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

16 Architekturentwurf Einführung und Überblick

16 Architekturentwurf Einführung und Überblick Teil III: Software-Architekturentwurf 16 Architekturentwurf Einführung und Überblick 16.1 Software entwerfen Warum? Beim Arbeiten im Kleinen nicht oder nur ansatzweise (Detailentwurf) Größere Software

Mehr

6 Zusammenfassende Bewertung und Ausblick

6 Zusammenfassende Bewertung und Ausblick 437 6 Zusammenfassende Bewertung und Ausblick Immer wieder scheitern Projekte zur Software-Gestaltung im Öffentlichen Dienst bzw. sie laufen nicht wie geplant ab. Dies ist für sich genommen nicht weiter

Mehr

1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem

1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem 1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem Management, Access Management a. Event Management b. Service Desk c. Facilities Management d. Change Management e. Request Fulfilment

Mehr

Prüfspezifikation für Anforderungen (Lastenheft) für WiBe 4.0. Version: 1.3

Prüfspezifikation für Anforderungen (Lastenheft) für WiBe 4.0. Version: 1.3 -Prüfung: Prüfspezifikation Dokument- Prüfspezifikation für Anforderungen (Lastenheft) für WiBe 4.0 Version: 1.3 Projektbezeichnung Projektleiter Verantwortlich Erstellt am 11.03.2005 Zuletzt geändert

Mehr

Abb.: Darstellung der Problemfelder der Heine GmbH

Abb.: Darstellung der Problemfelder der Heine GmbH Entwicklung eines SOLL-Konzeptes Kehl Olga 16.05.10 Wie aus der Ist-Analyse ersichtlich wurde, bedarf die Vorgehensweise bei der Abwicklung von Projekten an Verbesserung. Nach der durchgeführten Analyse

Mehr

Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung

Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung Hintergrund Bei komplexen Baugruppen ergeben sich sehr hohe Anforderungen an die Tolerierung der einzelnen

Mehr

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar: KLIPS 2.0 Dozent: Prof. Dr. Thaller Referent:

Mehr

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Modellgetriebene Softwareentwicklung auf Basis von TOPCASED am Beispiel

Mehr

Systematisches Testen von Software

Systematisches Testen von Software Programmierung Systematisches Testen von Software Markus Eckstein Systematika Information Systems GmbH Kurfürsten-Anlage 36 69115 Heidelberg markus.eckstein@systematika.com Zusammenfassung Die wichtigsten

Mehr

1 Einleitung. Software Engineering. Vorgehensweisen

1 Einleitung. Software Engineering. Vorgehensweisen 1 Noch ein Buch über Software Engineering? Warum nicht! Wir folgen einem Prinzip, das zur Lösungsfindung in den verschiedensten Domänen Einzug gehalten hat: die Betrachtung aus verschiedenen Blickwinkeln.

Mehr

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells...

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells... Inhaltsverzeichnis Inhaltsverzeichnis... I 1 Problemstellung... 1 2 V-Modell... 1 2.1 Allgemeines... 1 2.2 Anwendung des V-Modells... 3 3 SCRUM-Modell... 4 3.1 Allgemeines... 4 3.2 Anwendung des SCRUM-Modells...

Mehr

1 Einleitung. 1.1 Unser Ziel

1 Einleitung. 1.1 Unser Ziel 1 Dieses Buch wendet sich an alle, die sich für agile Softwareentwicklung interessieren. Einleitend möchten wir unser mit diesem Buch verbundenes Ziel, unseren Erfahrungshintergrund, das dem Buch zugrunde

Mehr

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003):

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003): Professionelles Projekt-Management in der Praxis Veranstaltung 7 Teil 1 (30.06.2003): Prof. Dr. Phuoc Tran-Gia, FB Informatik, Prof. Dr. Margit Meyer, FB Wirtschaftswissenschaften, Dr. Harald Wehnes, AOK

Mehr

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Andreas Armbrecht Siemens AG Darmstadt, 01. 02. Dezember 2009 Business Unit Rail Automation Systeme der Eisenbahnautomatisierung

Mehr

Lernen durch Feedback aus Inspektionen 28.11.2013 Dr. Andrea Herrmann

Lernen durch Feedback aus Inspektionen 28.11.2013 Dr. Andrea Herrmann Lernen durch Feedback aus Inspektionen 28.11.2013 Dr. Andrea Herrmann Freie Software Engineering Trainerin und Forscherin www.herrmann-ehrlich.de Übersicht 1. Motivation 2. Fragen 3. Durchführung 4. Ergebnisse

Mehr

Einführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben

Einführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Einführung von Testautomatisierung reflektiert Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Matt Young Leiter Test Acquiring Inhaltsverzeichnis Einleitung Testautomatisierung PostFinance

Mehr

Service Innovation Lab. Produktentwicklung im Dienstleistungsunternehmen

Service Innovation Lab. Produktentwicklung im Dienstleistungsunternehmen Service Innovation Lab Produktentwicklung im Dienstleistungsunternehmen 2 Wettbewerbsvorteile durch Dienstleistungsinnovation Die Erlangung von neuen oder die Sicherung bestehender Wettbewerbsvorteile

Mehr

ISMS Teil 3 Der Startschuss

ISMS Teil 3 Der Startschuss ISMS Teil 3 Der Startschuss Nachdem das TOP-Managenment die grundsätzliche Entscheidung getroffen hat ein ISMS einzuführen, kann es nun endlich losgehen. Zu Beginn sollte Sie noch die Grundlagen des ISMS

Mehr

ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen

ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen Bernhard Fischer Fischer Consulting GmbH MedConf 2009 Folie 1 Wie soll Software entwickelt werden? MedConf 2009 Folie

Mehr

Messen von Usability. Wie kann man eine GUI unter dem Gesichtspunkt Usability bewerten?

Messen von Usability. Wie kann man eine GUI unter dem Gesichtspunkt Usability bewerten? Messen von Usability Wie kann man eine GUI unter dem Gesichtspunkt Usability bewerten? 1 Motivation Warum Usability messen? Usability Probleme frühzeitig erkennen Unterschiedliche Bedienelemente / Interaktionsmöglichkeiten

Mehr

Dipl. Inf. Ali M. Akbarian

Dipl. Inf. Ali M. Akbarian Dipl. Inf. Ali M. Akbarian 2012 Einführung Globalisierung, Innovation und Kundenzufriedenheit sind auch in Zukunft die wichtigsten Herausforderungen der Unternehmen. Diese Herausforderungen verlangen:

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Migration von (0)190 Servicerufnummern in die Diensterufnummerndatenbank

Migration von (0)190 Servicerufnummern in die Diensterufnummerndatenbank Migration von (0)190 Servicerufnummern in die Konzept des UAK DR zur Einführung einer Erweiterung der Version 0.0.1 Stand 29.06.2001 Verwendung: UAK DR Auftraggeber: UAK DR Autor: Rick Wiedemann Talkline

Mehr

Data Mining-Projekte

Data Mining-Projekte Data Mining-Projekte Data Mining-Projekte Data Mining stellt normalerweise kein ei nmaliges Projekt dar, welches Erkenntnisse liefert, die dann nur einmal verwendet werden, sondern es soll gewöhnlich ein

Mehr

Grob- und Detailplanung bei der Implementierung nutzen

Grob- und Detailplanung bei der Implementierung nutzen Softwarearchitektur Grob- und Detailplanung bei der Implementierung nutzen Bereich Realisierung Aktivität Softwareinkrement realisieren Ziele Vermitteln einer Orientierungshilfe für alle Entwickler Etablierung

Mehr

Objektorientierte Software-Entwicklung

Objektorientierte Software-Entwicklung Objektorientierte Software-Entwicklung Priv.- Doz Dr. Rolf Hennicker 04.10.2002 Kapitel 1 Software Engineering: Überblick Kapitel 1 Software Engineering: Überblick 2 Ziele Verstehen, womit sich die Disziplin

Mehr

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung Unified Process Eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Unified Process Wie wird heute gearbeitet? Der Unified Process

Mehr

REQUIREMENTS ENGINEERING KONSTRUKTIVE QS REQUIREMENTS ENGINEERING 1

REQUIREMENTS ENGINEERING KONSTRUKTIVE QS REQUIREMENTS ENGINEERING 1 REQUIREMENTS ENGINEERING KONSTRUKTIVE QS REQUIREMENTS ENGINEERING 1 QUALITÄT FÜR SIE Qualität zeigt sich in Ergebnissen und Erfolgen. Sie hängt von der jeweiligen Problemstellung ab, deshalb sehen wir

Mehr

Requirements Engineering und IT Service Management Ansatzpunkte einer integrierten Sichtweise

Requirements Engineering und IT Service Management Ansatzpunkte einer integrierten Sichtweise Requirements Engineering und IT Service Management Ansatzpunkte einer integrierten Sichtweise Markus Garschhammer Munich Network Management Team (LMU München / Leibniz Rechenzentrum) Friederike Nickl Sepis

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

in Unternehmen der Gesundheits- und Sozialbranche - VQSV

in Unternehmen der Gesundheits- und Sozialbranche - VQSV 1. Kundenorientierung Umsetzung im QM-Handbuch Verantwortung gegenüber Kunden Den Kunden / Patienten / Bewohner als Partner und Mensch behandeln. Welches sind meine Kunden? Bedarfsgerechte Leistung Sicherstellen,

Mehr

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process.

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1996 Philippe Kruchten: Rational Unified Process Produkt der Firma Seit 2002 Teil des IBM Konzerns Objektorientiertes

Mehr

Wi W s i sens n ch c a h ft f l t ilc i h c e h s s A rbe b it i en Hans-Peter Wiedling 1

Wi W s i sens n ch c a h ft f l t ilc i h c e h s s A rbe b it i en Hans-Peter Wiedling 1 Wissenschaftliches Arbeiten Hans-Peter Wiedling 1 Mit Ihrer wissenschaftlichen Arbeit dokumentieren Sie die eigenständige Einarbeitung in eine Aufgaben-/Problemstellung sowie die methodische Erarbeitung

Mehr

PQ4Agile Agiler Referenzprozess

PQ4Agile Agiler Referenzprozess PQ4Agile Agiler Referenzprozess ARBEITSPAKET 1.1 KONSORTIUM Projekt Förderprogramm PQ4Agile KMU Innovativ Förderkennzeichen 01IS13032 Arbeitspaket Fälligkeit 31.07.2014 Autor Status Klassifikation AP1.1

Mehr

Software Engineering 4) Definitionsphase und Requirements Engineering

Software Engineering 4) Definitionsphase und Requirements Engineering Software Engineering 4) Definitionsphase und Requirements Engineering Prof. Dr. Anja Metzner Hochschule Augsburg, Fakultät für Informatik Kontakt: anja.metzner@hs-augsburg.de Studiengang WiBac 4 (Stand:

Mehr

Wie man mit Change Management IT-Projektkosten senken kann

Wie man mit Change Management IT-Projektkosten senken kann Wie man mit Change Management IT-Projektkosten senken kann ein Artikel von Ulrike Arnold Kaum ein Projekt wird in der vorgegebenen Zeit und mit dem geplanten Budget fertiggestellt. Und das, obwohl die

Mehr

Softwaretechnik Nicht funktionale Anforderungen

Softwaretechnik Nicht funktionale Anforderungen Softwaretechnik Nicht funktionale Anforderungen Karsten Weicker, Nicole Weicker HTWK Leipzig, FHTW Berlin Will Turner: You swore she d go free! Barbossa: Don t dare impugn me honor boy! I agreed she go

Mehr

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung Software-Qualität im Rahmen modellgetriebener Softwareentwicklung OFFIS Technologiecluster Enterprise Application Integration niels.streekmann@offis.de 09.07.2008 Seite 1 / 13 Software-Qualität: Unterschiedliche

Mehr

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/

Mehr

Software Engineering II (IB) Testen von Software / Modultests

Software Engineering II (IB) Testen von Software / Modultests Testen von Software / Modultests Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Programm-Tests Tests sollen zeigen, dass ein Programm das tut was es tun soll sowie

Mehr

Design, Durchführung und Präsentation von Experimenten in der Softwaretechnik

Design, Durchführung und Präsentation von Experimenten in der Softwaretechnik Design, Durchführung und Präsentation von Experimenten in der Softwaretechnik Inhalt 1. Zusammenfassung der Papers 2. Fehler in Design, Durchführung und Präsentation 3. Richtlinien für saubere Experimente

Mehr

Kapitel 2: Der Software-Entwicklungsprozess

Kapitel 2: Der Software-Entwicklungsprozess Wie konstruiert man Software? Kapitel 2: Der Software-Entwicklungsprozess SoPra 2008 Kap. 2: Der Software-Entwicklungsprozess (1/10) Der Software-Entwicklungs-Prozess Historisches 1960JJ adhoc Techniken

Mehr

Prüfbericht. Produktprüfung FastViewer

Prüfbericht. Produktprüfung FastViewer Nr. 028-71325195-000 Rev. 1 Produktprüfung FastViewer Gegenstand FastViewer - Desktop-Sharing Anwendung Prüfungsart Produktprüfung Grundlage TÜV-Süd Prüfkatalog zur Qualität von Anwendungs-Software auf

Mehr

Softwareanforderungsanalyse

Softwareanforderungsanalyse Softwareanforderungsanalyse Einführung Burkhardt Renz Institut für SoftwareArchitektur der Technischen Hochschule Mittelhessen Wintersemester 2015/16 Übersicht Was ist Softwareanforderungsanalyse Definitionen

Mehr

Use-Cases. Bruno Blumenthal und Roger Meyer. 17. Juli 2003. Zusammenfassung

Use-Cases. Bruno Blumenthal und Roger Meyer. 17. Juli 2003. Zusammenfassung Use-Cases Bruno Blumenthal und Roger Meyer 17. Juli 2003 Zusammenfassung Dieses Dokument beschreibt Netzwerk-Szenarios für den Einsatz von NetWACS. Es soll als Grundlage bei der Definition des NetWACS

Mehr

IV::SOLUTIONFRAMEWORK

IV::SOLUTIONFRAMEWORK IV::SOLUTIONFRAMEWORK EINFÜHRUNG Das IV::SolutionFramework ist die Antwort der INTERVISTA AG auf die Anforderungen an moderne IT Entwicklungsprojekte. Effiziente Vorgehensmodelle und die Einführung von

Mehr

Informationssystemanalyse Personal Software Process 8 1

Informationssystemanalyse Personal Software Process 8 1 Informationssystemanalyse Personal Software Process 8 1 Personal Software Process Sehr eng mit dem CMM hängt der PSP (Personal Software Process) zusammen. Der PSP ergänzt das organisationsweite CMM um

Mehr

Collaborative Virtual Environments

Collaborative Virtual Environments Collaborative Virtual Environments Stefan Lücking Projektgruppe Kreativität und Technik AG Domik WS 02/03 09.01.2003 1/35 Was sind CVE? Versuch einer Definition : Ein CVE ist ein Programm, das eine virtuelle

Mehr

Agile Programmierung - Theorie II SCRUM

Agile Programmierung - Theorie II SCRUM Agile Programmierung - Theorie II SCRUM Arne Brenneisen Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Seminar Softwareentwicklung in der Wissenschaft Betreuer: Christian

Mehr

RE-Praxisbericht: Ergebnisse einer aktuellen Studie zum Thema Use Cases

RE-Praxisbericht: Ergebnisse einer aktuellen Studie zum Thema Use Cases RE-Praxisbericht: Ergebnisse einer aktuellen Studie zum Thema Use Cases Dr. Alexander Rachmann Hartmut Schmitt Softwareforen Leipzig 9. Mai 2014 Agenda Der Use-Case-Arbeitskreis der Gesellschaft für Informatik/Fachgruppe

Mehr

Techniken zu Schreibwerkstatt Phase 1: Ein Thema erforschen und eingrenzen

Techniken zu Schreibwerkstatt Phase 1: Ein Thema erforschen und eingrenzen Techniken zu Schreibwerkstatt Phase 1: Ein Thema erforschen und eingrenzen Die 5 folgenden Techniken können Ihnen dabei helfen, ein passendes Thema bzw. eine Hypothese zu finden. 1. Fragen helfen beim

Mehr

Einführung und Motivation

Einführung und Motivation Einführung und Motivation iks-thementag: Requirements Engineering 16.11.2010 Autor Carsten Schädel Motto Definiere oder Du wirst definiert. Seite 3 / 51 These Im Privatleben definiert jeder (seine) Anforderungen.

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

Requirements Engineering für IT Systeme

Requirements Engineering für IT Systeme Requirements Engineering für IT Systeme Warum Systemanforderungen mit Unternehmenszielen anfangen Holger Dexel Webinar, 24.06.2013 Agenda Anforderungsdefinitionen Von der Herausforderung zur Lösung - ein

Mehr

IV Software-Qualitätssicherung

IV Software-Qualitätssicherung Softwaretechnik- Praktikum: 12. Vorlesung Jun.-Prof Prof.. Dr. Holger Giese Raum E 3.165 Tel. 60-3321 Email: hg@upb.de Übersicht I II III IV V Einleitung Ergänzungen zur Software-Entwicklung Software Management

Mehr