Axel Kalenborn

Requirements Engineering in the Bidding Stage of Software Projects – A Research Preview

[Context and motivation] Before a software project officially starts, there is a stage that has not received much consideration in literature: the precontract or bidding stage. [Question/problem] In this phase, basic Requirements Engineering (RE) activities are conducted without having a budget, yet. In this paper, the SmartOffer project is described, which aims on improving RE during this precontract phase. [Principal idea/results] Therefore, bidding processes of several organizations were analyzed and commonalities/differences were identified. The consolidated process is described in this paper. It consists out of four abstract phases: assessment of demand, conception, proposal, and actual project conduction. Mandatory and optional process steps within these phases allow for being tailored to different companies and products. [Contribution] The consolidated bidding process provides the potential for automation and tool support. In consequence the precontract phase will be more efficient and effective. Building a tool supporting this process as well as evaluating this tool will be addressed in future work to complement this research preview.

Das Mobex-Werkzeug zur Realisierung der MbE-Methode

Mobex ermoglicht die Erstellung und semantische Anreicherung von Mock-Ups und soll dadurch den die MbE-Methode in der Praxis anwendbar machen. Das Werkzeug ist in die Kategorie der Rapid-Prototyping- bzw. Wireframe-Systeme mit dem Schwerpunkt auf Webprojekten einzuordnen.

Die Vorvertragsphase von Softwareprojekten

In der Literatur zum Management von Softwareprojekten, zum Software-Engineering oder zum Requirements-Engineering, beginnen Projekte in der Regel mit einer ausfuhrlichen Analysephase, auf deren Basis sie dann umgesetzt und getestet werden. In der Praxis ist vor dem eigentlichen Beginn eines Softwareprojekts zunachst eine erste strategische Entscheidung zu fallen, namlich die Frage nach der Eigenfertigung („make“) oder dem Fremdbezug („buy“). Die aktuelle Situation in der Softwareentwicklung ist durch einen Mangel an Entwicklungsressourcen bei gleichzeitig steigender Bedeutung von Softwareprodukten gekennzeichnet.

Die werkzeugbasierte Modeling by Example Methode

In den bisherigen Ausarbeitungen wurde auf die Probleme im Rahmen der Vorbereitung von Softwareprojekten eingegangen und es wurden Defizite in den Methoden des Requirements-Engineering in dieser Phase eines Softwareprojekts beschrieben. Die im Folgenden vorgestellte Methode stellt die visuelle Aufbereitung eines Web Projektes in das Zentrum des Requirements-Engineering und der Modellierung. Der Kunde soll bereits in der Angebotsphase eine moglichst prazise Vorstellung seiner Anwendung bekommen und diese erleben konnen. Dem Motto von Albert Einstein folgend, „If I can’t picture it, I can’t understand it!“, wird ein Abbild der Anwendung als Basis fur die fachliche und technische Beschreibung der Anforderungen sowie deren Kalkulation verwendet.

Anforderungserhebung in der Vorvertragsphase

Das ingenieurmasige Erheben von Anforderungen ist ein wichtiger Aspekt bei der Entwicklung von Systemen aller Art. Requirements-Engineering befasst sich mit den „Prinzipien, Methoden und Werkzeugen zur Ermittlung, Beschreibung, Prufung und Verwaltung von Anforderungen in der Systementwicklung“. Die Anforderungen, die der Auftraggeber an den Auftragnehmer hat, werden gesammelt, strukturiert und anschliesend spezifiziert, um sie zur Festlegung der Vertragsmodalitaten nutzen zu konnen.

Evaluation der Methode

Als Ziele der Modeling by Example Methode wurden in Abschnitt 4.2 Effizienzsteigerungen bei der Vorbereitung von internetbasierten Projekten sowie die Verbesserung des Dialogs mit den fachfremden Stakeholdern im Rahmen der Vorvertragsphase und dem Projektverlauf aufgefuhrt.

Java-basiertes automatisiertes Test-Framework

KernpunkteManuelle Software Tests werden immer häufiger durch automatisierte Tests ergänzt bzw. ersetzen diese vollständig. Automatisierte Tests können jedoch nur in Komponenten verankert werden deren Quellcode vorliegt und sind daher für Fremdkomponenten nicht nutzbar.Der Beitrag beschreibt den „State-of-the-Art“ des Software Testens, definiert verschiedenen Test ansätze und würdigt diese kritisch.Die Grenzen automatisierter Software Tests werden aufgezeigt und das Problem der Testbarkeit externer Komponenten besprochen.Im CBTesten-Ansatz wird eine Möglichkeit zur nachträglichen Integration von Testroutinen in bereits kompilierte Softwarekomponenten vorgestellt.AbstractJava-based Automated Test-Framework With an increasing number of software-systems built using components, software developers are faced with entirely new challenges. For example, testing these modu-lar systems has become far more complex. Manual test approaches are incapable of dealing with the new architectures, leaving several parts of the systems untested. Thorough tests require extensive use of human resources, with enormous financial repercussions. Most customers are unwilling to accept these, completely unaware of their eventual benefit. Even existing automated software test approaches can only remedy these problems in parts. They commonly require source code access to add the necessary test routines, making the approach unsuitable for third party compo-nents. The innovative CBTesten approach tackles this problem. A highly dynamic framework is introduced into the software-system after compilation, which allows de-riving of test cases as well as fully automated tests based on the collected data.