Wiki im Requirements-Engineering

Größe: px
Ab Seite anzeigen:

Download "Wiki im Requirements-Engineering"

Transkript

1 Daniel Taudien Wiki im Requirements-Engineering Hausarbeit Software-Engineering D. Taudien, Matrikel-Nr

2 Inhaltsverzeichnis Inhaltsverzeichnis... I Abkürzungsverzeichnis... II Abbildungsverzeichnis... III Wiki im Requirements-Engineering Einleitung Problemstellung und Zielsetzung Vorgehensweise Requirements-Engineering Anforderungserhebung und -anlyse Requirements-Management Wiki Wiki Web Standardfunktionen aller Typen von Wikis Semantische Wikis Wiki im Requirements-Engineering Anforderungserhebung und analyse mit einem Wiki Requirements-Engineering mit einem semantischen Wiki Fazit...16 Literaturverzeichnis...18 I

3 Abkürzungsverzeichnis Abb. Abbildung d.h. das heißt et al. et alii f. folgende (Seite) ff. fortfolgende Hrsg. Herausgeber i.d.r. in der Regel i.e.s. im engeren Sinn i.w.s. im weiteren Sinn o.g. oben genannten RE Requirements-Engineering RM Requirements-Management S. Seite Vgl. Vergleiche II

4 Abbildungsverzeichnis Abbildung 1: Projekterfolgsquoten... 2 Abbildung 2: Requirements-Management... 6 III

5 - 1. Einleitung 1.1. Problemstellung und Zielsetzung Software gestützte Systeme machen nicht immer das, was sie sollen. Hierbei kann es sich um vergleichsweise harmlose Fälle handeln wie beispielsweise die Oberbürgermeister Wahl in Neu-Ulm 1994, bei der die Wahlbeteiligung mit 104% ausgewiesen wurde um danach festzustellen, dass es sich um eine Verdopplung aufgrund eines Software-Fehlers gehandelt hat. Es können aber auch wirtschaftliche Schäden entstehen, wie zum Beispiel bei dem Projekt Fiscus der deutschen Finanzverwaltung mit ca. 900 Millionen Euro Lehrgeld. 1 Schwerwiegender sind jedoch die Fälle, bei denen es um das Leben von Menschen geht. Zu nennen ist hier unter anderem ein Fehler in der Software bei Passagierflugzeugen. 2 Diese Fehlverhalten sind keine neuen Probleme, sondern sie sind bereits in den 60er Jahren aufgetreten. Der Versuch einer Lösung ist die ingenieurmäßige Vorgehensweise in Software-Projekten und somit die Geburtsstunde des Software- Engineering. Schon in dieser Zeit wurde erkannt, dass es sich bei einem Software- Projekt um i.d.r. komplexe Projekte handelt. 3 Aus diesem Grund wird der Fokus der Arbeit auf komplexe Projekte gerichtet, bei der Nutzung in kleinen Projekten können einzelne Bausteine herausgenommen werden, so dass eine Anwendung erfolgen kann. Trotz der Entwicklung von Methoden und Modellen in den letzten Jahren im Software-Engineering sind Software-Projekte immer noch mit großen wirtschaftlichen und technischen Risiken behaftet, welche ihre Ursache häufig in einem mangelnden Requirements-Engineering haben. 4 1 Vgl. Partsch 2010 /Requirements-Engineering/ S Vgl. Partsch 2010 /Requirements-Engineering/ S Vgl. Partsch 2010 /Requirements-Engineering/ S Vgl. Pohl 2010 /Requirements-Engineering/ S. 6; Kittlaus, Rau, Schulz 2004 /Software-Produkt- Management/ S

6 Abbildung 1: Projekterfolgsquoten 5 Somit können Verbesserungen in diesem Bereich eine signifikante 6 Verbesserung der gesamten Erfolgsquote herbeiführen. Auch die Entwicklung des ersten Wiki ist im Rahmen eines Software-Projektes entstanden und hatte zum Ziel die Abstimmung zwischen Programmierern zu erleichtern. Es sollte Software-Code direkt ins Wiki geschrieben und dieser durch andere Programmierer geprüft und ergänzt werden. Dabei lag der Fokus auf einer einfachen Bedienung. Aufgrund von Wikipedia und der Entdeckung der Anwendbarkeit in den verschiedensten Bereichen ist das Wiki-Konzept mittlerweile einem breiten Publikum bekannt geworden. 7 Somit kann davon ausgegangen werden, dass für die Anwender 8 ein Wiki ein gut zu nutzendes Werkzeug ist. Auf Basis dieser Grundlage ist somit die Erweiterung der Nutzung für das Requirements-Engineering zu prüfen und das Wiki aus dem Bereich der Programmierer auch den Anwendern in einem Software-Projekt zur Verfügung zu stellen. Die Zielsetzung dieser Arbeit liegt somit in der Prüfung, ob ein Wiki im Bereich des Requirements-Engineering Möglichkeiten bietet, eine Verbesserung zu erreichen und einen Beitrag zum Erfolg von Software-Projekten zu leisten. 5 Quelle: Partsch 2010 /Requirements-Engineering/ S Signifikant, da bei der Behebung von Problemen in diesem Bereich ein Großteil der Probleme in Software-Projekten behoben ist. Vgl. zur Häufigkeit der Probleme Pohl 2010 /Requirements- Engineering/ S. 6; Kittlaus, Rau, Schulz 2004 /Software-Produkt-Management/ S Vgl. Ebersbach et al /Wiki/ S. 15 f. 8 Unter Anwender soll im Folgenden ein Nutzer eines IT-Systems verstanden werden der keine Programmier- oder IT-spezifische Ausbildung hat. 2

7 1.2. Vorgehensweise Für diese Prüfung werden im folgenden Kapitel 2 die Aufgaben und Probleme des Requirements-Engineering beschrieben. Kapitel 3 beschäftigt sich mit dem Wiki und den Möglichkeiten dieses Werkzeugs. Hierbei erfolgt eine Beschränkung auf die im Requirements-Engineering relevanten Bestandteile. In Kapitel 4 wird die Zusammenführung erfolgen, so dass klar wird, an welcher Stelle eine Verbesserung möglich ist und an welcher Stelle es noch Probleme gibt. 2. Requirements-Engineering Das Requirements-Engineering (RE) umfasst die systematische Erhebung, Analyse, Spezifikation, Validierung und Verwaltung von Anforderungen an eine Software. 9 Naturgemäß sind die Anforderungen zunächst unscharf, mehrdeutig, unvollständig und teilweise widersprüchlich definiert. Die Aufgabe des RE ist es diese aufzubereiten und präzise, eindeutig, konsistent und vollständig zu erfassen. 10 Hierbei ist es sinnvoll RE zum Entwurf im Software-Engineering abzugrenzen, wobei dies durchaus umstritten ist. Dies ist nach Ansicht des Verfassers jedoch notwendig, da nur so eine klare Vorstellung der Aufgaben und Tätigkeiten möglich ist. Im Folgenden soll die Unterscheidung wie folgt verstanden werden: Das Requirements-Engineering beschreibt das Was, also die Anforderung an die Software. Der Entwurf beschreibt das Wie, somit die Umsetzung im System. 11 Demzufolge ist das RE eher am Anwender ausgerichtet. Die Ermittlung der Anforderungen erfolgt grundsätzlich iterativ, in einem Prozess mit Rückkopplungsschleifen. 12 Die dabei entstehenden Dokumente und andere Informationsträger, sind innerhalb des Projektverlaufs nachzuverfolgen. D.h. es ist eine Verwaltung der Anforderungen notwendig. Diese Tätigkeit kann zusammen- 9 Vgl. Geisser et al /Wikis/ S. 3.; Sommerville 2001 /Software-Engineering/ S Vgl. Partsch 2010 /Requirements-Engineering/ S Vgl. Partsch 2010 /Requirements-Engineering/ S. 21 f. 12 Vgl. Zuser, Grechenig, Köhle 2004 /Software Engineering/ S

