Autor*innen mit den meisten Dokumenten
Auflistung nach:
Neueste Veröffentlichungen
- ZeitschriftenartikelmConcAppt — Methode zur Konzeption von mobilen Business Apps(Softwaretechnik-Trends: Vol. 33, No. 1, 2013) Hess, Steffen
- ZeitschriftenartikelBest Practices für den Umgang mit Macht und Politik im Requirements Engineering(Softwaretechnik-Trends: Vol. 33, No. 1, 2013) Herrmann, Andrea; Merten, Alexander-Marc1
- 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
- ZeitschriftenartikelEin automatisiert überprüfbares Qualitätssicherungsmodell für textuelle Anforderungen(Softwaretechnik-Trends: Vol. 33, No. 1, 2013) Stoyanova, NadyaNadya Stoyanova
- ZeitschriftenartikelRequirements Engineering und Projektmanagement: Erfahrungen mit der Suche nach Best Practices(Softwaretechnik-Trends: Vol. 33, No. 1, 2013) Knauss, Eric; Herrmann, Andrea; Fahney, Ralf; Gartung, Thomas; Glunde, Jörg; Hoffmann, Anne; Valentini, Uwe; Weißbach, RüdigerEric Knauss1, Andrea Herrmann2, Ralf Fahney3, Thomas Gartung , Jörg Glunde5, Anne Hoffmann6, Uwe Valentini7, Rüdiger Weißbach8 1 University of Victoria, knauss@computer.org 2 Freie Software Engineering Trainerin und Forscherin, herrmann@herrmann-ehrlich.de 3 Fahney Anforderungsingenieurwesen GmbH, rf@fahney.com 4 STRABAG Property and Facility Services GmbH, thomas.gartung@strabag-pfs.com 5 Zeppelin Baumaschinen GmbH, joerg@glunde.net 6 anne.hoffmann@web.de, 7 HOOD GmbH, Uwe.Valentini@hood-group.com 8 Hochschule für Angewandte Wissenschaften Hamburg, ruediger.weissbach@haw-hamburg.de
- ZeitschriftenartikelWie viel Usability-Engineering braucht das Requirements-Engineering?(Softwaretechnik-Trends: Vol. 33, No. 1, 2013) Popp, Monika; Rupp, Chris
- ZeitschriftenartikelDie IBIS- Methode(Softwaretechnik-Trends: Vol. 33, No. 1, 2013) Hess, Anne; Maier, Andreas; Löffler, Diana
- 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
- ZeitschriftenartikelModellbasierte Priorisierung in geschäftsprozessgetriebener Softwareentwicklung(Softwaretechnik-Trends: Vol. 33, No. 1, 2013) Riegel, NormanNorman Riegel Fraunhofer Institut für Experimentelles Software Engineering IESE, DE-67663 Kaiserslautern, norman.riegel@iese.fraunhofer.de Einleitung Viele Entwicklungsprojekte im Bereich Informationssysteme zielen darauf ab, die Geschäftsprozesse eines Unternehmens zu unterstützen und den Geschäftsbetrieb zu optimieren. In diesen Projekten spielt geschäftsprozessgetriebenes Requirements Engineering (Business-Process-Driven Requirements Engineering, kurz BPRE) eine große Rolle, welches Geschäftsprozessdesign und Requirements Engineering vereint [1]. Dabei beginnt die Anforderungserhebung typischerweise mit der Identifizierung und Analyse der Geschäftsprozesse, von welchen sukzessive detailliertere Anforderungen (bspw. Beschreibung von Geschäftsaktivitäten, detaillierte Systemfunktionen) auf verschiedenen Abstraktionsebenen abgeleitet werden. Dadurch steigt die Zahl der Anforderungen signifikant während der Verfeinerung an, was in Abbildung 1 veranschaulicht ist. Da selbst in kleinen und mittelständigen Unternehmen mehrere dutzend Geschäftsprozesse vorliegen, ist es unabdingbar, die Anforderungserhebung zu fokussieren, um den dafür nötigen Aufwand gering zu halten. Typischerweise werden hierfür Priorisierungstechniken eingesetzt, um sich auf diejenigen Anforderungen zu konzentrieren, welchen den höchsten Wert hinsichtlich gewisser Kriterien, wie beispielsweise Nutzen-KostenVerhältnis, versprechen. In der Literatur sind zahlreiche verschiedene Priorisierungsansätze beschrieben, welche sich beispielsweise hinsichtlich ihrer Komplexität oder ihrer Bewertungs- und Berechnungsart unterscheiden (siehe z.B. [2]). Es hat sich jedoch gezeigt, dass die Anwendung dieser Methoden in der Praxis problematisch ist. Die Techniken lassen sich nicht auf den oben skizzierten Kontext anpassen und können nicht so zugschnitten werden, um das Priorisierungsproblem adäquat zu lösen [3]. Dies hat zur Konsequenz, dass Aufwände in (Requirements Engineering) Aktivitäten von geringem Wert fließen. Dies äußerst sich beispielsweise in der Durchführung von Workshops und Interviews, welche sich im Nachhinein als unnötig herausstellen oder in der Spezifikation von erhobenen Anforderungen, deren Nutzen später als gering eingeschätzt wird. In dieser Forschungs-Vorschau wird die Idee eines Priorisierungsframeworks vorgestellt, welches das vorgestellte Priorisierungsproblem im Rahmen geschäftsprozessgetriebener Softwareentwicklung lösen soll.