Supporting software maintenance with non-functional information

The paper highlights the role of non functional information (about efficiency, reliability and other software attributes) of software components in software maintenance, focusing in the component programming framework. Non functional information is encapsulated in modules bound to both definitions and implementations of software components and it is written as expressions in a classical programming language. It is shown with an example how this notation supports software maintenance, with the help of an algorithm which is able to select the best implementation of a software component in its context of use, meaning byPeer ReviewedPostprint (published version

Towards Automating the Construction & Maintenance of Attack Trees: a Feasibility Study

Security risk management can be applied on well-defined or existing systems; in this case, the objective is to identify existing vulnerabilities, assess the risks and provide for the adequate countermeasures. Security risk management can also be applied very early in the system's development life-cycle, when its architecture is still poorly defined; in this case, the objective is to positively influence the design work so as to produce a secure architecture from the start. The latter work is made difficult by the uncertainties on the architecture and the multiple round-trips required to keep the risk assessment study and the system architecture aligned. This is particularly true for very large projects running over many years. This paper addresses the issues raised by those risk assessment studies performed early in the system's development life-cycle. Based on industrial experience, it asserts that attack trees can help solve the human cognitive scalability issue related to securing those large, continuously-changing system-designs. However, big attack trees are difficult to build, and even more difficult to maintain. This paper therefore proposes a systematic approach to automate the construction and maintenance of such big attack trees, based on the system's operational and logical architectures, the system's traditional risk assessment study and a security knowledge database.Comment: In Proceedings GraMSec 2014, arXiv:1404.163

Generic Continuity of Operations/Continuity of Government Plan for State-Level Transportation Agencies, Research Report 11-01

The Homeland Security Presidential Directive 20 (HSPD-20) requires all local, state, tribal and territorial government agencies, and private sector owners of critical infrastructure and key resources (CI/KR) to create a Continuity of Operations/Continuity of Government Plan (COOP/COG). There is planning and training guidance for generic transportation agency COOP/COG work, and the Transportation Research Board has offered guidance for transportation organizations. However, the special concerns of the state-level transportation agency’s (State DOT’s) plan development are not included, notably the responsibilities for the entire State Highway System and the responsibility to support specific essential functions related to the State DOT Director’s role in the Governor’s cabinet. There is also no guidance on where the COOP/COG planning and organizing fits into the National Incident Management System (NIMS) at the local or state-level department or agency. This report covers the research conducted to determine how to integrate COOP/COG into the overall NIMS approach to emergency management, including a connection between the emergency operations center (EOC) and the COOP/COG activity. The first section is a presentation of the research and its findings and analysis. The second section provides training for the EOC staff of a state-level transportation agency, using a hybrid model of FEMA’s ICS and ESF approaches, including a complete set of EOC position checklists, and other training support material. The third section provides training for the COOP/COG Branch staff of a state-level transportation agency, including a set of personnel position descriptions for the COOP/COG Branch members

Software Engineers' Information Seeking Behavior in Change Impact Analysis - An Interview Study

Software engineers working in large projects must navigate complex information landscapes. Change Impact Analysis (CIA) is a task that relies on engineers' successful information seeking in databases storing, e.g., source code, requirements, design descriptions, and test case specifications. Several previous approaches to support information seeking are task-specific, thus understanding engineers' seeking behavior in specific tasks is fundamental. We present an industrial case study on how engineers seek information in CIA, with a particular focus on traceability and development artifacts that are not source code. We show that engineers have different information seeking behavior, and that some do not consider traceability particularly useful when conducting CIA. Furthermore, we observe a tendency for engineers to prefer less rigid types of support rather than formal approaches, i.e., engineers value support that allows flexibility in how to practically conduct CIA. Finally, due to diverse information seeking behavior, we argue that future CIA support should embrace individual preferences to identify change impact by empowering several seeking alternatives, including searching, browsing, and tracing.Comment: Accepted for publication in the proceedings of the 25th International Conference on Program Comprehensio

IT process architectures for enterprises development: A survey from a maturity model perspective

During the last years much has been published about IT governance. Close to the success of many governance efforts are the business frameworks, quality models, and technology standards that help enterprises improve processes, customer service, quality of products, and control. In this paper we i) survey existing frameworks, namely ITIL, ASL and BiSL, ii) find relations with the IT Governance framework CobiT to determine if the maturity model of CobiT can be used by ITIL, ASL and BiSL, and (iii) provide an integrated vista of IT processes viewed from a maturity model perspective. This perspective can help us understand the importance of maturity models for increasing the efficiency of IT processes for enterprises development and business-IT alignment

Fine Grained Component Engineering of Adaptive Overlays: Experiences and Perspectives

Recent years have seen significant research being carried out into peer-to-peer (P2P) systems. This work has focused on the styles and applications of P2P computing, from grid computation to content distribution; however, little investigation has been performed into how these systems are built. Component based engineering is an approach that has seen successful deployment in the field of middleware development; functionality is encapsulated in ‘building blocks’ that can be dynamically plugged together to form complete systems. This allows efficient, flexible and adaptable systems to be built with lower overhead and development complexity. This paper presents an investigation into the potential of using component based engineering in the design and construction of peer-to-peer overlays. It is highlighted that the quality of these properties is dictated by the component architecture used to implement the system. Three reusable decomposition architectures are designed and evaluated using Chord and Pastry case studies. These demonstrate that significant improvements can be made over traditional design approaches resulting in much more reusable, (re)configurable and extensible systems

How do software architects consider non-functional requirements: an exploratory study

© 2012 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes,creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.Dealing with non-functional requirements (NFRs) has posed a challenge onto software engineers for many years. Over the years, many methods and techniques have been proposed to improve their elicitation, documentation, and validation. Knowing more about the state of the practice on these topics may benefit both practitioners' and researchers' daily work. A few empirical studies have been conducted in the past, but none under the perspective of software architects, in spite of the great influence that NFRs have on daily architects' practices. This paper presents some of the findings of an empirical study based on 13 interviews with software architects. It addresses questions such as: who decides the NFRs, what types of NFRs matter to architects, how are NFRs documented, and how are NFRs validated. The results are contextualized with existing previous work.Peer ReviewedPostprint (author’s final draft

Inter-organizational fault management: Functional and organizational core aspects of management architectures

Outsourcing -- successful, and sometimes painful -- has become one of the hottest topics in IT service management discussions over the past decade. IT services are outsourced to external service provider in order to reduce the effort required for and overhead of delivering these services within the own organization. More recently also IT services providers themselves started to either outsource service parts or to deliver those services in a non-hierarchical cooperation with other providers. Splitting a service into several service parts is a non-trivial task as they have to be implemented, operated, and maintained by different providers. One key aspect of such inter-organizational cooperation is fault management, because it is crucial to locate and solve problems, which reduce the quality of service, quickly and reliably. In this article we present the results of a thorough use case based requirements analysis for an architecture for inter-organizational fault management (ioFMA). Furthermore, a concept of the organizational respective functional model of the ioFMA is given.Comment: International Journal of Computer Networks & Communications (IJCNC