8 gefasst werden zum Requirements-Management. 13 Dabei ist zu berücksichtigen, dass die Überprüfung der Einhaltung der Anforderungen nach der Programmierung, nicht mehr in dem Bereich des Requirements-Managements und somit auch nicht in den Bereich des RE fällt. 14 Die o.g. Tätigkeiten Anforderungserhebung und analyse, sowie die Verwaltung derselben sind bei der Überprüfung der Nutzung eines Wiki zur Unterstützung zu berücksichtigen. 15 Hierzu werden im Folgenden diese Tätigkeiten näher betrachtet und stellen somit die Rahmenbedingungen 16 dar Anforderungserhebung und -anlyse Der erste Schritt im RE-Prozess ist i.d.r. 17 die initiale Erhebung der Anforderung. 18 Es kann durch den iterativen Verlauf des RE jedoch vorkommen, dass aus einer späteren Phase die Erhebung der Anforderung erneut durchlaufen wird. 19 Der RE- Prozess wird gestartet durch ein initiales Treffen des Projektteams. Dies ist im kleineren Projekten an einem Standort relativ einfach, bei großen Projekten und heterogenen Standorten kommt diesem Prozess eine große Bedeutung zu, da sicher gestellt werden muss, dass alle Beteiligten den notwendigen Informationsstand haben. 20 Nach Erfahrungen des Verfassers ist die Notwendigkeit der Sicherstellung eines einheitlichen Informationsstandes jedoch auch an einem Standort nicht zu vernachlässigen. Ab dem Start der Ermittlung der Anforderungen ist es möglich, dass sich die Anwender nicht im Klaren sind, wie die Anforderung und der Bedarf tatsächlich aussehen. Ein Grund hierfür kann sein, dass sie nicht in der Lage sind ihr implizites 13 Vgl. Partsch 2010 /Requirements-Engineering/ S. 22 f. 14 Vgl. Partsch 2010 /Requirements-Engineering/ S Vgl. grundsätzlich zu Werkzeugen im Requirements-Engineering Partsch 2010 /Requirements- Engineering/ S. 61 ff. 16 Rahmenbedingungen können an dieser Stelle synonym zu einer Eingrenzung verstanden werden. 17 Aufgrund der verschiedenen Vorgehensmodelle im Software-Engineering kann es Ausnahmen geben, diese haben jedoch keinen Einfluss auf die Konzeption. Vgl. zu den verschiedenen Vorgehensmodellen Sommerville 2001 /Software-Engineering/ S. 44 ff. 18 Vgl. Geisser et al /Wikis/ S. 4 f. 19 Vgl. zum iterativen Verlauf Partsch 2010 /Requirements-Engineering/ S Vgl. Geisser et al /Wikis/ S. 4 f. 4

9 Wissen zu explizieren. Die Folge daraus ist, dass die Anwender zwar instinktiv richtig arbeiten, es jedoch schwierig ist dies verbal zu beschreiben. 21 Ein weiteres Hindernis kann sein, dass innerhalb der Anwender nicht klar ist, was gewollt ist. D.h. es gibt unterschiedliche Meinungen und somit keine einheitliche Anforderung. Dies zu priorisieren und eine Schnittmenge zu bilden stellt sich als eine schwierige Aufgabe dar. 22 Um somit die Anforderungen verständlich und umfassend zu beschreiben sollten sich die Entwickler und Anwender zusammensetzen und so die Anforderung gemeinsam definieren. Hierbei kann jeder Bereich seine spezifischen Fragen stellen und mit seinem spezifischen Wissen die Anforderung erweitern. So wächst der Detaillierungsgrad der Anforderung sukzessive an. 23 Des Weiteren ist zu berücksichtigen, dass im Allgemeinen durch die Diskussion neue Erkenntnisse entstehen, die weiter verarbeitet werden können. Am Ende kann sodann entschieden werden, ob die Anforderung gültig und der Erstellungsprozess abgeschlossen ist. 24 Demgegenüber gibt es auch Probleme, wenn der Entwickler und der Anwender eine unterschiedliche Sprache sprechen. 25 D.h. es gibt eine unterschiedliche Verwendung von Fachtermini. Dies entsteht oft in Software-Projekten, da von Seiten der Entwickler oft künstliche Sprachen verwendet werden, wohingegen die Anwender die natürliche Sprache verwenden. 26 Den Fachtermini kommt aus diesem Grund eine besondere Bedeutung zu. Im Zuge der Kommunikation zwischen den Anwendern und Entwicklern und der späteren Dokumentation ist eine einheitliche Begrifflichkeit anzustreben. Um dies zu erreichen ist es somit erforderlich verwendete Termini, die nicht dem regulären Sprachgebrauch entsprechen, zu defi- 21 Vgl. Goeken 2006 /Data-Warehouse-Systeme/ S Vgl. Goeken 2006 /Data-Warehouse-Systeme/ S Vgl. Koschek 2011 /Anforderungsermittlung/ S Vgl. Koschek 2011 /Anforderungsermittlung/ S Vgl. Koschek 2011 /Anforderungsermittlung/ S Vgl. Goeken 2006 /Data-Warehouse-Systeme/ S

10 nieren. 27 Der Verfasser sieht an dieser Stelle jedoch auch die Notwendigkeit reguläre Termini zu beschreiben, soweit dies der Verständlichkeit nützlich ist Requirements-Management Das Requirements-Management (RM) sorgt dafür, dass die Anforderungen auf dem aktuellen Stand sind und alle am Projekt beteiligten Personen die für sie notwendigen Informationen verfügbar haben. Dabei fokussiert sich das RM auf die Information, nicht auf das Dokument. Das bedeutet, dass alle relevanten Informationen an einer zentralen Stelle verfügbar sein müssen. 28 Dies erfüllt sodann die Verfügbarkeitsbedingung notwendiger Informationen für die im Projekt tätigen Personen. 29 Eine Übersicht der Bereiche des RM ist in Abb. 2 dargestellt. Abbildung 2: Requirements-Management 30 Das RM hat die Aufgabe sicherzustellen, dass die Identifizierbarkeit gewährleistet ist. Dies bedeutet, dass Zuordnungen zu einzelnen Detailinformationen stimmig sind und Nummerierungen nicht redundant sind. Sollte eine Anforderung nicht weiter verfolgt werden, so ist die Nummer zu löschen und die anderen Nummern 27 Vgl. zur Notwendigkeit klarer Terminologien Goeken 2006 /Data-Warehouse-Systeme/ S. 270 ff., der diese Tätigkeit dem Terminologiemanagement zuordnet. 28 Vgl. Hood et al /Requirements Management/ S. 35 f. 29 Vgl. hierzu Kapitel Quelle: Partsch 2010 /Requirements-Engineering/ S

11 sind anzupassen. Hierbei ist darauf zu achten, dass dies durchgängig erfolgt. 31 Dies ist erforderlich, da auch in Software-Projekten nichts so beständig ist, wie der Wandel. Dieser kann ausgelöst werden durch äußere Ereignisse, wie die Finanzkrise oder durch innere Ereignisse, wie personelle Veränderungen, neue Erkenntnisse oder eine Neuausrichtung des Unternehmens. 32 Zusätzlich zur Identifizierbarkeit ist die Filtrierbarkeit wichtig, aufgrund der Notwendigkeit, dass jede Person nur die für sie relevanten Informationen erhält, ist es erforderlich, dass Informationen gefiltert werden können. Beispielsweise möchte ein Test Manager andere Informationen haben als ein Projekt Manager. Die Filtrierbarkeit bezieht sich aber auch auf die möglichen verschiedenen Versionen der Spezifikation 33 einer Anforderung und des hiermit zusammenhängenden Entscheidungsprozesses 34 im Projektverlauf. Auch hier ist eine Filtrierung notwendig. Dabei ist zu berücksichtigen, dass Berechtigungskonzepte abzubilden sind. Bei kritischen Informationen muss es möglich sein, diese nur für bestimmte Personen freizugeben. Wie bereits beschrieben ist die Nachverfolgbarkeit eine Basisvoraussetzung für das RE. 35 Die Nachverfolgbarkeit kann mindestens in zwei Bereiche eingeteilt werden. Zum einen in eine Nachverfolgung von einer spezifischen Anforderung im Zeithorizont und zum anderen in die Nachverfolgung einer spezifischen Anforderung von unterschiedlichen Personen. Beispielsweise in die Beschreibung der Anforderung eines Anwenders und die Anforderungsbearbeitung eines Entwicklers. Dies erfordert somit eine bidirektionale Verknüpfung der Daten. 36 Die gesamte Nachverfolgbarkeit dient im Projekt der Vollständigkeitskontrolle, der Statusverfolgung und der Ermittlung der Auswirkungen von Änderungen Vgl. Hood et al /Requirements Management/ S Vgl. Koschek 2011 /Anforderungsermittlung/ S Vgl. Hood et al /Requirements Management/ S Vgl. Geisser et al /Wikis/ S Vgl. Goeken 2006 /Data-Warehouse-Systeme/ S. 272 f.; speziell zum Change Management vgl. Balzert 2008 /Softwaremanagement/ S. 429 f. 36 Vgl. Hood et al /Requirements Management/ S. 36 f. 37 Vgl. Goeken 2006 /Data-Warehouse-Systeme/ S. 272 f. 7

