325 research outputs found
Engineering Resilient Systems: Models, Methods and Tools (Dagstuhl Seminar 13022)
No full textSoftware-intensive systems are becoming widely used in such critical infrastructures as railway, air- and road traffic, power management, health care and banking. In spite of drastically increased complexity and need to operate in unpredictable volatile environment, high dependability remains a must for such systems. Resilience -- the ability to deliver services that can be justifiably trusted despite changes - is an evolution of the dependability concept. It adds several new dimensions to dependability concepts including adaptability to evolving requirements and proactive error prevention. To address these challenges we need novel models, methods and tools that enable explicit modeling of resilience aspects and reasoning about them. The Dagstuhl Seminar 13022 "Engineering Resilient Systems: Models, Methods and Tools"
discussed the most promising techniques for achieving resilience both at the system design stage and at runtime. It brought together researchers from dependability, formal methods, fault tolerance and software engineering communities that promoted vivid cross-disciplinary discussions
Re-engineering data-centric information systems for the Cloud – A method and architectural patterns promoting multi-tenancy
No full textEnterprise applications are data-centric information systems that are being increasingly deployed as <i>Software-as-a-Service (SaaS)</i> Cloud offerings. Such service-oriented enterprise applications allow multiple tenants (i.e., groups of service consumers) to share the computational and storage capabilities of a single Cloud application instance. Compared to a more traditional single-tenant application deployment model, a multi-tenant SaaS architecture lowers both deployment and maintenance costs. These cost reductions motivate architects to re-engineer existing enterprise applications to support multi-tenancy at the application level. However, in order to preserve data integrity and data confidentiality, the re-engineering process must guarantee that different tenants allocated to the same application instance cannot access one another’s data, including both persistent values stored in databases and transient values created during calculations.\ud
This chapter presents a method and a set of architectural patterns for systematically re-engineering data-sensitive enterprise applications into secure multi- tenant software services that can be deployed to public and private Cloud offerings seamlessly. Architectural refactoring is introduced as a novel re- engineering practice and the necessary steps in multi-tenant refactoring are described from planning to execution to validation (including testing and code reviews). The method and patterns are validated in a fictitious, but realistic and representative case study that was distilled from real-world requirements and application architectures
Domain- and Quality-aware Requirements Engineering for Law-compliant Systems
No full textTitel in deutscher Übersetzung: Domänen- und qualitätsgetriebene Anforderungserhebung für gesetzeskonforme Systeme
Der bekannte Leitsatz in der Anforderungserhebung und -analyse besagt, dass es schwierig ist, das richtige System zu bauen, wenn man nicht weiß, was das 'Richtige' eigentlich ist. Es existieren überzeugende Belege, dass dieser Leitsatz die Notwendigkeit der Anforderungserhebung und -analyse exakt definiert
und beschreibt. Zum Beispiel ergaben Studien, dass das Beheben von Defekten in einer Software, die bereits produktiv genutzt wird, bis zu 80 mal so teuer ist wie das frühzeitige Beheben der korrespondierenden Defekte in den Anforderungen. Generell hat es sich gezeigt, dass das Durchführen einer angemessenen
Anforderungserhebung und -analyse ein wichtiger Erfolgsfaktor für
Softwareentwicklungsprojekte ist. Während der Progression von den initialen Wünschen der beteiligten Interessensvertretern für ein zu entwickelndes System zu einer Spezifikation für eben dieses Systems müssen Anforderungsanalysten einen komplexen Entscheidungsprozess durchlaufen, der die initialen Wünsche in
die Spezifikation überführt. Tatsächlich wird das Treffen von Entscheidungen als integraler Bestandteil der Anforderungsanalyse gesehen. In dieser Arbeit werden wir versuchen zu verstehen welche Aktivitäten und Information von Nöten sind, um eine fundierte Auswahl von Anforderungen vorzunehmen, welche Herausforderungen damit verbunden sind, wie eine ideale Lösung zur Anforderungswahl aussehen könnte und in welchen Bereichen der aktuelle Stand der Technik in Bezug auf diese ideale Lösung lückenhaft ist.
Innerhalb dieser Arbeit werden wir die Informationen, die notwendig für eine fundierte Anforderungsauswahl sind, identifizieren, einen Prozess präsentieren, um diese notwendigen Informationen zu sammeln, die Herausforderungen herausstellen, die durch diesen Prozess und die damit verbundenen Aktivitäten adressiert werden und eine Auswahl von Methoden diskutieren, mit deren Hilfe man
die Aktivitäten des Prozesses umsetzen kann. Die gesammelten Informationen werden dann für eine automatisierte Anforderungsauswahl verwendet. Für die Auswahl kommt ein Optimierungsmodell, das Teil des Beitrags dieser Arbeit ist,
zum Einsatz. Da wir während der Erstellung dieser Arbeit zwei große Lücken im Stand der Technik bezüglich unseres Prozesses und der damit verbundenen Aktivitäten identifiziert haben, präsentieren wir darüber hinaus zwei neuartige Methoden für die Kontexterhebung und die Erhebung von rechtlichen Anforderungen, um diese Lücken zu schließen. Diese Methoden sind Teil des Hauptbeitrags dieser
Arbeit.
Unsere Lösung für der Erhebung des Kontext für ein zu entwickelndes System ermöglicht das Etablieren eines domänenspezifischen Kontextes unter Zuhilfenahme von Mustern für verschiedene Domänen. Diese Kontextmuster erlauben eine strukturierte Erhebung und Dokumentation aller relevanten Interessensvertreter
und technischen Entitäten für ein zu entwickelndes System. Sowohl die
Dokumentation in Form von grafischen Musterinstanzen und textuellen Vorlageninstanzen als auch die Methode zum Sammeln der notwendigen Informationen sind expliziter Bestandteil jedes Kontextmusters. Zusätzlich stellen wir auch Hilfsmittel für die Erstellung neuer Kontextmuster und das Erweitern der in
dieser Arbeit präsentierten Kontextmustersprache zur Verfügung.
Unsere Lösung für die Erhebung von rechtlichen Anforderungen basiert auch auf Mustern und stellt eine Methode bereit, welche es einem erlaubt, die relevanten Gesetze für ein zu erstellendes System, welches in Form der funktionalen Anforderungen bereits beschrieben sein muss, zu identifizieren und welche die bestehenden funktionalen Anforderungen mit den rechtlichen Anforderungen verknüpft. Diese Methode beruht auf der Zusammenarbeit zwischen
Anforderungsanalysten und Rechtsexperten und schließt die Verständnislücke zwischen ihren verschiedenartigen Welten.
Wir veranschaulichen unseren Prozess unter der Zuhilfenahme eines durchgehenden Beispiels aus dem Bereich der service-orientierten Architekturen. Zusätzlich präsentieren wir sowohl die Ergebnisse der Anwendung unseres Prozesses (bzw. Teilen davon) auf zwei reale Fälle aus den Bereichen von Smart Grids und Wahlsystemen, als auch alle anderen Ergebnisse der wissenschaftlichen Methoden, die wir genutzt haben, um unsere Lösung zu fundieren und validieren.The long known credo of requirements engineering states that it is challenging to build the right system if you do not know what right is. There is strong evidence that this credo exactly defines and describes the necessity of requirements engineering. Fixing a defect when it is already fielded is reported to be up to eighty times more expensive than fixing the corresponding requirements defects early on. In general, conducting sufficient requirements engineering has shown to be a crucial success factor for software development projects. Throughout the progression from initial stakeholders' wishes regarding the system-to-be to a specification for the
system-to-be requirements engineers have to undergo a complex decision process for forming the actual plan connecting stakeholder wishes and the final specification. Indeed, decision making is considered to be an inherent part of requirements engineering. In this thesis, we try to understand which activities and information are needed for selecting requirements, which the challenges are, how an ideal solution for selecting requirements would look like, and where the current state of the art is deficient regarding the ideal solution.
Within this thesis we identify the information necessary for an informed requirements selection, present a process in which one collects all the necessary information, highlight the challenges to be addressed by this process and its activities, and a selection of methods to conduct the activities of the process. All the collected information is then used for an automated requirements selection using an optimization model which is also part of the contribution of this thesis. As we identified two major gaps in the state of the art considering the proposed process and its activities, we also present two
novel methods for context elicitation and for legal compliance requirements elicitation to fill the gaps as part of the main contribution.
Our solution for context elicitation enables a domain-specific context
establishment based on patterns for different domains. The context patterns allow a structured elicitation and documentation of relevant stakeholders and technical entities for a system-to-be. Both, the documentation in means of graphical pattern instances and textual template instances as well as the method for collecting the necessary information are explicitly given in each context pattern. Additionally, we also provide the means which are necessary to derive new context patterns and extend our context patterns language which is part of this thesis.
Our solution for legal compliance requirements elicitation is a pattern-based and guided method which lets one identify the relevant laws for a system-to-be, which is described in means of functional requirements, and which intertwines the functional requirements with the according legal requirements. This method relies on the collaboration of requirements engineers and legal experts, and
bridges the gap between their distinct worlds.
Our process is exemplified using a running example in the domain of service oriented architectures. Additionally, the results of applying (parts of) the process to real life cases from the smart grid domain and voting system domain are presented, as well as all other results from the scientific means we took to ground and validate the proposed solutions
Secure data processing in the cloud
No full textData protection is a key issue in the adoption of cloud services. The project “RestAssured – Secure Data Processing in the Cloud,” financed by the European Union’s Horizon 2020 research and innovation programme, addresses the challenge of data protection in the cloud with a combination of innovative security solutions, data lifecycle management techniques, run-time adaptation, and automated risk management. This paper gives an overview about the pro-ject’s goals and current statu
Problem-based privacy analysis (ProPAn) – a computer-aided privacy requirements engineering method
No full textWith the advancing digitalization in almost all parts of our daily life, e.g., electronic health records and smart homes, and the outsourcing of data processing, e.g., data storage in the cloud and data analysis services, computer-based systems process more and more data these days. Often the processed data originate from natural persons (called data subjects) and are hence personal data possibly containing sensitive information about the individuals. Privacy in the context of personal data processing means that personal data are protected, e.g., against unwanted access and modification, that data subjects are aware about the processing practices of the controller that processes their data, and that data subjects keep control over the processing of their personal data. Privacy regulations, such as the EU General
Data Protection Regulation (GDPR), aim at protecting data subjects by empowering them with rights and by putting obligations on controllers processing personal data. Not only administrative fines defined in regulations are a driver for the consideration of privacy in the development of a software-based system, also several data breaches occurred in the last years have shown that a poor consideration of privacy during the system and software development may
ultimately lead to a loss of trust in and reputation of the controller.
To avoid the occurrence of data breaches and to be compliant with privacy regulations, privacy should to be considered in system and software development as a software quality from the beginning. This approach is also known as privacy-by-design. There are several challenges for privacy-by-design methods that are still not fully addressed by existing methods. First, diverse notions of privacy exist. Most of these privacy notions are non-technical and have to be
refined to more technical privacy requirements that can be related to the system. Second, the system has to be analyzed for its personal data processing behavior. That is, it has to be determined which personal data are collected, stored, and provided to others by the system. Third, the privacy requirements have to be elicited that are actually relevant for the system. Fourth, the privacy risks imposed by or existing in the system have to be identified and evaluated. Fifth, measures that implement the privacy requirements and mitigate
the privacy risks of the system have to be selected and integrated into the system. Sixth, privacy regulations mandate to assess the impact of the personal data processing on the data subjects. Such a privacy impact assessment (PIA) may be performed as part of a privacy-by-design method. Seventh, the conduction of a privacy-by-design method should be supported as good as possible, e.g., by a
systematic method, supportive material, and computer support.
In this thesis, I propose the privacy requirements engineering method
Problem-based Privacy Analysis (ProPAn). The ProPAn method aims to address the aforementioned challenges starting with a system's functional requirements as input. As part of ProPAn, I provide a privacy requirements taxonomy that I derived from and mapped to various other privacy notions. This privacy requirements taxonomy addresses the first challenge mentioned above. The ProPAn
method is the main contribution of my thesis and addresses the second to seventh challenge mentioned above. To address the fifth challenge in the ProPAn method, I propose an aspect-oriented requirements engineering framework that allows to model
cross-cutting functionalities and to modularly integrate them into a system's functional requirements. The seventh challenge is addressed by ProPAn's computer support for the execution of the method and the documentation and validation of the method's artifacts in a machine-readable model.Mit der fortschreitenden Digitalisierung in beinah allen Bereichen unseres täglichen Lebens, z.B. elektronische Patientenakten und Smart Homes, und dem Outsourcing von Datenverarbeitung, z.B. Datenspeicherung in der Cloud und Datenanalysediensten, verarbeiten computerbasierte Systeme immer mehr Daten. Häufig stammen die verarbeiteten Daten von natürlichen Personen (betroffenen Personen) und sind daher personenbezogene Daten, die möglicherweise
sensible Informationen über die einzelnen Personen enthalten. Im
Kontext der Verarbeitung personenbezogener Daten heißt Privacy, dass personenbezogene Daten geschützt werden, z.B. gegen ungewollten Zugriff und Änderung, dass betroffene Personen sich über die Verarbeitung der personenbezogenen Daten bewusst sind, und dass die betroffenen Personen die Kontrolle über die Verarbeitung ihrer Daten behalten. Datenschutzregularien,
wie die EU Datenschutz-Grundverordnung (DSGVO), verfolgen das Ziel betroffene Personen zu stärken, indem ihnen Rechte gegeben werden, und Verantwortlichen, die personenbezogene Daten verarbeiten, Pflichten auferlegt werden. Nicht nur Geldbußen, die in Regularien definiert sind, sind ein Treiber für die Berücksichtigung von Privacy bei der Entwicklung von softwarebasierten System, auch einige Verletzungen des Schutzes personenbezogener Daten in den letzten
Jahren haben gezeigt, dass eine unzureichende Berücksichtigung von Privacy während der System- und Softwareentwicklung letztlich zu einem Verlust von Vertrauen in den Verantwortlichen und dessen Ansehen führen können.
Um Verletzungen des Schutzes personenbezogener Daten zu vermeiden und konform zu Datenschutzregularien zu sein, sollte Privacy von Anfang an während der System- und Softwareentwicklung als Softwarequalität berücksichtigt werden. Dieser Ansatz ist auch als Privacy-by-Design bekannt. Es gibt einige Herausforderung für Privacy-by-Design-Methoden, die noch nicht vollständig von existierenden Methoden adressiert werden. Erstens gibt es verschiedenste
Privacybegriffe. Die meisten dieser Begriffe sind nicht-technisch und müssen zu technischeren Privacyanforderungen verfeinert werden, die zu dem System in Bezug gesetzt werden können. Zweitens muss das System bezüglicher seiner Verarbeitung von personenbezogenen Daten untersucht werden. Das heißt, dass festgestellt werden
muss, welche personenbezogenen Daten vom System gesammelt, gespeichert, und an Andere weitergegeben werden. Drittens müssen die Privacyanforderungen erhoben werden, die tatsächlich für das System relevant sind. Viertens müssen die Risiken bezüglich Privacy, die das System verursacht oder beinhaltet, identifiziert und evaluiert werden. Fünftens, müssen Maßnahmen, die Privacyanforderungen implementieren und Risiken bezüglich Privacy reduzieren, ausgewählt und in das System integriert werden. Sechstens schreiben Datenschutzregularien vor, die Folgen der Verarbeitung personenbezogener Daten auf die betroffenen Personen zu untersuchen. Eine solche Datenschutz-Folgenabschätzung kann als Teil einer Privacy-by-Design-Methode durchgeführt werden. Siebtens sollte die Durchführung einer Privacy-by-Design-Methode so gut wie möglich unterstützt werden, z.B. durch eine systematische Methode, unterstützendes Material, und Computerunterstützung.
In meiner Dissertation stelle ich die Anforderungsanalysemethode Problembasierte Privacy Analyse (ProPAn) vor, in der die Berücksichtigung von Privacy integriert ist. Die ProPAn-Methode verfolgt das Ziel, die zuvor genannten Herausforderungen zu adressieren, beginnend mit den funktionalen Anforderungen des Systems als Eingabe. Als Teil der ProPAn-Methode stelle ich
eine Privacyanforderungstaxonomie bereit, die ich aus verschiedenen
Privacybegriffen abgeleitet habe und zu diesen in Beziehung
setze. Die ProPAn-Methode ist der Hauptbeitrag meiner Dissertation und adressiert die zweite bis siebte zuvor genannte Herausforderung. Um die fünfte Herausforderung zu adressieren, präsentiere ich ein aspektorientiertes Anforderungsanalyseframework, das es erlaubt Querschnittsanforderungen zu modellieren und modular in die funktionalen Anforderungen eines Systems zu integrieren. Die siebte Herausforderung wird von ProPAns Computerunterstützung
für die Anwendung der Methode, und der Dokumentation und Validierung der Methodenartefakte in einem maschinenlesbaren Modells adressiert
Towards a systematic literature review on secure software design
No full textIn recent years numerous researchers proposed approaches
to incorporate security into software design. Unfortunately a systematic literature review (SLR) providing a detailed overview of the state of the art and defining interesting research opportunities is lacking. This creates an extra barrier for (new) researchers to enter the domain and contribute to it. We describe a protocol for an SLR aimed at minimizing this barrier. By providing this protocol we first hope to trigger a discussion and get feedback on the protocol. Second, this protocol is useful when updating the SLR with approaches that emerged after its initial performance.status: Publishe
Combining Goal-Oriented and Problem-Oriented Requirements Engineering Methods
No full textPart 1: Cross-Domain Conference and Workshop on Multidisciplinary Research and Practice for Information Systems (CD-ARES 2013)International audienceSeveral requirements engineering methods exist that differ in their abstraction level and in their view on the system-to-be. Two fundamentally different classes of requirements engineering methods are goal- and problem-based methods. Goal-based methods analyze the goals of stakeholders towards the system-to-be. Problem-based methods focus on decomposing the development problem into simple sub-problems. Goal-based methods use a higher abstraction level that consider only the parts of a system that are relevant for a goal and provide the means to analyze and solve goal conflicts. Problem-based methods use a lower abstraction level that describes the entire system-to-be. A combination of these methods enables a seamless software development, which considers stakeholders’ goals and a comprehensive view on the system-to-be at the requirements level. We propose a requirements engineering method that combines the goal-based method SI* and the problem-based method Problem Frames. We propose to analyze the issues between different goals of stakeholders first using the SI* method. Our method provides the means to use the resulting SI* models as input for the problem frame method. These Problem Frame models can be refined into architectures using existing research. Thus, we provide a combined requirements engineering method that considers all stakeholder views and provides a detailed system specification. We illustrate our method using an E-Health example
Zu mehr Vergleichbarkeit bei der Evaluierung der Fehlertoleranz von sicherheitskritischer eingebetteter Software
No full textSafety-critical embedded systems often need to be cost-effective, but must nevertheless be safe. More and more, fault-tolerance mechanisms are being shifted from hardware into software. Not only is developing safety-critical software a challenging and intricate task, likewise intricate is to put its fault-tolerance into expressive and comparable measures. This especially holds for the fault-tolerance of software when it comes to hardware-faults that affect the execution of the machine instructions.
Several fault-injection approaches for fault-tolerance evaluation of software have been presented in the past. However, these approaches do not underlie a uniform procedure, so that the obtained measures are specific to the system and therefore cannot be compared among one another.
In this thesis a fault-injection method is developed that allows the evaluation of the fault-tolerance of embedded software in such a way, that the obtained measures become comparable. The method bases on a concept from the early 90s which characterizes fault-injection through a collection of sets. These sets are extended and adjusted in this thesis to the object of evaluation 'software in execution' and to the herein considered hardware faults. The software is thereby conceived as process. From its structural components, which are defined by means of a universal microprocessor model, a hardware-independent fault set is derived. This set forms a mutual basis among different experiments. In conjunction with the other sets presented, a fault-injection method allowing for comparable fault-tolerance measures is constructed.
Therewith is presented a fault-tolerance evaluation method that enables comparability of the fault-tolerance of different software on different hardware -- as far as this is possible in the field of fault-injection
An Approach to Develop Provably Safe Software
No full textWe present a process model for the development of provably safe software. It is based on well-established tools and techniques to set up formal specifications in the specification language Z and a program synthesis system designed by the author. The model provides a guideline for the specification and implementation of safe software, consisting of a number of steps that are complemented by proof obligations. The parts of the process specific to software safety are given special consideration. The approach is exemplified by the specification and partial implementation of a program controlling the pump of a steam boiler. Finally, we relate software safety to correctness and reliability. 1 Why, What and How Our approach aims at developing software for which certain safety conditions can be guaranteed. For this purpose, formal methods are applied. The idea is to express the safety conditions in a formal specification language. This makes it possible to treat them like functional requirem..
- …
