Boundary Objects and their Use in Agile Systems Engineering

Agile methods are increasingly introduced in automotive companies in the attempt to become more efficient and flexible in the system development. The adoption of agile practices influences communication between stakeholders, but also makes companies rethink the management of artifacts and documentation like requirements, safety compliance documents, and architecture models. Practitioners aim to reduce irrelevant documentation, but face a lack of guidance to determine what artifacts are needed and how they should be managed. This paper presents artifacts, challenges, guidelines, and practices for the continuous management of systems engineering artifacts in automotive based on a theoretical and empirical understanding of the topic. In collaboration with 53 practitioners from six automotive companies, we conducted a design-science study involving interviews, a questionnaire, focus groups, and practical data analysis of a systems engineering tool. The guidelines suggest the distinction between artifacts that are shared among different actors in a company (boundary objects) and those that are used within a team (locally relevant artifacts). We propose an analysis approach to identify boundary objects and three practices to manage systems engineering artifacts in industry

Rethinking Security Incident Response: The Integration of Agile Principles

In today's globally networked environment, information security incidents can inflict staggering financial losses on organizations. Industry reports indicate that fundamental problems exist with the application of current linear plan-driven security incident response approaches being applied in many organizations. Researchers argue that traditional approaches value containment and eradication over incident learning. While previous security incident response research focused on best practice development, linear plan-driven approaches and the technical aspects of security incident response, very little research investigates the integration of agile principles and practices into the security incident response process. This paper proposes that the integration of disciplined agile principles and practices into the security incident response process is a practical solution to strengthening an organization's security incident response posture.Comment: Paper presented at the 20th Americas Conference on Information Systems (AMCIS 2014), Savannah, Georgi

Enhancing security incident response follow-up efforts with lightweight agile retrospectives

Security incidents detected by organizations are escalating in both scale and complexity. As a result, security incident response has become a critical mechanism for organizations in an effort to minimize the damage from security incidents. The final phase within many security incident response approaches is the feedback/follow-up phase. It is within this phase that an organization is expected to use information collected during an investigation in order to learn from an incident, improve its security incident response process and positively impact the wider security environment. However, recent research and security incident reports argue that organizations find it difficult to learn from incidents. A contributing factor to this learning deficiency is that industry focused security incident response approaches, typically, provide very little practical information about tools or techniques that can be used to extract lessons learned from an investigation. As a result, organizations focus on improving technical security controls and not examining or reassessing the effectiveness or efficiency of internal policies and procedures. An additional hindrance, to encouraging improvement assessments, is the absence of tools and/or techniques that organizations can implement to evaluate the impact of implemented enhancements in the wider organization. Hence, this research investigates the integration of lightweight agile retrospectives and meta-retrospectives, in a security incident response process, to enhance feedback and/or follow-up efforts. The research contribution of this paper is twofold. First, it presents an approach based on lightweight retrospectives as a means of enhancing security incident response follow-up efforts. Second, it presents an empirical evaluation of this lightweight approach in a Fortune 500 Financial organization's security incident response team

Exploring the importance of reflection in the control room

While currently difficult to measure or explicitly design for, evidence suggests that providing people with opportunities to reflect on experience must be recognized and valued during safety-critical work. We provide an insight into reflection as a mechanism that can help to maintain both individual and team goals. In the control room, reflection can be task-based, critical for the 'smooth' day-to-day operational performance of a socio-technical system, or can foster learning and organisational change by enabling new understandings gained from experience. In this position paper we argue that technology should be designed to support the reflective capacity of people. There are many interaction designs and artefacts that aim to support problem-solving, but very few that support self-reflection and group reflection. Traditional paradigms for safety-critical systems have focussed on ensuring the functional correctness of designs, minimising the time to complete tasks, etc. Work in the area of user experience design may be of increasing relevance when generating artefacts that aim to encourage reflection

Role clarity deficiencies can wreck agile teams

Background One of the twelve agile principles is to build projects around motivated individuals and trust them to get the job done. Such agile teams must self-organize, but this involves conflict, making self-organization difficult. One area of difficulty is agreeing on everybody’s role. Background What dynamics arise in a self-organizing team from the negotiation of everybody’s role? Method We conceptualize observations from five agile teams (work observations, interviews) by Charmazian Grounded Theory Methodology. Results We define role as something transient and implicit, not fixed and named. The roles are characterized by the responsibilities and expectations of each team member. Every team member must understand and accept their own roles (Local role clarity) and everbody else’s roles (Team-wide role clarity). Role clarity allows a team to work smoothly and effectively and to develop its members’ skills fast. Lack of role clarity creates friction that not only hampers the day-to-day work, but also appears to lead to high employee turnover. Agile coaches are critical to create and maintain role clarity. Conclusions Agile teams should pay close attention to the levels of Local role clarity of each member and Team-wide role clarity overall, because role clarity deficits are highly detrimental

Towards the Model-Driven Engineering of Secure yet Safe Embedded Systems

We introduce SysML-Sec, a SysML-based Model-Driven Engineering environment aimed at fostering the collaboration between system designers and security experts at all methodological stages of the development of an embedded system. A central issue in the design of an embedded system is the definition of the hardware/software partitioning of the architecture of the system, which should take place as early as possible. SysML-Sec aims to extend the relevance of this analysis through the integration of security requirements and threats. In particular, we propose an agile methodology whose aim is to assess early on the impact of the security requirements and of the security mechanisms designed to satisfy them over the safety of the system. Security concerns are captured in a component-centric manner through existing SysML diagrams with only minimal extensions. After the requirements captured are derived into security and cryptographic mechanisms, security properties can be formally verified over this design. To perform the latter, model transformation techniques are implemented in the SysML-Sec toolchain in order to derive a ProVerif specification from the SysML models. An automotive firmware flashing procedure serves as a guiding example throughout our presentation.Comment: In Proceedings GraMSec 2014, arXiv:1404.163