12 3. Wiki Wiki Web Der Name Wiki 38 stammt von dem hawaiischen Wiki Wiki ab, dies bedeutet schnell. 39 Es geht somit um das schnelle unkomplizierte zur Verfügung stellen von Informationen. Der Name Wiki wird im Folgenden verstanden als die Software selbst im Zusammenhang mit dem Wiki-Konzept der kooperativen Sammlung, Organisation und Bereitstellung von Informationen. Grundsätzlich kann man Wikis für geschlossene Arbeitsgruppen oder für beliebige Anwender über das Web nutzen. Darüber hinaus dienen Wikis als Wissensmanagement-Werkzeug bei Planung, Dokumentation und als Content Management System Hierbei ist zu berücksichtigen, dass es Anforderungen geben kann, die ein reines Content Management System erfordern. Dies ist auf Basis der im Unternehmen vorhandenen Rahmenbedingungen zu entscheiden. 42 Es sei jedoch angemerkt, dass es für die Anwendung als Content Management System bereits Erweiterungen einzelner Wikis gibt. 43 Innerhalb einer Organisation ist es wichtig, das Wissen der Mitarbeiter zu externalisieren. D.h. es sollen Möglichkeiten geschaffen werden das persönliche Wissen niederzuschreiben und so Anderen zugänglich zu machen. Diese können dann prozessuales Wissen und Erfahrungen in der für sie relevanten Art und Weise weiter verarbeiten. 44 Gerade hier können Vorteile ggü. anderen Werkzeugen bei einem Wiki gesehen werden. 38 Das erste Wiki wurde 1995 von Ward Cunningham entwickelt. Vgl. Ebersbach et al /Wiki/ S Vgl. Komus, Wauch 2008 /Wikimanagement/ S Ein Content Management System bildet die Organisationsstruktur in Zusammenhang mit einem Verzeichnis ab. Es geht somit um die Unterstützung des Verwaltungsaufwandes eines Archives für Informationen. Vgl. Gallenbacher 2007 /CMS/ S. 30 ff. 41 Vgl. Ebersbach et al /Wiki/ S Vgl. Vgl. Gallenbacher 2007 /CMS/ S. 37. In Bezug auf einen Abgleich eines Wiki zu einem Content Management System Vgl. Gallenbacher 2007 /CMS/ S. 32 ff. 43 Vgl. zu spezifischen Ausprägungen in den einzelnen Wikis Abruf am Vgl. Komus, Wauch 2008 /Wikimanagement/ S

13 Die Genres in denen ein Wiki eingesetzt wird sind beispielsweise Offene-Punkte- Listen, Referenzen in der Software-Entwicklung oder Ideensammlung, Sitzungsprotokolle und Statusreports im Projektmanagement Standardfunktionen aller Typen von Wikis Es gibt mittlerweile nicht mehr das Wiki, sondern mehrere Abwandlungen 46 für spezifische Anforderungen. 47 Aus diesem Grund werden im Folgenden die Standardfunktionen vorgestellt. Ein Wiki ist ein einfach und leicht zu bedienendes Werkzeug für kooperatives Arbeiten an Texten und Hypertexten. 48 Diese Hypertexte bewirken, dass auf den Seiten Begrifflichkeiten mit den dafür zugehörigen Seiten verknüpft werden können. So kann der Anwender entscheiden, ob er diese Information lesen möchte, bspw. zum besseren Verständnis oder ob er den aktuellen Text weiter folgt. Die in regulären Ausarbeitungen vorhandenen Strukturen mit klaren Zuordnungen von Texten zu einzelnen Themen können so übergangen werden und erleichtern dem Leser die Bearbeitung und das Verständnis. 49 Bei der Bearbeitung können die einzelnen Seiten nicht nur neu erstellt, verändert oder erweitert werden, sondern es können auch Kommentare zu den Seiten verfasst werden. 50 Dies ist sinnvoll, wenn ein Meinungsaustausch erreicht werden soll. Dabei kann für Abstimmungsprozesse einzelner Themen eine eigene Diskussionsseite erstellt werden. Auf dieser Seite können die Inhalte eines Artikels besprochen werden umso zu einem Konsens zu finden. Eine mögliche Diskussion kann darüber hinaus genauso nachvollzogen 51 werden, wie dies bei den regulären Seiten möglich ist Vgl. Blaschke 2008 /Wikis in Organisationen/ S Vgl. zu den verschiedenen Typen von Wikis und den Funktionen Abruf am , dort werden die einzelnen Typen und Funktionen derselben vorgestellt. 47 Vgl. Ebersbach et al /Wiki/ S Vgl. Parson 2011 /Dokumentation/ S Vgl. Ebersbach et al /Wiki/ S. 17 f.; Ebersbach et al /Wiki/ S. 22 f. 50 Vgl. Parson 2011 /Dokumentation/ S Vgl. zur Nachvollziehbarkeit die folgenden Ausführungen. 52 Vgl. Ebersbach et al /Wiki/ S. 69 f. 9

14 Die Seiten können von allen Anwendern erstellt und geändert werden, jedoch ist es auch möglich einzelne Seiten zu sperren. 53 Dies ist notwendig bei Seiten, die nicht der Abstimmung dienen, sondern reinen Informationscharakter haben. Des Weiteren kann es auch Seiten geben, die nur von bestimmten Personen geändert werden sollen oder bereits bearbeitet und verabschiedet sind. Für die Verfolgung der Veränderung im Verlauf auf den Seiten werden sämtliche Veränderungen oder besser gesagt die Vorgängerversionen gespeichert. 54 Nach Ansicht des Verfassers ist es jedoch notwendig eine Beschränkung zu berücksichtigen, da sich das Datenvolumen in komplexen Projekten sonst exponentiell entwickelt. 55 Hierbei ist es möglich Vorgängerversionen und somit den ursprünglichen Inhalt wieder zu speichern als finale Version. Diese Funktion kann als Rollback- Funktion bezeichnet werden. In einigen Typen von Wikis gibt es zusätzlich besondere Funktionen, mit denen Änderungen grafisch dargestellt werden, so dass es nicht notwendig ist zwei Versionen Zeile für Zeile zu Vergleichen. 56 Dies ermöglicht eine spezielle Art der Kommunikation der Anwender 57, die über die Änderungen einen, wenn auch abstrakten, Dialog führen und sich so dem gemeinsamen Ergebnis annähern. 58 Zusätzlich zu dieser Funktion ist es möglich die letzten Änderungen in einem gesonderten übergeordneten Dokument sichtbar zu machen. Dies kann für eine gewisse Anzahl gelten, oder auch für Änderungen in einem bestimmten Zeitraum. Auch bei dieser speziellen Funktion gibt es Typen von Wikis, bei denen ein Anwender gezielt einzelne Artikel nachverfolgen kann. Dies erleichtert einem Projektleiter oder Verantwortlichen für einen Teilbereich die Überprüfung und Transparenz Vgl. Ebersbach et al /Wiki/ S Vgl. Ebersbach et al /Wiki/ S In welchem Rahmen dies erfolgen kann wird hier nicht weiter behandelt. Dies ist bei der Implementierung im Einzelfall zu entscheiden und zu berücksichtigen. 56 Vgl. Ebersbach et al /Wiki/ S Es sei darauf hingewiesen, dass bei einer nachträglichen Änderung durch denselben Anwender keine Kommunikation erfolgen kann, dies kann im Rahmen dieser Arbeit jedoch vernachlässigt werden. 58 Vgl. zur Kommunikation über die Funktion der Veränderungsverfolgung Blaschke 2008 /Wikis in Organisationen/ S Vgl. Ebersbach et al /Wiki/ S. 23 f. 10

15 Sollte ein Anwender einen bestimmten Artikel oder eine Begrifflichkeit suchen, so gibt es die Möglichkeit eine klassische Volltext- oder Titelsuche durchzuführen. Wurde darauf geachtet die Seitentitel eindeutig zu definieren, so kann das Wiki wie ein Karteikartensystem genutzt werden. 60 Darüber hinaus ist es grundsätzlich möglich sämtliche Daten in einem Wiki bereit zu stellen, die auch auf jeder anderen Internetseiten gespeichert werden können. 61 Dies ermöglicht es somit auch andere Werkzeuge und deren Output mit zu berücksichtigen. Bspw. spezielle Formalismen und Konzepte im Requirements- Engineering, wie Ablaufdiagramme, Petrinetze und modellbasierte Beschreibungen. 62 Aufgrund der Wiki-Technologie ist bei einer Anwendung im Intranet oder Internet eine verteilte Bearbeitung möglich. Sollten zwei Anwender gleichzeitig arbeiten, so wird die Seite, welche in Bearbeitung ist, durch den ersten Anwender gesperrt. 63 Dies stellt sicher, dass die o.g. Funktion der Speicherung von Versionen immer eindeutig ist Semantische Wikis Innerhalb einer Gruppe kann es vorkommen, dass das Vokabular, trotz der identischen natürlichen Sprache unterschiedlich ist. Beispielsweise schreibt ein Anwender Präsentation, ein Anderer Praesentation. Dies führt dazu, dass die o.g. Suchfunktionen und auch Zuordnungen in Hypertexten nicht zu 100% funktionieren. Semantische Wikis steuern diesem mit semantischen Technologien entgegen. Das Wiki mit dieser Technologie kann bei einem Eintrag die Wörter überprüfen und 60 Vgl. Ebersbach et al /Wiki/ S Vgl. Bry 2009 /Kreidetafel/ S Vgl. zu den unterschiedlichen Formalismen und Konzepten die Darstellungen in Partsch 2010 /Requirements-Engineering/ S. 69 ff. 63 Vgl. Geisser et al /Wikis/ S

