Auflistung nach:
Auflistung Softwaretechnik-Trends 33(1) - 2013 nach Erscheinungsdatum
1 - 10 von 17
Treffer pro Seite
Sortieroptionen
- ZeitschriftenartikelPartizipation von Fachabteilungen in Requirements-Engineering-Prozessenfür kaufmännische Anwendungen in KMU(Softwaretechnik-Trends: Vol. 33, No. 1, 2013) Weißbach, Rüdiger
- ZeitschriftenartikelTooling zur schrittweisen methodischen Fundierung des RE in KMU(Softwaretechnik-Trends: Vol. 33, No. 1, 2013) Merten, Thorsten; Bürsner, SimoneThorsten Merten und Simone B¨ ursner
- ZeitschriftenartikelNeuer Arbeitskreis „Requirements Engineering Lehre“(Softwaretechnik-Trends: Vol. 33, No. 1, 2013) Herrmann, Andrea; Weißbach, Rüdiger
- ZeitschriftenartikelLeichtgewichtige Traceability im agilen Entwicklungsprozess am Beispiel von Scrum(Softwaretechnik-Trends: Vol. 33, No. 1, 2013) Bouillon, Elke; Güldali, Baris; Herrmann, Andrea; Keuler, Thorsten; Moldt, Daniel; Riebisch, MatthiasElke Bouillon1, Baris Güldali2, Andrea Herrmann3, Thorsten Keuler4, Daniel Moldt5, Matthias Riebisch6 1 Technische Universität Ilmenau, elke.bouillon@tu-ilmenau.de 2 s-lab Software Quality Lab/Universität Paderborn, bguldali@s-lab.upb.de 3 Freie Software Engineering Trainerin und Forscherin, herrmann@herrmann-ehrlich.de 4 Fraunhofer IESE, Thorsten.keuler@iese.fraunhofer.de 5 Universität Hamburg, moldt@informatik.uni-hamburg.de 6 Universität Hamburg, riebisch@informatik.uni-hamburg.de Motivation Einer der wichtigsten Erfolgsfaktoren der agilen Softwareentwicklung ist die schnelle und unkomplizierte Verteilung von Informationen. Dabei reicht das Spektrum der Informationsverteilung von einfachen Dokumenten über Wikis, Videos und Telefonaten bis hin zum 'Face-to-Face' Gespräch. In der traditionellen Softwareentwicklung lag der Fokus typischerweise auf einer dokument-basierten Erfassung und Verteilung von Informationen. Explizite Dokumentation beruht auf der Annahme, dass sich die festgehaltenen Informationen nur in bestimmtem Maße ändern. Da dieser Umstand insbesondere in der Softwareentwicklung nicht automatisch gegeben ist, hat man dies im Kontext der agilen Vorgehensweisen als ein Kernproblem von schwergewichtigen Prozessen identifiziert. Als Konsequenz dazu wird in der agilen SoftwareEntwicklung der Umfang der Dokumentation minimiert. Dies spiegelt sich im Manifest für Agile Software-Entwicklung wider (s. agilemanifesto.org): Obwohl die umfassende Dokumentation als wichtig erachtet wird, wird der Wert funktionierender Software höher eingeschätzt. Nach den zwölf inizialen Prinzipien hinter dem Agilen Manifest gilt die direkte persönliche Übermittlung als effizientestes und effektivstes Verfahren. Funktioniert diese Kompensation besonders gut solange die Entwickler möglichst nah zusammen arbeiten, so ergeben sich jedoch Herausforderungen beim Versuch, agile Entwicklung in mehreren Teams und Standorten zu realisieren. Insbesondere fehlt es in der aktuellen Praxis an Techniken, welche die Dokumentation und Traceability der Entwicklungsartefakte optimal unterstützen. Somit kann es in der Praxis vorkommen, dass Anforderungen oder Entwurfsentscheidungen dem Rest des Teams nicht mitgeteilt werden und diese Wissenslücke die weiteren Implementierungs- und Testaktivitäten negativ beeinflusst. Unsere Hypothese ist es, dass es sinnvoll ist, Traceability in einem agilen Projekt zu unterstützen. Dies ist nach unserer Meinung notwendig, sobald ein Projekt eine Größe überschritten hat, bei der noch jedes Teammitglied das gesamte System überschauen kann oder wo ein persönlicher Kontakt, z.B. aufgrund der Laufzeit eines Projektes und der räumlichen, organisatorischen oder zeitlichen Verfügbarkeit von Personen, nicht mehr gegeben ist. TraceabilityInformationen unterstützen den Projekterfolg durch eine Überprüfung der Abdeckung (beispielsweise der User Stories durch Code und Testfälle), das Konservieren von Entscheidungen, das Unterstützen von Entscheidungsfindungen sowie die Weitergabe von Wissen, z.B. bei der Einarbeitung neuer Teammitglieder. Der Arbeitskreis 'Traceability' der GI-Fachgruppe 'Architektur' arbeitet aktuell an einem Ansatz für die Integration von Traceability in die agile Entwicklung. Der zu entwickelnde Ansatz soll leichtgewichtig sein und keine / möglichst wenige neue Artefakte in die agile Entwicklung einbringen, sondern die vorhandenen Artefakte nutzen und verbinden. Der Ansatz soll unabhängig von einem konkreten agilen Vorgehen sein, auch wenn wir ihn am Beispiel von Scrum entwickeln und darstellen. Wir stellen hier den aktuellen Stand unserer Überlegungen dar und die weitere geplante Arbeit. Lösung: Konzept und Werkzeugunterstützung Wie in Abbildung 1 dargestellt, sieht der ScrumProzess folgende Artefakte zur Erfassung der Anforderungen und zur Dokumentation der Entwicklungsvorgänge vor: Produkt-Backlog (PB), Sprint-Backlog (SB), Sprint-Tasks (ST). Die Entwickler setzen die Implementierungsaufgaben um, die in STs festgehalten werden, und checken ihren Code (Daily Results DR) täglich ins Code-Repository ein. Im Laufe des Sprints werden die DRs zu funktionellen Inkrementen (I) zusammengefügt. Die Inkremente aus mehreren Sprints werden nach und nach integriert und ergeben am Ende des Projektes das fertige Produkt (P). Zur Validierung gegen die Implementierungsvorgaben werden die Codeteile nach jeder Entwicklungsphase getestet, z.B. mittels Continuous Integration oder nach Projektkonvention. Die DRs werden mittels Unit-Testfälle (UT) geprüft. Das Inkrement wird am Ende eines Sprints mittels Integrationstestfällen (IT) und Regressionstestfällen
- ZeitschriftenartikelDie IBIS- Methode(Softwaretechnik-Trends: Vol. 33, No. 1, 2013) Hess, Anne; Maier, Andreas; Löffler, Diana
- ZeitschriftenartikelVon der Idee zum Anforderungsmodell ohne Medienbruch(Softwaretechnik-Trends: Vol. 33, No. 1, 2013) Wüest, Dustin; Seyff, Norbert; Glinz, MartinDustin Wüest, Norbert Seyff, Martin Glinz Universität Zürich, Requirements Engineering Research Group, Binzmühlestrasse 14, 8050 Zürich, Schweiz Email: wueest@ifi.uzh.ch, seyff@ifi.uzh.ch, glinz@ifi.uzh.ch Motivation und Problem In frühen Projektphasen sind Kreativität sowie das Skizzieren und Austauschen von Ideen oft wichtige Bestandteile der Anforderungsermittlung [2]. Modellierungswerkzeuge wie z.B. UML-Tools werden in diesen Phasen oft nicht verwendet, weil sie bedingt durch die Formalität der jeweils unterstützten Notation nicht flexibel genug sind, um verschiedene Sachverhalte schnell und simpel darstellen zu können. Des Weiteren werden diese Notationen oft nicht von allen Interesseneignern verstanden. Oftmals werden freie Skizzen auf Papier oder Whiteboards zum Dokumentieren und initialen Modellieren von Anforderungen verwendet [3]. Dies erleichtert allen Projektbeteiligten den Zugang und unterstützt auch die Kreativität. Solche Diagramme können auf beliebigen Abstraktionsebenen und unter Verwendung verschiedener Notationen gezeichnet werden. Für die Spezifikation und das Management von Anforderungen müssen diese Diagramme dann aber in einer maschinell verarbeitbaren Form vorliegen. Das heißt, dass zu einem späteren Zeitpunkt die auf Papier oder Whiteboard skizzierten Modelle von Grund auf neu erstellt werden müssen. Dazu benutzt der Anforderungsanalytiker meist ein (halb-)formales Modellierungstool. Zwischen den initial skizzierten Diagrammen und den mit Hilfe von Werkzeugen erstellten Modellen entsteht somit ein Medienbruch. Ebenso ist das Erstellen der neuen Modelle zeitintensiv und fehleranfällig. Der Kontext, in dem die Zeichnungen entstanden sind, ist inzwischen möglicherweise nicht mehr ersichtlich, wodurch diese verschieden interpretiert und falsch übersetzt werden können. Flexibles Modellieren im RE Unsere aktuelle Forschung befasst sich mit einem Ansatz, welcher eine softwareunterstützte Alternative zu Papier und Whiteboards bietet [1]. Unter Verwendung dieses Ansatzes können diagrammähnliche Anforderungsskizzen halbautomatisch in halbformale Modelle transformiert werden, indem sie schrittweise verfeinert und formalisiert werden. Das erlaubt freies Zeichnen, und bei Bedarf kann den gezeichneten Symbolen jederzeit eine Bedeutung durch das Definieren von Syntax und/oder Semantik zugeordnet werden. So werden aus Skizzen Modelle; ein Medienbruch entfällt. Auf diese Weise können außerdem auch domänenspezifische Modellierungssprachen erstellt werden. Im Gegensatz zu anderen Lösungen (z.B. [4]) muss hier die Sprache also nicht bereits definiert sein, bevor man mit der eigentlichen Modellierung beginnen kann was ein sehr flexibles Modellieren ermöglicht. Unter der Annahme, dass die in frühen Projektphasen verwendeten Notationen nicht zu komplex ausfallen, erlaubt dieses Vorgehen das Erstellen von Modellierungssprachen auch durch Anforderungsanalytiker, welche keine Experten in Bezug auf Metamodellierung sind. Der Erfolg unseres Ansatzes hängt neben methodischen Herausforderungen auch von der Gebrauchstauglichkeit eines möglichen Werkzeugs ab. Deshalb haben wir einen Prototypen, FlexiSketch, entwickelt. Flexibles Modellieren bedeutet für uns, dem Benutzer nicht nur freie Wahl bezüglich Notation zu lassen, sondern auch, wo und wann er/sie Anforderungsdiagramme zeichnen will. Daher haben wir FlexiSketch für auf Android 3.0+ basierende Tablet-Computer entwickelt (FlexiSketch ist auf Google Play verfügbar). Der Prototyp erlaubt dem Benutzer das Ausführen von drei wesentlichen Aktivitäten [1]: das Skizzieren beziehungsweise Modellieren von Anforderungen, das Klassifizieren und Wiederverwenden von Symbolen als erster Schritt der Metamodellierung, und das automatische Erkennen sowie Ersetzen von ähnlichen Symbolen mittels Sketch Recognition. Nachfolgend beschreiben wir FlexiSketch kurz. Skizzieren/Modellieren. Das GUI ist minimalistisch gehalten und beschränkt sich auf das Wesentliche. Wenn unser Prototyp gestartet wird, zeigt er eine leere, weiße Fläche an, die zu freiem Zeichnen animieren soll. Zusätzliche Funktionalitäten verstecken sich in Kontextmenüs und ausklappbaren Registern (Abbildung 1). Jedes Mal, wenn der Benutzer beim Zeichnen eine Pause einlegt, verwandelt FlexiSketch die zuletzt gezeichneten Striche in ein separates Symbol (oder in eine gerade Verbindungslinie, falls ein Strich zwischen zwei Symbolen gemalt wurde). Symbole sind eigenständige Objekte, die selektiert und manipuliert (z.B. verschoben, skaliert) werden können. Metamodellierung. Symbole können über ihr Kontextmenü klassifiziert werden. Alle klassifizierten Symbole werden in ein Register auf der Seite des Bildschirms kopiert. Diese Symbole bilden dann sozusagen das Grundvokabular der Modellierungssprache. Per 'Drag & Drop' können Kopien dieser Symbole auf die Zeichenfläche gezogen werden. Sketch Recognition. Die vom Benutzer klassifizierten Symbole stellen die Grundlage für die automatische Erkennung weiterer Symbole dar. Zeichnet der Benut-
- ZeitschriftenartikelMit Versionierungsinformationen im Requirements Interchange Format (ReqIF) echte Wiederverwendung von Anforderungen erreichen(Softwaretechnik-Trends: Vol. 33, No. 1, 2013) Alt, OliverDr.-Ing. Oliver Alt LieberLieber Software GmbH Handelskai 340/5, A-1020 Wien Oliver.Alt@lieberlieber.com
- ZeitschriftenartikelWie viel Usability-Engineering braucht das Requirements-Engineering?(Softwaretechnik-Trends: Vol. 33, No. 1, 2013) Popp, Monika; Rupp, Chris
- ZeitschriftenartikelEin automatisiert überprüfbares Qualitätssicherungsmodell für textuelle Anforderungen(Softwaretechnik-Trends: Vol. 33, No. 1, 2013) Stoyanova, NadyaNadya Stoyanova
- ZeitschriftenartikelUNICASE Trace Client: (Semi-) Automatic Tracing of Requirements and Code During Development for Small and Medium Enterprises(Softwaretechnik-Trends: Vol. 33, No. 1, 2013) Delater, Alexander; Paech, BarbaraAlexander Delater, Barbara Paech Institute of Computer Science, University of Heidelberg, Im Neuenheimer Feld 326, 69120 Heidelberg, Germany {delater, paech}@informatik.uni-heidelberg.de