Auflistung nach:
Auflistung Softwaretechnik-Trends 34(1) - 2014 nach Erscheinungsdatum
1 - 10 von 14
Treffer pro Seite
Sortieroptionen
- ZeitschriftenartikelUnterstützung von KMU bei der Erbringung komplexer Mobilitäts-Services(Softwaretechnik-Trends: Vol. 34, No. 1, 2014) Pelzl, Norman; Schockert, Sixten; Helferich, AndreasNorman Pelzl, Sixten Schockert Universität Stuttgart, Betriebswirtschaftliches Institut, Lehrstuhl für ABWL und Wirtschaftsinformatik II {pelzl|schockert}@wius.bwi.uni-stuttgart.de Andreas Helferich highQ Computerlösungen GmbH, a.helferich@highQ.de Motivation der Fragestellung und Kontext Sowohl der klassische Öffentliche Personennahverkehr (ÖPNV) als auch alternative Mobilitätskonzepte wie Carsharing und Fahrradverleihsysteme decken in der Regel nur einen Teil des Mobilitätsbedarfs ihrer Kunden ab. Daher profitieren Anbieter in diesem Bereich davon, sich zu sog. Koopkurrenznetzwerken [1] zusammenzuschließen und ihre Leistungen im Verbund anzubieten. Das (((eTicket Deutschland ist ein Beispiel hierfür, ebenso die verstärkt auftretenden kommunalen oder regionalen Mobilitätskarten wie der Mobilitätspass des Verkehrsverbunds Stuttgart (VVS). Die Teilnahme an einem solchen Koopkurrenznetzwerk stellt sowohl hohe Anforderungen an die Hintergrundsysteme als auch an die Front-Office-Systeme zur Anbindung der Endnutzermedien wie Smartphones oder Smartcards. Große Mobilitätsdienstleister sind in der Lage, eigene organisatorische Einheiten und Rechenzentren zu nutzen. Kleine und mittelständische Mobilitätsdienstleister hingegen wiesen i. d. R. keine leistungsfähige ITInfrastruktur auf und sind nur eingeschränkt in der Lage, entsprechendes Know-how aufzubauen. Behandelte Fragestellung Vor diesem Hintergrund ist das Ziel des Forschungsprojekts Aprikose kleinen und mittleren Unternehmen im Bereich von Mobilitäts- sowie komplementärer Dienstleistungen eine Möglichkeit zu geben, sich einfach, kostengünstig und sicher als Anbieter an einem Koopkurrenznetzwerk wie dem (((eTicket Deutschland zu beteiligen. Dazu ist eine Kooperation mehrerer Partner notwendig, die in vielen Fällen gleichzeitig in Konkurrenz zueinander stehen. Dieser Zustand wird als Koopkurrenz (engl. Coopetition) bezeichnet [1]. So sind der öffentliche Personennahverkehr und CarsharingAnbieter einerseits Wettbewerber um den Kunden, der innerstädtisch von A nach B kommen will; andererseits ergänzen sie sich: wenn der Kunde z. B. mit der S-Bahn zum Standort eines car2go-Fahrzeugs fährt, um den innerstädtischen Berufsverkehr zu vermeiden, dann aber umsteigt, um mit dem Auto die letzte Meile bis zur eigenen Haustür zurückzulegen und unterwegs noch Besorgungen vor Ort vorzunehmen. Besonders einfach und damit attraktiv für den Kunden ist die Nutzung derartiger kombinierter Angebote, wenn sowohl Auskunft ('Wie komme ich am besten von A nach B?'), als auch Preisauskunft ('Was kostet mich das?') als auch Zugang ('Wie öffne ich das Fahrzeug? Habe ich die richtige Fahrberechtigung?') und Abrechnung ('Wie und wo muss ich bezahlen?') integriert erfolgen. Das Koopkurrenzverhältnis innerhalb eines Unternehmensnetzwerks bedingt einerseits, dass alle Anbieter über ein geeignetes IT-Netzwerk verbunden werden müssen. Andererseits muss aufgrund des weiterhin bestehenden Konkurrenzverhältnisses und zum Schutz von kritischen Unternehmensdaten sowie der Privatsphäre der Kunden sichergestellt werden, dass jeder Partner lediglich Zugriff auf diejenigen Daten erhält, die er zur Erfüllung seiner Aufgaben zwingend benötigt. Diese Daten sicher, zuverlässig und jederzeit aktuell bereitzustellen, stellt die Anbieter IT-seitig vor große Herausforderungen insbesondere kleinere Anbieter. Lösung und Ergebnisse Aufgrund des hohen Innovationsgrads des Vorhabens wurde ein dreistufiges Vorgehen im Sinne einer Produktlinienentwicklung gewählt. Die erste Ausbaustufe hat die Entwicklung einer auf den ÖPNV beschränkten prototypischen Lösung zum Ziel. Der Vorteil ist hier, dass mit der sog. VDV-Kernapplikation (VDVKA) [2] ein branchenweiter auf der ISO 24014-1 basierenden Standard existiert, der die Interoperabilität innerhalb des ÖPNV ermöglicht, gleichzeitig aber eine Offenheit für die Erweiterung im Bereich der sog. Multiapplikation vorsieht. In der zweiten Stufe kommen neue Mobilitätskonzepte hinzu, um die Einsatzdomäne auf intermodale Wegeketten auszudehnen und Koopkurrenznetzwerke zwischen ÖPNV und Anbietern neuer Mobilitätskonzepte zu unterstützen. In der dritten Stufe wird der Anwendungsbereich um mobilitätsnahe, komplementäre Dienstleistungen (insb. Tourismusdienstleistungen) ausgeweitet. Zur Anforderungsermittlung für das ÖPNV-Umfeld (Stufe 1) kommt die Methode Quality Function Deployment (QFD) zum Einsatz, da sie die Kundenanforderungen in den Mittelpunkt aller Bemühungen stellt: ein Produkt soll ausschließlich die vom Kunden gewünschten und nicht alle technisch möglichen Merkmalen aufweisen ('fitness for use') [3]. Zudem wird QFD in vielen Unternehmen, aber auch in der Innovationsmanagement-Literatur als prototypische Methode gesehen, um eine hohe Kundenorientierung als übergeordneten Erfolgsfaktor im Innovationsmanagement zu verwirklichen. Auf der Basis
- ZeitschriftenartikelLeichtgewichtige Requirements Engineering Assessments in Softwareprojekten(Softwaretechnik-Trends: Vol. 34, No. 1, 2014) Rapp, Daniel; Seyff, Norbert; Hess, Anne; Spörri, Peter; Glinz, Martin; Fuchs, EmmerichDaniel Rapp1, Norbert Seyff2, Anne Hess3, Peter Spörri1, Martin Glinz2, Emmerich Fuchs1 1 Zühlke Management Consultants AG, Schlieren, Schweiz, {daniel.rapp, peter.spoerri, emmerich.fuchs}@zuehlke.com 2 Universität Zürich, Schweiz, {seyff, glinz}@ifi.uzh.ch 3 Fraunhofer IESE, Kaiserslautern, Deutschland, anne.hess@iese.fraunhofer.de Motivation Erfolgreiches Requirements Engineering (RE) hat maßgeblichen Einfluss auf den Erfolg von Softwareprojekten [1, 2]. Diese Erkenntnis teilen nicht nur Wissenschaftler und Großkonzerne, sondern auch kleine und mittlere Unternehmen, die in Softwareentwicklungsprojekten involviert sind. Dabei stellt die erfolgreiche Durchführung von RE in Softwareprojekten häufig eine Herausforderung für Unternehmen dar. Missstände und Probleme bezüglich RE können oftmals nicht selbst von den Unternehmen richtig und objektiv erkannt werden, sodass eine Unterstützung von außen effizient ist, um eine effektive Verbesserung des RE-Prozesses einzuleiten. Die dafür notwendige 'Standortbestimmung' durch RE-Prozess-Analysen, stellt aber vor allem für kleinere und mittlere Softwareunternehmen eine große Herausforderung dar, da existierende AssessmentVerfahren nur unzureichend auf ihre Bedürfnisse zugeschnitten sind. Laut unserer Erfahrung bieten wissenschaftliche Publikationen zu diesem Thema oftmals zu wenig konkrete Anleitung und Hilfestellung für Praktiker und werden daher selten eingesetzt, um die Qualität eines vorhandenen RE-Prozesses zu bestimmen. Ebenso fällt es gerade kleinen und mittleren Unternehmen oft schwer, auf Standards wie CMMI und ISO/IEC 15504 zu setzten, da deren Einsatz mit hohen Kosten und einer langwierigen Implementierungsdauer verbunden sein kann. Diese Situation führt dazu, dass viele Unternehmen keine hinreichende Möglichkeit sehen, ihre Probleme und deren Ursachen bezüglich RE zu erkennen und zu adressieren [3, 4, 5]. Der RE Assessment Guide Vor diesem Hintergrund haben wir uns das Ziel gesetzt, eine leichtgewichtige RE Assessmentmethode zu entwickeln, die sich vor allem an den Bedürfnissen von kleinen und mittleren Unternehmen anlehnt. Das schnelle und effiziente Bewerten von existierenden REProzessen und das Aufzeigen von konkreten Verbesserungsmaßnahmen standen somit bei der Entwicklung des 'RE Assessment Guides' im Vordergrund. Der entwickelte RE Assessment Guide umfasst unter anderem auch spezifische Fragestellungen zu iterativen Softwareentwicklungsprojekten, da diese heutzutage sehr weit verbreitet sind und auch hier insbesondere für Requirements Engineering Aktivitäten in der Praxis noch große Herausforderungen existieren [6]. Des Weiteren passt sich der Assessment Guide während des Assessments dynamisch an die Eigenschaften eines konkreten Projektes an. Indem sichergestellt wird, dass nur projektrelevante Aspekte bewertet werden, wird ein Assessment der Charakteristik sowie der Heterogenität verschiedener Firmen und deren Projekten gerecht. Aus diesem Grund ist es möglich verschiedenste Arten von RE Assessments durchzuführen. So kann ein Assessment sowohl ein einzelnes Softwareentwicklungsprojekt bewerten als auch mehrere Projekte innerhalb eines Unternehmens analysieren und deren Unterschiede bzw. Gemeinsamkeiten hinsichtlich RE aufzeigen. Der RE Assessment Guide wurde mit dem OpenSource-Tool LimeSurvey implementiert [7]. In der aktuellen Version ist der RE Assessment Guide bezüglich iterativer Softwareentwicklungsprozesse, wie dem Rational Unified Process (RUP), optimiert und setzt sich aus drei Hauptteilen zusammen: 1. Einflussfaktoren: in diesem Teil werden allgemeine Informationen sowie projektspezifische Aspekte gesammelt, wie z.B. die Grösse und Branche des Unternehmens, die im Projekt eingesetzten Rollen oder die Erfahrung des Requirements Engineers. Prozessanalyse: hierbei werden Informationen bezüglich der konkreten Ausprägungen und Durchführung des Softwareentwicklungsprozesses erfasst, wie z.B. die Art des Prozesses, die durchgeführten Aktivitäten oder die Art und Weise der Kommunikation. Dokumentenanalyse: der dritte Hauptteil sammelt Informationen über die spezifizierten Artefakte und Dokumente, wie beispielsweise über deren Aufbau, dem Zeitpunkt der Erstellung und Kommunikation oder deren Verständlichkeit.
- ZeitschriftenartikelProjektsteuerung beim Einsatz agiler Vorgehensmodelle(Softwaretechnik-Trends: Vol. 34, No. 1, 2014) Ebhart, Dieter; Lehmann, Florian; Thaden, ThorstenDieter Ebhart, Lead Project Manager msgGillardon AG, dieter.ebhart@msg-gillardon.de Florian Lehmann, IT Consultant msgGillardon AG, florian.lehmann@msg-gillardon.de Thorsten von Thaden, Lead Software Engineer msgGillardon, thorsten.von.thaden@msg-gillardon.de Abstract. Bei der Durchführung agiler Projekte ist ein integriertes Berichtswesen für die erfolgreiche Projektsteuerung und -abwicklung essentiell. Dieser Artikel beschreibt, wie eine solche Integration aussehen kann, ohne aufwändige Anpassungen, etwa in Bezug auf Aufwandsschätzungen, Plan-/IstVergleiche oder Projektsteuerung. Somit bleiben die Vorteile agiler Vorgehensweisen, wie z.B. Flexibilität bei Änderungen, geringerer Overhead oder kürzere Entwicklungszyklen erhalten, ohne Abstriche an Berichts- und Steuerungsinformationen hinnehmen zu müssen. Kernelemente der Projektsteuerung. Ein Schlüsselfaktor für die erfolgreiche Projektarbeit ist, sicherzustellen, dass die richtigen Ressourcen zur richtigen Zeit für die Abarbeitung der richtigen Arbeitspakete zur Verfügung stehen. Dabei ist der Projektstrukturplan (PSP) die Grundlage für die Projektentscheidung, die Zeit-, Ressourcen- und Budgetpläne und ggfs. das spätere Berichtswesen im Projekt. Zur Erstellung des Zeitplans wird jedes Arbeitspaket im PSP geschätzt, um die Abhängigkeiten der Arbeitspakete erweitert und mittels Überlappung, Parallelisierung oder Verdichtung von Vorgängen optimiert. Die Arbeitspakete dürfen nicht zu klein gewählt werden typischerweise sollte ein Arbeitspaket zwischen 1% und 5% des Gesamtaufwands umfassen vgl. [SCHU2011]. Durch Ermittlung der benötigten Einsatzmittel und deren Kosten entsteht der Ressourcen und Budgetplan. Planung und Aufwandsschätzung bei agilen Methoden. Bei agilen Methoden werden typischerweise detaillierte Aufwandsschätzungen mit einer Vorausschau von nur wenigen Wochen erstellt. Somit ist eine detaillierte Aufwandsschätzung nur für die Arbeitspakete verfügbar, die in naher Zukunft zur Bearbeitung anstehen. Die Betrachtung der Abhängigkeiten erfolgt durch das Entwicklungsteam und Product Owner gemeinsam. Die letztendliche Festlegung der Reihenfolge erfolgt durch den Product Owner unter Berücksichtigung dieses Teaminputs, des Business Values und der Interessen der Stakeholder. Bei der Abschätzung von User Stories empfehlen wir Storypoints als Maß zu verwenden. Für jedes Team kann so die Sprint Velocity, also die durchschnittliche Anzahl der Storypoints, die ein spezielles Team in einem Sprint typischerweise abarbeitet, ermittelt werden. Versteht man das Backlog als PSP, müssen die Backlog-Einträge so geschätzt werden, dass daraus eine Aussage zum Gesamtaufwand und damit zu den Gesamtkosten und Terminen, abgeleitet werden kann. Die intuitive Methode, die Backlog-Einträge unabhängig von Ihrer Detaillierungsstufe mit Storypoints zu bewerten funktioniert nur in Ausnahmefällen, da Storypoints: teamabhängig sind. Sie beinhalten die Erfahrungen und Kenntnisse des Schätzteams und sind daher nicht auf andere Teams übertragbar. keine absolute Schätzgröße, sondern eine relative Vergleichsgröße der einzelnen Backlog Einträge untereinander sind. Die Sprint Velocity ist daher auch bei gleichbleibendem Team nicht von einem Projekt auf ein anderes übertragbar. nicht stetig, sondern in Stufen vergeben werden. Typisch ist eine Verteilung von 1,2,3,5,8,13,20,40. Storypoints ab 20 bedeuten, dass das Team diese Story für sehr komplex hält, und z.B. der BacklogEintrag (User-Story) aufgeteilt werden sollte.
- ZeitschriftenartikelHerausforderungen in der Laufzeitdarstellung von Anforderungen für eingebettete Systeme(Softwaretechnik-Trends: Vol. 34, No. 1, 2014) Kneer, Fabian; Kamsties, Erik
- ZeitschriftenartikelGlobal Requirements Engineering - Resultate einer Literaturanalyse(Softwaretechnik-Trends: Vol. 34, No. 1, 2014) Schmid, Klaus
- ZeitschriftenartikelRequirements Engineering und Konzeption von "Gamified" Apps(Softwaretechnik-Trends: Vol. 34, No. 1, 2014) Hess, Steffen; Collarana, Diego; Dörr, Jörg
- ZeitschriftenartikelBericht und Beiträge vom Treffen der Fachgruppe am 28. und 29. November 2013 in Ilmenau(Softwaretechnik-Trends: Vol. 34, No. 1, 2014) Herrmann, Andrea; Houdek, Frank; Doerr, Joerg; Knauss, Eric; Schneider, Kurt
- ZeitschriftenartikelKonferenzankündigungen(Softwaretechnik-Trends: Vol. 34, No. 1, 2014)
- ZeitschriftenartikelNein oder nicht Nein - Die Mär von der bösen negativen Anforderung(Softwaretechnik-Trends: Vol. 34, No. 1, 2014) Tayeh, Malik
- ZeitschriftenartikelWo stehen wir und wo wollen wir hin? Erfüllungsgrade von RE-Praktiken 2013(Softwaretechnik-Trends: Vol. 34, No. 1, 2014) Adam, Sebastian; Wünch, Christian; Koch, Matthias