16 eine einheitliche Schreibweise vorschlagen. 64 Somit ist es für die Speicherung von strukturiertem Wissen sinnvoll ein semantisches Wiki zu verwenden. 65 Die o.g. semantischen Technologien können unter dem Begriff des Semantic-Web zusammengefasst werden. Das Semantic-Web hat die Vision die Inhalte einer Internetseite mit einer Maschine erfassen zu können. 66 Als Beispiel für eine derartige Unterstützung kann man das Projekt Semantic Wikipedia betrachten. Ein Anwender kann, wenn er innerhalb eines Textes das Wort Berlin und auch Deutschland liest, erkennen, dass es sich bei Berlin um die Hauptstadt Deutschlands handelt. Ein reguläres Wiki 67 kann dies nicht. Da im regulären Wikipedia 68 keine semantische Funktion verfügbar ist, ist ein zusätzliches Modul entwickelt worden. Das fertige Produkt ist das Semantic MediaWiki, welches eine Erweiterung des MediaWiki darstellt. 69 Durch dieses Modul ist es dem Wiki möglich die Metainformation ist Hauptstadt, gemäß dem o.g. Beispiel, hinzuzufügen. So ist es möglich eine Abfrage der Hauptstädte in Europa zu machen und schnell ein Ergebnis zu erzielen. 70 Die Erweiterung eines Wiki um die semantische Technologie kann als Erweiterung oder Evolution eines Wiki gesehen werden, die Standardfunktionen werden durch diese Erweiterung nicht negativ beeinflusst. Somit ist ein Wiki nicht nur auf die Texterstellung beschränkt, sondern kann auch bei strukturiertem Wissen gute Arbeit leisten. Die hierbei entstehenden Möglichkeiten aus bestehenden Artikel neues Wissen zu generieren werden bestehende Wikis zu mächtigen Datenbanken machen Vgl. Bry 2009 /Kreidetafel/ S. 28 f. 65 Vgl. Geisser et al /Wikis/ S Vgl. Hüner et al /Semantisches Wiki/ S Das Wiki soll hier verstanden werden als die reine Maschine ohne Bezug zu einem Konzept. 68 Wikipedia basiert auf dem MediaWiki. Vgl. Hüner et al /Metadatenmanagement/ S Vgl. Hüner et al /Metadatenmanagement/ S Vgl. Geisser et al /Wikis/ S. 10 f. 71 Vgl. Geisser et al /Wikis/ S

17 4. Wiki im Requirements-Engineering Für das Requirements-Engineering ist es wichtig die richtigen Werkzeuge zu nutzen. Ohne gute Werkzeuge ist ein größeres Projekt kaum händelbar. 72 Im Speziellen für das RE gibt es Werkzeuge, es ist jedoch nach Ansicht des Verfassers zu berücksichtigen, dass diese sehr oft für die Anwender und ggf. in Teilbereichen auch für die Entwickler, neu sind. Ein Wiki ist hingegen bei den Entwicklern bekannt 73 und wird oft im abgegrenzten Bereich der Entwicklung eingesetzt. Dies auch vor dem Hintergrund, dass die agilen Methoden im Bereich der Software-Entwicklung einfache flexible Werkzeuge benötigen. 74 Darüber hinaus haben auch die Anwender durch Wikipedia Kenntnisse dieses Werkzeuges. 75 Dies stellt somit unter der Komplexität eines Software-Projektes eine gute Möglichkeit zur Komplexitätsreduzierung und Nutzung dar. Die Anwender müssen sich nicht in eine neue Software einarbeiten, um in einem Software-Projekt mitarbeiten zu können. Die Mitarbeit ist hierbei unabhängig von Ort und Zeit, durch die Möglichkeit verteilt arbeiten zu können. Daraus folgt, dass ein Wiki gut in internationalen Software-Projekten einsetzbar ist. Mehrere Projektmitglieder können im Team zusammenarbeiten. 76 Auf Basis des oben beschriebenen Anforderungsprozesses ist zu prüfen, in wie weit ein Wiki den Prozess der Anforderungserhebung- und -analyse 77 unterstützen kann Anforderungserhebung und analyse mit einem Wiki Bei der Nutzung eines Wikis für die Anforderungserhebung und analyse kann zu jeder initial entstandenen Anforderung eine eigene Seite aufgemacht werden. 78 Auf dieser Seite kann die Anforderung beschrieben, wichtige zusätzliche Dokumente 72 Vgl. Kittlaus, Rau, Schulz 2004 /Software-Produkt-Management/ S Vgl. Kapitel 2 und die Entstehung des Wiki. Die Nutzung bei Entwicklern ist die Basis der heutigen Wikis. 74 Vgl. Rodé, Schnitter, Wend /IT-Anwendungen/ S Vgl. Komus, Wauch 2008 /Wikimanagement/ S Vgl. Rüping 2011 /Dokumentation/ S Vergleiche zum Prozess Kapitel 2.1. Anforderungserhebung und analyse. 78 Vgl. Geisser et al /Wikis/ S

18 hinzugefügt oder auch verlinkt werden. 79 Zusätzlich zu der reinen Anforderung kann durch die möglichen Kommentare ein Abstimmungsprozess eingeleitet werden. 80 Durch die Standardfunktion der Kommentare und auch der Nachverfolgbarkeit kann somit folgender Prozess durchgeführt werden. 81 Ein Anwender erstellt eine initiale Anforderung an die Software, andere Anwender aus dem Unternehmen können diese lesen und nach ihrer Meinung fehlerhafte Daten ändern oder auch für sie selbst wichtige Punkte ergänzen. Hierbei kann von einer Entscheidungsinstanz 82 die Seite geprüft und nach dem Abstimmungsprozess zur weiteren Verarbeitung gesperrt werden. 83 Durch diese Vorgehensweise werden alle Anwender an dem Prozess beteiligt und das organisationale Wissen genutzt. Des Weiteren ist der Entstehungsprozess immer klar nachvollziehbar. 84 Durch die Abstimmung in der Unternehmung können Fehler vermieden und die teilweise vorhandenen Schwierigkeiten der Externalisierung des Wissens gelöst werden. 85 Bei der Betrachtung Tätigkeit innerhalb der Anforderungserhebung und analyse ist zu erkennen, dass Fachtermini wichtig sind. Gerade in diesem Bereich kann ein Wiki eine sehr gute Unterstützung leisten. Wird ein Glossar erstellt, so können innerhalb der Anforderung auftretende Fachtermini mit einem Hyperlink versehen werden und im Glossar erklärt werden. 86 Für das Glossar selbst gelten die gleichen Funktionen, wie auch für die Anforderung selbst, so dass auch dort Kommentare und Versionen verfügbar sind. Sollte es vorkommen, dass Fachtermini durch Fachtermini erklärt werden, so wird auch dort die Verlinkung angewendet. Dies erleichtert allen Beteiligten das Verständnis in einer heterogenen Gruppe aus Anwendern und Entwicklern. Sollte, als Vergleich, beim RE Büro-Software genutzt werden, liegt die Verantwortlichkeit der Ablage bei den einzelnen Anwendern, Entwicklern und dem Projektlei- 79 Zur Möglichkeit der Verlinkung vgl. Kapitel Vgl. Geisser et al /Wikis/ S Vgl. zu der Möglichkeit der Kommentare und der Nachverfolgbarkeit Kapitel Dies kann der Projektleiter oder anderes organisatorisches Gremium wie bspw. ein Lenkungsausschuss sein. 83 Vgl. zur Möglichkeit der Sperrung einzelner Seiten Kapitel Vgl. Geisser et al /Wikis/ S Vgl. zum Wissensmanagement mit Groupware und Social Software Lehner 2009 /Wissensmanagement/ S. 241 ff. 86 Vgl. Parson 2011 /Dokumentation/ S

19 ter. Folglich kann es vorkommen, dass Änderungen nicht mehr nachvollzogen werden können. 87 Dieses Problem wird bei der Nutzung eines Wikis behoben, da sämtliche Versionen verfügbar sind und so eine Nachverfolgung ermöglicht wird. 88 Auch die gleichzeitige Bearbeitung einer Seite wird durch die Sperrung des ersten Anwenders verhindert. Somit kommt es nicht vor, dass zwei Dokumente 89 mit gleicher Bezeichnung unterschiedliche Inhalte haben. Zusätzlich ist die Verfolgung über den Status der Anforderung möglich, so dass immer klar ist, wie weit die Bearbeitung des Dokuments fortgeschritten ist. 90 Durch die Möglichkeit der Verschlagwortung und der Kategorisierung der Anforderungen kann die Suche innerhalb eines Wiki sehr stark vereinfacht werden. Es ist somit einfach möglich notwendige Informationen über eine Volltextsuche zu suchen. Dies erleichtert ebenfalls die Arbeit im Requirements-Engineering Requirements-Engineering mit einem semantischen Wiki Dem semantischen Wiki kommt innerhalb des Requirements-Engineering eine besondere Bedeutung zu. Es ist durch die semantische Technologie möglich, die entstandenen Anforderungen weiter zu strukturieren und neue Informationen aus den bestehenden Daten zu extrahieren. Hierbei wird die Ermittlung der Sprache nicht ersetzt, sondern erweitert. Der evolutionäre Prozess der Anforderungsabstimmung / -entstehung wird zusätzlich mit berücksichtigt und ermöglicht neue Erkenntnisse. Gerade diese Funktion macht ein Wiki Requirements-Engineering tauglich. Die verwendeten Schlussfolgerungssysteme, Regelsprachen oder deklarative Abfragesprachen ermöglichen die dynamische Generierung von Inhalten oder können für Modelldaten und deren Validierung genutzt werden. 92 Im Zusammenhang mit der Requirements-Engineering ist es auch möglich einzelne ERP- Transaktion mit genutzt in zu integrieren, so dass dies bei der Anforderungser- 87 Vgl. Geisser et al /Wikis/ S. 3 f. 88 Vgl. Ebersbach et al /Wiki/ S Es wird hier nicht von Seite, sondern Dokument gesprochen, da dieses Problem bei einem Wiki nicht auftritt und die Begrifflichkeit Seite in diesem Zusammenhang einen falschen Schluss zulassen würde. Dokumente können sein Excel, Word, PDF und ähnliche Dokumentenarten. 90 Vgl. Parson 2011 /Dokumentation/ S Vgl. Parson 2011 /Dokumentation/ S Vgl. Geisser et al /Wikis/ S

