5 research outputs found

    Re-examining the Information Systems Security Problem from a Systems Theory Perspective

    Get PDF
    This theoretical paper discusses a recent shift in cyber attackers’ interest away from traditional network and operating systems vulnerabilities and towards application level security flaws in end user systems. The authors argue that this shift signals a strong need to re-examine the way that security is addressed during the systems development process. Most of the systems development methodologies currently used do not contain formal processes for dealing with the interconnected complexity and risks associated with today’s computing environments. Using systems theory as a theoretical lens, the fundamental processes of current systems development methodologies are analyzed and weaknesses in their ability to deal with these environmental factors are discussed. The authors then present a proposed holistic framework for integrating security into existing systems development methods. The paper concludes with a discussion of the need for more scholarly research in this area and suggestions for future research directions are offered

    Interaction Room - Eine Methode zur Förderung der Wertorientierung in Planung und Requirements Engineering von Informationssystemen

    Get PDF
    Software wird immer wichtiger in unserer Gesellschaft, trotzdem dauern IT-Projekte länger und werden teurer, als ursprünglich geplant, sie verfehlen ihre funktionalen und qualitativen Ziele oder werden vorzeitig abgebrochen. Durch inhärente Ungewissheit, Komplexität und mangelnde Wertorientierung wird eine realistische Projektplanung für die Entwicklung von Informationssystemen erschwert. Auf Basis eines unzureichenden Verständnisses über Anforderungen, Risiken und Ziele kann der zu leistende Aufwand nicht realistisch geschätzt werden, die daraufhin allokierten Ressourcen, bereitgestellten monetären Mittel und die geplante Projektlaufzeit reichen für eine erfolgreiche Projektumsetzung nicht aus. Die initiale Verständnisbildung über Anforderungen und Risiken geschieht in plangetriebenen Vorgehensweisen zu Beginn eines Projekts durch eine umfangreiche Analyse und möglichst vollständige Spezifikation. Das Schreiben vollständiger Spezifikationen ist jedoch unwirtschaftlich, weil soziotechnische Systeme nicht vollständig beschreibbar sind und emergente Anforderungen in erkenntnisgetriebenen Softwareprozessen zu Änderungen führen. In agilen Vorgehensweisen wird das Verständnis durch die gleichen Aktivitäten, jedoch in kurzen Zyklen und ohne vollständige Spezifikation zu Projektbeginn, durch enge Zusammenarbeit zwischen Kunden und Entwicklungsteams hergestellt. Um Projekte erfolgreich planen zu können, müssen die richtigen Anforderungen in angemessenem Detailniveau verstanden und dokumentiert sein. Plangetriebene und agile Vorgehensweisen liefern den organisatorischen Rahmen zur Herstellung eines expliziten und impliziten gemeinsamen Verständnisses. Das Erkennen erfolgskritischer Projektinhalte obliegt der Verantwortung einzelner Rolleninhaber in den Vorgehensweisen – eine strukturierte Herangehensweise, um die Aspekte eines Projektes explizit zu machen, die über Erfolg und Misserfolg eines Projektes entscheiden können, existiert nicht. Um einen Beitrag zum Erfolg von IT-Projekten durch deren realistische Planung zu leisten, wird in dieser Arbeit der Interaction Room vorgestellt: Eine Methode, in der interdisziplinäre Teams pragmatische Modelle über das Verhalten sowie die Struktur eines Informationssystems in moderierten Workshops skizzieren. Sie kennzeichnen Wert-, Aufwands- und Risikotreiber in Modellskizzen, die auf Interaction-Room-Landkarten visualisiert werden. Dabei veranschaulicht die Feature-Landkarte den funktionalen Projekt-umfang. Die Prozesslandkarte veranschaulicht durch das Informationssystem unterstützte Prozesse zur Erfüllung der funktionalen Anforderungen. Die Objektlandkarte veranschaulicht erzeugte und verarbeitete Geschäftsobjekte und die Integrationslandkarte veranschaulicht direkte Schnittstellen des Informationssystems zu benachbarten Systemen sowie ausgetauschte Geschäftsobjekte. Die Kennzeichnung von Wert-, Aufwands- und Risikotreiber geschieht mit Hilfe von getypten Annotationen, die von den Stakeholdern des interdisziplinären Teams auf die Landkarten geheftet, im Anschluss diskutiert und dokumentiert werden. Durch die Annotationstypen lassen sich z. B. Werte für Nutzer, Flexibilitätsanforderungen und Ungewissheit kennzeichnen. Die Erkenntnisse aus Inter-action-Room-Workshops werden in eine pragmatische Struktur für Anforderungsdokumente überführt und können dadurch unmittelbar in Softwareprozessen weiter verwendet werden. Zwischen November 2011 und Februar 2017 wurden 23 Analyse-, Neuentwicklungs-, Weiterentwicklungs- und Migrationsprojekte mit Industriepartnern unterschiedlicher Branchen durchgeführt. Auf dieser Datenbasis wurden unterschiedliche Methodenparameter auf Zusammenhänge untersucht. Erwartungsgemäß bestehen positive Zusammenhänge zwischen Metriken der Projektgröße, zwischen dem Vorschlag zur Verwendung von Annotationstypen und deren tatsächlicher Verwendung, sowie zwischen der Menge verwendeter Annotationstypen und der Anzahl Duplikate. Außerdem besitzen die Inter-action-Room-Annotationen positiven Einfluss auf die Genauigkeit der Aufwandsschätzung. Die Planung von Entwicklungsiterationen kann durch Interaction-Room-Landkarten unterstützt werden, wodurch eine quantitative Verbesserung bei der Identifikation von Arbeitspaketen beobachtet wurde. Die Verbesserung besitzt positiven Einfluss auf die Fortschrittsmessung während einer Iteration und damit auf ihre Erfolgsprognose. Die Intervention kann in ein übliches Vorgehen zur Planung von Entwicklungsiterationen integriert werden, weil sie von den Planenden nicht als störend wahrgenommen wurde

    Modeling architectural non functional requirements: From use case to control case

    No full text
    While the functional requirements of a system can be effectively modeled through the Use Case driven approach, there is no standard or de facto method for modeling non-functional requirements of the system architecture. Often such requirements are dealt with in a reactive manner rather than proactively. Yet increasingly a contributing factor in project difficulty and failure are the non-functional requirements imposed on the solution architecture. This paper proposes a Control Case approach to record and model non-functional requirements. This technique enables the control case to represent the nonfunctional requirements from different perspectives, most typically the various operating conditions. Furthermore, we propose an extension to the “4+1" view model for depicting software architecture by adding the control case view. The combination of both the use case and control case views thus reflects the complete requirements across the collective system life cycle views: design, process, implementation and deployment
    corecore