20 hebung und auch der späteren Programmierung verwendet werden kann und ein einheitlicher Bezug besteht Fazit Wie oben dargestellt ist ein Wiki einfach in der Bedienung und eignet sich somit gut für das am Anwender ausgerichtete Requirements-Engineering. Dabei werden die Tätigkeiten unterstützt, die für das RE wichtig und notwendig sind in Verbindung mit neuen Möglichkeiten das Wissen der Anwender zu sammeln, zu strukturieren und eine gemeinsame Sprache zu finden. Aber auch aus Sicht der Entwickler, die traditionell eher weniger an der schriftlichen Aufnahme der Anforderungen interessiert sind und lieber programmieren, stellt ein Wiki eine gute Möglichkeit der Formalisierung der Anforderungen dar. Es sei jedoch angemerkt, dass die Funktionsfähigkeit eines Wiki nicht nur von der Technik abhängt. Wenn ein Wiki im RE eingesetzt wird, so ist es unabdingbar ein klares Vorgehensmodell zu nutzen und ggf. die spezifischen Bedingungen im Einzelfall eines Projektes zu berücksichtigen. 94 Bei der Betrachtung der zukünftigen Entwicklung und den aktuell diskutierten agilen Methoden im Software-Engineering kann ein Wiki, im Speziellen durch die Flexibilität, eine gute Unterstützung leisten. An der Diskussion und der Prüfung der Möglichkeiten der Unterstützung der Dokumentation durch ein Wiki in agilen Projekten kann erkannt werden, dass sich Wikis in einem evolutionären Prozess befinden. 95 Ob es hier in Zukunft ein Wiki für das Software-Engineering oder spezielle Bereiche gibt ist nach Ansicht des Verfassers fraglich, jedoch kann man erkennen, dass Potenziale vorhanden sind, die Software-Projekte erfolgreicher machen können. 93 Vgl. zur Möglichkeit der Verknüpfung der ERP-Transaktion Hüner et al /Metadatenmanagement/ S Vgl. zu einem beispielhaften Vorgehensmodell i.v.m. der Dokumentation in der Software- Entwicklung Parson 2011 /Dokumentation/ S. 42 f. 95 Vgl. zu der Prüfung eines Wiki zur Dokumentation Parson 2011 /Dokumentation/ S. 40 ff.; Rüping 2011 /Dokumentation/ S. 28 ff. 16

Wiki im Requirements-Engineering

Wiki im Requirements-Engineering Daniel Taudien Wiki im Requirements-Engineering Hausarbeit Software-Engineering D. Taudien, Matrikel-Nr. 268783 25.06.2011 Inhaltsverzeichnis Inhaltsverzeichnis... I Abkürzungsverzeichnis... II Abbildungsverzeichnis...

Mehr

Kundenanforderungen dokumentieren

Kundenanforderungen dokumentieren Requirements Engineering Kundenanforderungen dokumentieren Bereich Anforderungen Aktivität Kunden-Anforderungen erheben Ziele Gesteigerte Kundenzufriedenheit Dokumentation der genauen Erwartungen des Kunden

Mehr

KT Communications Engineering

KT Communications Engineering KT Communications Engineering IKT im Kontext von (verteilten) Softwareentwicklungsprojekten Sommersemester 2015 LVA-Nummer: 257.131 LVA-Leiter/in: Florian Krenn, MSc Kontakt: Florian.Krenn@jku.at, (0732

Mehr

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

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

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Dateiname: ecdl5_01_00_documentation_standard.doc Speicherdatum: 14.02.2005 ECDL 2003 Basic Modul 5 Datenbank - Grundlagen

Mehr

Softwareanforderungsanalyse

Softwareanforderungsanalyse Softwareanforderungsanalyse Evolution von Anforderungen Burkhardt Renz Institut für SoftwareArchitektur der Technischen Hochschule Mittelhessen Wintersemester 2015/16 Evolution von Anforderungen Anforderungen

Mehr

IT-Grundschutz-Zertifizierung von ausgelagerten Komponenten

IT-Grundschutz-Zertifizierung von ausgelagerten Komponenten Ergänzung zum Zertifizierungsschema Nr. 1 Titel ITGrundschutzZertifizierung von ausgelagerten Komponenten Status Version 1.0 Datum Diese Ergänzung zum Zertifizierungsschema gibt verbindliche Hinweise,

Mehr

Software Engineering

Software Engineering Software Engineering Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik Prof. A. Müller, FH KL Software Engineering 2015 1 Inhalte Begrüßung Vorstellung, Übersicht Formales

Mehr

Konzeption eines Enterprise 2.0 Projektmanagement - Tool mit Beteiligung diverser Stake Holder. Bachelorarbeit

Konzeption eines Enterprise 2.0 Projektmanagement - Tool mit Beteiligung diverser Stake Holder. Bachelorarbeit Konzeption eines Enterprise 2.0 Projektmanagement - Tool mit Beteiligung diverser Stake Holder Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

Mehr

1. Grundbegriffe des Software-Engineering

1. Grundbegriffe des Software-Engineering 1. Grundbegriffe Software Engineering 1 1. Grundbegriffe des Software-Engineering Was ist Software-Engineering? (deutsch: Software-Technik) Teilgebiet der Informatik, das sich mit Methoden und Werkzeugen

Mehr

Software Engineering. Bibliographisches Institut & F. A. Brockhaus AG, Mannheim; Spektrum Akademischer Verlag GmbH, Heidelberg, 2003

Software Engineering. Bibliographisches Institut & F. A. Brockhaus AG, Mannheim; Spektrum Akademischer Verlag GmbH, Heidelberg, 2003 Software Engineering Softwaretechnik Softwaretechnologie, Software Engineering (engl.) das, -, Teilgebiet der Informatik, das sich mit Methoden und Werkzeugen für das ingenieurmäßige Entwerfen, Herstellen

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 (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

Requirements Management Wissensmanagement für und mit Anforderungen

Requirements Management Wissensmanagement für und mit Anforderungen Requirements Management Wissensmanagement für und mit Anforderungen Barbara Paech Forum ITK-Industrie Industrie trifft Forschung in ViSEK, 28.10.02 IESE Fraunhofer Institut Experimentelles Software Engineering

Mehr

Das Pflichtenheft. Dipl.- Ing. Dipl.-Informatiker Dieter Klapproth Ains A-Systemhaus GmbH Berlin

Das Pflichtenheft. Dipl.- Ing. Dipl.-Informatiker Dieter Klapproth Ains A-Systemhaus GmbH Berlin Fragestellungen: Warum reicht das Lastenheft nicht aus? Was kann ich mit dem Lastenheft machen? Was unterscheidet das Pflichtenheft vom Lastenheft? Was gehört zum Auftragsumfang einer Individualsoftware?

Mehr

Requirements-Management Ein praktisches Beispiel

Requirements-Management Ein praktisches Beispiel 2003 Eurocopter Deutschland GmbH 2003 Requirements-Management Ein praktisches Beispiel a.s.drexler@t-online.de Softwareprozesse in Luft- und Raumfahrtprojekten Workshop der DGLR am 15.10.2003 Der Vortrag

Mehr

BPMN vs. EPK & Co. oder auf was es wirklich ankommt

BPMN vs. EPK & Co. oder auf was es wirklich ankommt BPMN vs. EPK & Co. oder auf was es wirklich ankommt Sebastian Adam, Norman Riegel 15. Mai 2012, St. Augustin Die Fraunhofer-Gesellschaft e.v. Benannt nach: Rolle der FraunhoferGesellschaft: Größe: Forschungsvolumen:

Mehr

Wissensmanagement 2.0.

Wissensmanagement 2.0. Wissensmanagement 2.0. Rahmenbedingungen, Barrieren, Erfolgsfaktoren präsen9ert von Lena Després, ebusiness- Lotse Darmstadt- Dieburg Agenda Vorstellung ebusiness- Lotse Was ist Wissensmanagement? Wie

Mehr

SemanticMediaWiki+ als Wissensplattform für Unternehmen

SemanticMediaWiki+ als Wissensplattform für Unternehmen SemanticMediaWiki+ als Wissensplattform für Unternehmen Zielgruppengerechte Produktion von Trainingsmaterial am Beispiel der UNESCO Daniel Hansch, hansch@ontoprise.de, ontoprise GmbH Hans-Peter Schnurr,

Mehr

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management Anforderungsmanagement im Projekt BIS-BY von B. KREUZER Schlüsselwörter: Änderungswünsche, Anforderungsmanagement, DOORS Kurzfassung Softwaresysteme unterliegen während ihrer Entwicklung und während ihres

Mehr

Anforderungen: Management

Anforderungen: Management Anforderungen: Management Anforderungen: Management Der Begriff der Anforderungsanalyse ist grundsätzlich vom Begriff des Anforderungsmanagements zu trennen, obwohl beide Konzepte in vie l- fältiger Weise

Mehr

Ersatzteile der Extraklasse Magento-Module der Shopwerft

Ersatzteile der Extraklasse Magento-Module der Shopwerft Ersatzteile der Extraklasse Magento-Module der Shopwerft MicroStudio - Fotolia.com E-Mails sind für Online-Shops ein zentrales Mittel in der Kundenkommunikation. Zur Abwicklung von Bestellungen werden

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

Requirements Engineering as a Success Factor in Software Projects

Requirements Engineering as a Success Factor in Software Projects Requirements Engineering as a Success Factor in Software Projects Hubert F. Hofmann, Franz Lehner Vorgetragen von Holger Friedrich Motivation Falsche Anforderungen sind der häufigste Grund für das Scheitern

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

Empfehlung für die technische Kommunikation von Produktänderungen im GDSN

Empfehlung für die technische Kommunikation von Produktänderungen im GDSN 1 Germany Empfehlung für die technische Kommunikation von Produktänderungen im GDSN Version 1.0 Stand Mai 2014 I I I Global Standards. Make Business Efficient. Zielsetzung des Dokuments Ziel der vorliegenden

Mehr

Modellgestütztes Consulting für die Windenergie Ein neuer Ansatz für die Entwicklung

Modellgestütztes Consulting für die Windenergie Ein neuer Ansatz für die Entwicklung für die Windenergie Ein neuer Ansatz für die Entwicklung 1 Umgang mit Informationen Bewältigung von Problemstellungen mit Informationskompetenz Erkennung eines Informationsbedarfes Lokalisierung von Informationen

Mehr

Wo sind meine Anforderungen?

Wo sind meine Anforderungen? Whitepaper Telekommunikation Wo sind meine Anforderungen? Eine effektive Lösung auf Basis von Confluence und JIRA 2011 SYRACOM AG 1 Einleitung Erfahrene Projektmitarbeiter sehen sich oftmals im Projektalltag

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

Software Engineering. 3. Analyse und Anforderungsmanagement

Software Engineering. 3. Analyse und Anforderungsmanagement Software Engineering 3. Analyse und Anforderungsmanagement Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz

Mehr

Workflowmanagement. Business Process Management

Workflowmanagement. Business Process Management Workflowmanagement Business Process Management Workflowmanagement Workflowmanagement Steigern Sie die Effizienz und Sicherheit Ihrer betrieblichen Abläufe Unternehmen mit gezielter Optimierung ihrer Geschäftsaktivitäten

Mehr

Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht. München, 11.03.2014

Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht. München, 11.03.2014 Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht München, 11.03.2014 Vorstellung Ihr Referent Ralf Nagel Senior Consultant für modellbasierte Anforderungsanalyse MID GmbH Kressengartenstraße

Mehr

Produktphilosophie erstellen

Produktphilosophie erstellen User Experience Produktphilosophie erstellen Bereich Anforderungen Aktivität Ziele Erleichterte Kommunikation zwischen Stakeholdern Designentscheidungen erleichtern/rechtfertigen schnell durchführbar einfach

Mehr

WSR 2004. Softwarewartung und Prozessmodelle in Theorie und Praxis. Urs Kuhlmann Andreas Winter

WSR 2004. Softwarewartung und Prozessmodelle in Theorie und Praxis. Urs Kuhlmann Andreas Winter WSR 2004 Softwarewartung und Prozessmodelle in Theorie und Praxis Urs Kuhlmann Andreas Winter Universität Koblenz-Landau 1 Gliederung Wartungsbegriff Prozessmodelle Fallstudien Problembereiche Fazit 2

Mehr

Wirtschaftsingenieurwesen (Informationstechnik) Modulname. Programmierung II / Software Engineering II Modulnummer

Wirtschaftsingenieurwesen (Informationstechnik) Modulname. Programmierung II / Software Engineering II Modulnummer Modulbeschreibung Programmierung II / Software Engineering II Modulname Programmierung II / Software Engineering II Modulnummer -1.2 Inhalt Programmierung II Software Engineering II Grundlagen der objektorientierten

Mehr

Risikomanagement für IT-Projekte: Vergleich von Risiken und Methoden

Risikomanagement für IT-Projekte: Vergleich von Risiken und Methoden Sperrvermerk Risikomanagement für IT-Projekte: Vergleich von Risiken und Methoden Bachelorarbeit Zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

Mehr

Software Requirements Specification

Software Requirements Specification Software Requirements Specification Identifikation von Sehenswürdigkeiten basierend auf Bildinhalten Iterationsschritt: 3 Abgabedatum: 08.06.2010 Gruppe 37: Matthias Hochsteger 0627568 Josef Kemetmüller

Mehr

SmartOffer. Eine werkzeugbasierte Methode zur Vorbereitung von Software Projekten. Universität Trier. Axel Kalenborn & Sebastian Adam

SmartOffer. Eine werkzeugbasierte Methode zur Vorbereitung von Software Projekten. Universität Trier. Axel Kalenborn & Sebastian Adam SmartOffer Eine werkzeugbasierte Methode zur Vorbereitung von Software Projekten Axel Kalenborn & Sebastian Adam Universität Trier Motivation: Phasen der Software Entwicklung Analyse Entwurf Umsetzung

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Herausforderungen beim verteilten RE: Ergebnisse einer Umfrage

Herausforderungen beim verteilten RE: Ergebnisse einer Umfrage Herausforderungen beim verteilten RE: einer Umfrage Andrea Herrmann, Timea Illes-Seifert, Michael Geisser, Tobias Hildenbrand Institut für Informatik Neuenheimer Feld 326 69120 Heidelberg, Germany http://www-swe.informatik.uni-heidelberg.de

Mehr

Dr. Klaus Körmeier BlueBridge Technologies AG

Dr. Klaus Körmeier BlueBridge Technologies AG Dr. Klaus Körmeier BlueBridge Technologies AG Agenda Was ist ein SharePoint Wiki Anwendungsbeispiele und Erweiterungen Was ist beim Einsatz zu beachten Zusammenfassung Partner Partner BlueBridge AG SharePoint-Erfahrung

Mehr

Vorlesung Software-Wartung Änderungs- und Konfigurationsmanagement

Vorlesung Software-Wartung Änderungs- und Konfigurationsmanagement Vorlesung Software-Wartung Änderungs- und Konfigurationsmanagement Dr. Markus Pizka Technische Universität München Institut für Informatik pizka@in.tum.de 3.3 Änderungsmanagement (CM) Evolution der Software

Mehr

DURCHGÄNGIGE SAP CHANGE- UND RELEASE-PROZESSE EINFACH UMSETZEN

DURCHGÄNGIGE SAP CHANGE- UND RELEASE-PROZESSE EINFACH UMSETZEN THEGUARD! SMARTCHANGE CHANGE PROCESS DURCHGÄNGIGE SAP CHANGE- UND RELEASE-PROZESSE EINFACH UMSETZEN DURCHGÄNGIGE SAP CHANGE- UND RELEASE-PROZESSE EINFACH UMSETZEN THEGUARD! SMARTCHANGE I CHANGE PROCESS

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

Wissen statt lernen! Wikis im Behördenumfeld

Wissen statt lernen! Wikis im Behördenumfeld Wissen statt lernen! Wikis im Behördenumfeld Fachtagung Neue virtuelle Welten?! 24. Oktober 2008 Agenda Kurzvorstellung cosinex d-nrw Potentiale der Web 2.0 Technologien Wissen statt lernen! - E- Learning

Mehr

Umsichtig planen, robust bauen

Umsichtig planen, robust bauen Umsichtig planen, robust bauen iks Thementag Mehr Softwarequalität Best practices für alle Entwicklungsphasen 19.06.2012 Autor: Christoph Schmidt-Casdorff Agenda Softwarearchitektur Architekturkonformität

Mehr

Software-Evolution im Staged Lifecycle Model

Software-Evolution im Staged Lifecycle Model Unterstützung evolutionärer Softwareentwicklung durch Merkmalmodelle und Traceability-Links Matthias Riebisch Technische Universität Ilmenau, matthias.riebisch@tu-ilmenau.de Arbeitsgruppe Software-Wartung

Mehr

Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich. Softwaretechnik I

Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich. Softwaretechnik I Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich Softwaretechnik I Wintersemester 2015 / 2016 www.ias.uni-stuttgart.de/st1 st1@ias.uni-stuttgart.de

Mehr

Die Baumschule Optimale Entscheidungsbäume

Die Baumschule Optimale Entscheidungsbäume Christian Gebauer, Sebastian Große, Benjamin Pfeiffer, Nico Smeenk, Jonathan Wiens Im Auftrag von Frau Prof. Dr. Dagmar Monett-Díaz Die Baumschule Optimale Entscheidungsbäume Allgemein Daten der Personen

Mehr

ECM - ein Erfordernis aus technischer Sicht

ECM - ein Erfordernis aus technischer Sicht ECM - ein Erfordernis aus technischer Sicht Compart, 2013 Harald Grumser 1 Die nächsten 40 Minuten Was ist ECM? Schnittstellenprobleme Komponenten im Einzelnen Input meets Output Wohin geht die Reise?

Mehr

Governance, Risk & Compliance für den Mittelstand

Governance, Risk & Compliance für den Mittelstand Governance, Risk & Compliance für den Mittelstand Die Bedeutung von Steuerungs- und Kontrollsystemen nimmt auch für Unternehmen aus dem Mittelstand ständig zu. Der Aufwand für eine effiziente und effektive

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

Stefan Jesse, Sixten Schockert. Nathan Expertise Peter-Schumacher-Straße 50 D-50171 Kerpen {jesse, schockert}@nathan-expertise.de

Stefan Jesse, Sixten Schockert. Nathan Expertise Peter-Schumacher-Straße 50 D-50171 Kerpen {jesse, schockert}@nathan-expertise.de Zertifizierung zum Certified Professional for Requirements Engineering (CPRE) des International Requirements Engineering Board (IREB e.v.): Praxisorientierte Hinweise aus dem Schulungsalltag eines Trainingsproviders

Mehr

Wissensmanagement mit SharePoint. Ein Vortrag von Helmut Reinke MindBusiness GmbH

Wissensmanagement mit SharePoint. Ein Vortrag von Helmut Reinke MindBusiness GmbH Wissensmanagement mit SharePoint Ein Vortrag von Helmut Reinke MindBusiness GmbH 2 Das Prozesshaus als Wissensplattform Projektwissen greifbar machen 3 SharePoint Wiki - Alle wissen Bedeutung Wissen für

Mehr

Softwareentwicklungspraktikum Sommersemester 2007. Feinentwurf

Softwareentwicklungspraktikum Sommersemester 2007. Feinentwurf Softwareentwicklungspraktikum Sommersemester 2007 Feinentwurf Auftraggeber Technische Universität Braunschweig

Mehr

CA Clarity PPM. Übersicht. Nutzen. agility made possible

CA Clarity PPM. Übersicht. Nutzen. agility made possible PRODUKTBLATT CA Clarity PPM agility made possible CA Clarity Project & Portfolio Management (CA Clarity PPM) unterstützt Sie dabei, Innovationen flexibel zu realisieren, Ihr gesamtes Portfolio bedenkenlos

Mehr

White-Paper zur Studie Lean-IT

White-Paper zur Studie Lean-IT White-Paper zur Studie Lean-IT Riesiges Verbesserungspotential in der Durchführung von IT-Projekten In Zusammenarbeit der Universität Hohenheim mit mm1 Consulting & Management Königstraße 10c D-70173 Stuttgart

Mehr

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 348

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 348 DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN Nr. 348 Konzeption eines Projektvorgehensmodells für die Business-Intelligence-Strategieberatung

Mehr

Open Source Knowledge Management

Open Source Knowledge Management Georg Hüttenegger Open Source Knowledge Management Mit 10 Abbildungen und 9 Tabellen 4ü Springer Inhaltsverzeichnis 1 Einleitung 1 1.1 Definitionen (Knowledge, Knowledge Management, Open Source,...) 2

Mehr

Leitfaden zum Erstellen der Projektarbeit

Leitfaden zum Erstellen der Projektarbeit Leitfaden zum Erstellen der Projektarbeit an der Höheren H http://www.slideshare.net www.slideshare.net/rudolpdo/vorgehensweise vorgehensweise-projektarbeit Was ist gefordert? Projektmanagement Unterlagen

Mehr

Das Open Source Content Management System

Das Open Source Content Management System Das Open Source Content Management System Erweiterbarkeit und Individualisierung visions-marketing Unternehmensberatung Alexander Winkler Postfach 950180 81517 München Tel.+Fax: 089 / 38 90 06 53 Mobil.:

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

Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013

Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013 Software Komponenten FS13 Gruppe 03 Horw, 16.04.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Estermann Michael

Mehr

Version 3.2 vom 13.08.2008

Version 3.2 vom 13.08.2008 Dokumentation Bausteine erstellen evolution Version 3.2 vom 13.08.2008 Copyright 2001-2008 dialogue1 GmbH, D-22337 Hamburg Alle Rechte vorbehalten, auch die der Übersetzung, der fotomechanischen Wiedergabe

Mehr

Wiki-Lösungen Wer die Wahl hat, hat die Qual

Wiki-Lösungen Wer die Wahl hat, hat die Qual Wer die Wahl hat, hat die Qual Sven Wartenberg Würth Elektronik ICS GmbH & Co. KG 74613 Öhringen Sven.Wartenberg@we.online.de Gefördert durch: Seite 1 Inhalt 1 Ausgangssituation 2 3 Vorgehen/Lösungen Erfahrungen/Fazit

Mehr

Softwaretechnik WS 2013/14. Fomuso Ekellem

Softwaretechnik WS 2013/14. Fomuso Ekellem WS 2013/14 Organisatorisches Dozentin : Ango (Raum 2.250) Fragen und Übungen: mathe_ekellem@yahoo.com (Nur hier, sonst wird nicht bewertet) Folien: http://www.gm.fh-koeln.de/~afomusoe/softwaretechnik.html

Mehr

---------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------- Webauftritt meiner Schule via CMS System Joomla! Dieser Arbeitskatalog hilft dir notwendige Arbeiten zu strukturieren. Grundsätzliches Das CMS System Joomla trennt strikt Content (Inhalte, Fotos, ) und

Mehr

Markup-basiertes Spezifikationsund Anforderungsmanagement in agilen Softwareprojekten

Markup-basiertes Spezifikationsund Anforderungsmanagement in agilen Softwareprojekten Roman Roelofsen Prof. Dr. Stephan Wilczek Markup-basiertes Spezifikationsund Anforderungsmanagement in agilen Softwareprojekten Konferenz Software Engineering & Management 2015 Dresden 19.03.2015 3 Rollen

Mehr

Content Management Datenbanken, Schnittstellen

Content Management Datenbanken, Schnittstellen Unterschiedlichste Informationen übersichtlich organisiert sypress Content Management Systemgruppe sypress bietet Ihnen Produkt oder Themen bezogen die Verwaltung beliebiger Inhalte. Die Speicherung erfolgt

Mehr

Leitfaden zur Anlage einer Nachforderung. Nachforderung. 04.04.2013 Seite 1 von 11 RWE IT GmbH

Leitfaden zur Anlage einer Nachforderung. Nachforderung. 04.04.2013 Seite 1 von 11 RWE IT GmbH Leitfaden zur Anlage einer 04.04.2013 Seite 1 von 11 Inhaltsverzeichnis 1 Aufruf des RWE smanagements...3 2 Eingabe der Benutzerdaten...4 3 Erfassen der...5 4 Neue...6 4.1 Allgemeine Daten...7 4.2 Beschreibung...7

Mehr

Wikis für Technische Dokumentation einsetzen

Wikis für Technische Dokumentation einsetzen Wikis für Technische Dokumentation einsetzen Auf dem Weg zur Dokumentation 2.0? 1 Agenda Sind Wikis geeignet für Technische Doku? Möglichkeiten und Grenzen Wie mache ich mein Wiki zum Erfolg? Wie komme

Mehr

Maintenance & Re-Zertifizierung

Maintenance & Re-Zertifizierung Zertifizierung nach Technischen Richtlinien Maintenance & Re-Zertifizierung Version 1.2 vom 15.06.2009 Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 22899 9582-0

Mehr

SiteAudit Knowledge Base. Move Add Change Tracking. Vorteile Übersicht. In diesem Artikel: Vorteile Übersicht Funktionsübersicht Berichte anpassen

SiteAudit Knowledge Base. Move Add Change Tracking. Vorteile Übersicht. In diesem Artikel: Vorteile Übersicht Funktionsübersicht Berichte anpassen SiteAudit Knowledge Base Move Add Change Tracking Dezember 2010 In diesem Artikel: Vorteile Übersicht Funktionsübersicht Berichte anpassen MAC Benachrichtigungen Vorteile Übersicht Heutzutage ändern sich

Mehr

Open Source Knowledge Management

Open Source Knowledge Management Georg Hüttenegger Open Source Knowledge Management Mit 10 Abbildungen und 9 Tabellen Springer Einleitung 1 1.1 Definitionen (Knowledge. Knowledge Management, Open Souree,... ) 2 1.1.1 Definition von Knowledge

Mehr

Die neue ISO 9001:2015 Neue Struktur

Die neue ISO 9001:2015 Neue Struktur Integrierte Managementsysteme Die neue ISO 9001:2015 Neue Struktur Inhalt Neue Struktur... 1 Die neue ISO 9001:2015... 1 Aktuelle Status der ISO 9001... 3 Änderungen zu erwarten... 3 Ziele der neuen ISO

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

W I S S E N M I T W I K I S

W I S S E N M I T W I K I S W I S S E N M I T W I K I S Ingenieurbüro für D i p l. - I n g. P e t e r L e h m a c h e r S t e t t i n e r S t r a ß e 1 7, 5 3 1 1 9 B o n n w w w. t e c h n i k - v e r s t e h e n. d e Wissen und

Mehr

Ein pragmatischer Ansatz zur Entwicklung situationsgerechter Entwicklungsmethoden. Michael Spijkerman 27.02.2013

Ein pragmatischer Ansatz zur Entwicklung situationsgerechter Entwicklungsmethoden. Michael Spijkerman 27.02.2013 Ein pragmatischer Ansatz zur Entwicklung situationsgerechter Entwicklungsmethoden Michael Spijkerman 27.02.2013 Methodenentwicklung in s-lab Projekten Strukturierte Entwicklungsmethoden ermöglichen bessere

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

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

Digitale Betriebsprüfung

Digitale Betriebsprüfung Digitale Betriebsprüfung 1 Digitale Betriebsprüfung Warum digitale Betriebsprüfung: Die digitale Betriebsprüfung ergänzt die bisherige Form der Betriebsprüfung. Seit dem 01.01.2002 sind alle Unternehmen,

Mehr

Drei Jahre mit Polarion bei Fresenius Medical Care. Stuttgart, Oktober 2012

Drei Jahre mit Polarion bei Fresenius Medical Care. Stuttgart, Oktober 2012 Drei Jahre mit Polarion bei Fresenius Medical Care Stuttgart, Oktober 2012 Polarion Users Conference 2012, Drei Jahre mit Polarion bei Fresenius Medical Care, Jürgen Lehre (c) Copyright 31/08/2012 Fresenius

Mehr

d e S I G n & d e v e L O P M e n T TYPO3 AdvAnced

d e S I G n & d e v e L O P M e n T TYPO3 AdvAnced DESIGN & DEVELOPMENT TYPO3 Advanced 1 Einleitung / Inhalt 2 / 13 Einleitung Dieses Dokument weist Sie durch die Funktion des Open Source CMS TYPO3. In wenigen, einfachen Schritten wird Ihnen bebildert

Mehr

- Planung und Steuerung: Risikoliste - Code-Generator für die Erstellung einer Lebenslaufakte. Version: 1.0. Nicole Scheeren

- Planung und Steuerung: Risikoliste - Code-Generator für die Erstellung einer Lebenslaufakte. Version: 1.0. Nicole Scheeren - Planung und Steuerung: Risikoliste - Code-Generator für die Erstellung einer Lebenslaufakte Version: 1.0 Projektbezeichnung Projektleiter Verantwortlich Erstellung einer Lebenslaufakte Nicole Scheeren

Mehr

Dokumentation. Projekt: Innovation Management Plattform To Activate Creative Thoughts

Dokumentation. Projekt: Innovation Management Plattform To Activate Creative Thoughts Dokumentation Projekt: Innovation Management Plattform To Activate Creative Thoughts Betreuer: Dr. Joachim Kurzhöfer, Stefan Wunderlich, Jens Siewert Referentin: Yaping Lian Gliederung Einleitung: Agiles

Mehr

Wikis als Wissensmanagement-Tool für Bibliotheken ein Praxisbericht

Wikis als Wissensmanagement-Tool für Bibliotheken ein Praxisbericht Wikis als Wissensmanagement-Tool für Bibliotheken ein Praxisbericht Mag. (FH) Michaela Putz Wirtschaftsuniversität Wien 12. Österreichisches Online-Informationstreffen / 13. Österreichischer Dokumentartag

Mehr

Referent: Alessandro Arrigo AAM1. Professor: Prof. Dr. Heindl. Furtwangen, 2.7.2009

Referent: Alessandro Arrigo AAM1. Professor: Prof. Dr. Heindl. Furtwangen, 2.7.2009 - Entwicklungsprozess - Referent: Alessandro Arrigo AAM1 Professor: Prof. Dr. Heindl Furtwangen, 2.7.2009 Agenda 1. Vorstellung des Autors 2. Das Buch 3. Inhalt des Kapitels 4. Verwendung in anderer Literatur

Mehr

Wiki Software. Das Wiki Konzept. Entdecke die Möglichkeiten. Vortrag von Christoph Sauer i3g Institut Hochschule Heilbronn www.i3g.hs-heilbronn.

Wiki Software. Das Wiki Konzept. Entdecke die Möglichkeiten. Vortrag von Christoph Sauer i3g Institut Hochschule Heilbronn www.i3g.hs-heilbronn. Das Wiki Konzept Wiki Software Entdecke die Möglichkeiten Vortrag von Christoph Sauer i3g Institut Hochschule Heilbronn www.i3g.hs-heilbronn.de Christoph Sauer, i3g Institut Wiki Software Entdecke die

Mehr

intence automotive electronics Ausführbare Spezifikation Der Weg zu besseren Anforderungen

intence automotive electronics Ausführbare Spezifikation Der Weg zu besseren Anforderungen intence automotive electronics Ausführbare Spezifikation Der Weg zu besseren Anforderungen Kurzvorstellung intence Agenda KURZVORSTELLUNG intence automotive electronics Wurde 2007 gegründet und ist Entwicklungspartner

Mehr

Pflichtenheft 1 Allgemeines 1.1 Nutzen

Pflichtenheft 1 Allgemeines 1.1 Nutzen Pflichtenheft 1 Allgemeines Oft wird im Bereich der Softwareentwicklung auf die Erstellung eines Pflichtenheftes verzichtet. Die Gründe sind dafür die Befürchtungen, dass sich dadurch die Entwicklung verzögert

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

Microsoft Solutions Framework. Daniel Dengler CN7. Unterschied MSF - MOF Microsoft Solutions Framework

Microsoft Solutions Framework. Daniel Dengler CN7. Unterschied MSF - MOF Microsoft Solutions Framework Einführung MSF MOF Microsoft Solutions Framework Microsoft Operations Framework Daniel Dengler CN7 Agenda Unterschied MSF - MOF Microsoft Solutions Framework Elementare Komponenten grundlegende Richtlinien

Mehr

ITIL und Entwicklungsmodelle: Die zwei Kulturen

ITIL und Entwicklungsmodelle: Die zwei Kulturen Kombination von IT Service Management (ITIL) und Anwendungsentwicklung Kai Witte und Matthias Kaulke, München, den 30.03.2006 Rahmeninformationen Wo sind wir? Unternehmensdarstellung (1) Unabhängiges Beratungsunternehmen

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

Softwaretechnik (Allgemeine Informatik) Überblick

Softwaretechnik (Allgemeine Informatik) Überblick Softwaretechnik (Allgemeine Informatik) Überblick 1 Einführung und Überblick 2 Abstraktion 3 Objektorientiertes Vorgehensmodell 4 Methoden der Anforderungs- und Problembereichsanalyse 5 UML-Diagramme 6

Mehr

Requirements Engineering I. Verwalten von Anforderungen!

Requirements Engineering I. Verwalten von Anforderungen! Martin Glinz Requirements Engineering I Kapitel 14 Verwalten von Anforderungen! 2010-2011 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen Gebrauch

Mehr

Software Engineering

Software Engineering Literatur Gliederung Software Engineering Herbert Kuchen Universität Münster Di+Fr 14:15-15:45, M2 Wintersemester 2009/2010 1 Literatur Gliederung Basis-Literatur H. Balzert: Lehrbuch der Software-Technik,

Mehr

Einführung in die Softwareentwicklung

Einführung in die Softwareentwicklung Einführung in die Softwareentwicklung Thorsten Lemburg Universität Hamburg Seminar: Softwareentwicklung in der Wissenschaft 1 / 53 Einführung in die Softwareentwicklung - Thorsten Lemburg Gliederung 1.

Mehr

Die Informations- und Archivierungs-Software, für die sich führende Immobiliengesellschaften Europas entschieden haben.

Die Informations- und Archivierungs-Software, für die sich führende Immobiliengesellschaften Europas entschieden haben. Die Informations- und Archivierungs-Software, für die sich führende Immobiliengesellschaften Europas entschieden haben. Die optimale Projekt- und Objekt-Verwaltung Das Leistungsspektrum Die örtliche Trennung

Mehr