Security in agile software development: A practitioner survey

Context: Software security engineering provides the means to define, implement and verify security in software products. Software security engineering is performed by following a software security development life cycle model or a security capability maturity model. However, agile software development methods and processes, dominant in the software industry, are viewed to be in conflict with these security practices and the security requirements. Objective: Empirically verify the use and impact of software security engineering activities in the context of agile software development, as practiced by software developer professionals. Method: A survey (N=61) was performed among software practitioners in Finland regarding their use of 40 common security engineering practices and their perceived security impact, in conjunction with the use of 16 agile software development items and activities. Results: The use of agile items and activities had a measurable effect on the selection of security engineering practices. Perceived impact of the security practices was lower than the rate of use would imply: This was taken to indicate a selection bias, caused by e.g. developers’ awareness of only certain security engineering practices, or by difficulties in applying the security engineering practices into an iterative software development workflow. Security practices deemed to have most impact were proactive and took place in the early phases of software development. Conclusion: Systematic use of agile practices conformed, and was observed to take place in conjunction with the use of security practices. Security activities were most common in the requirement and implementation phases. In general, the activities taking place early in the life cycle were also considered most impactful. A discrepancy between the level of use and the perceived security impact of many security activities was observed. This prompts research and methodological development for better integration of security engineering activities into software development processes, methods, and tools.</p

Understanding Work Practices of Autonomous Agile Teams: A Social-psychological Review

The purpose of this paper is to suggest additional aspects of social psychology that could help when making sense of autonomous agile teams. To make use of well-tested theories in social psychology and instead see how they replicated and differ in the autonomous agile team context would avoid reinventing the wheel. This was done, as an initial step, through looking at some very common agile practices and relate them to existing findings in social-psychological research. The two theories found that I argue could be more applied to the software engineering context are social identity theory and group socialization theory. The results show that literature provides social-psychological reasons for the popularity of some agile practices, but that scientific studies are needed to gather empirical evidence on these under-researched topics. Understanding deeper psychological theories could provide a better understanding of the psychological processes when building autonomous agile team, which could then lead to better predictability and intervention in relation to human factors

Challenges in Scaling Agile Software Development

Many challenges arise when agile software development methods are being used on larger scale. This thesis consists of two parts. First the thesis will go through the traditional software development processes and compare them to iterative and agile software development practices such as Scrum. Agile methods are represented so that the theory can be used on a basis of scaling analysis. For example queuing theory is relevant when using lean principles and working with larger batches. The most common practices are explained such as Test Driven Development, Continuous Integration and Extreme Programming. Different aspects of scaling issues and solutions, when working with large or distributed teams, are represented. These include the Scrum of Scrums model, agile release train and different requirements in the global delivery. Second part of the thesis is the survey which was conducted to a few software industry professionals. Their answers are being analyzed and represented with two related surveys. /Kir10 Keywords: Agile software development, lean, agile, global delivery, Scrum, agile at scal

Technical debt and agile software development practices and processes: An industry practitioner survey

Context: Contemporary software development is typically conducted in dynamic, resource-scarce environments that are prone to the accumulation of technical debt. While this general phenomenon is acknowledged, what remains unknown is how technical debt specifically manifests in and affects software processes, and how the software development techniques employed accommodate or mitigate the presence of this debt.Objectives: We sought to draw on practitioner insights and experiences in order to classify the effects of agile method use on technical debt management, given the popularity and perceived success of agile methods. We explore the breadth of practitioners’ knowledge about technical debt; how technical debt is manifested across the software process; and the perceived effects of common agile software development practices and processes on technical debt. In doing so, we address a research gap in technical debt knowledge and provide novel and actionable managerial recommendations.Method: We designed, tested and executed a multi-national survey questionnaire to address our objectives, receiving 184 responses from practitioners in Brazil, Finland, and New Zealand.Results: Our findings indicate that: 1) Practitioners are aware of technical debt, although, there was under utilization of the concept, 2) Technical debt commonly resides in legacy systems, however, concrete instances of technical debt are hard to conceptualize which makes it problematic to manage, 3) Queried agile practices and processes help to reduce technical debt; in particular, techniques that verify and maintain the structure and clarity of implemented artifacts (e.g., Coding standards and Refactoring) positively affect technical debt management.Conclusions: The fact that technical debt instances tend to have characteristics in common means that a systematic approach to its management is feasible. However, notwithstanding the positive effects of some agile practices on technical debt management, competing stakeholders’ interests remain a concern.</div

Establishing Guidelines for Medical Device Software Development Using Agile - Case: Start-up’s Infant Apnoea Monitor

Software has become a prominent part of modern medical devices. In order to ensure safety of patients and users of medical devices, health authorities around the world have produced a number of regulations that control the development, manufacturing and sales of medical devices. Software which is part of a medical device must meet the same safety and quality requirements as the device itself. In Europe, Directive 2007/47/EC regulates the development and manufacturing of medical devices. International standardization organizations have produced harmonized standards such as IEC 62304 – medical device software – software life cycle processes to assist the manufacturers of medical devices in obtaining regulatory approvals. In recent years a new way to develop software known as Agile has emerged. Agile methods are based on an iterative and evolutionary software development life cycle. Although regulators do not mandate what software life cycle should be used, most of the regulations and standards assume a linear life cycle, such as waterfall. The Agile practices emerge from a common set of values and principles, such as quality of the software, productivity of the development teams and customer satisfaction. In this thesis we discuss how these values align with those of health authorities and regulators around the world. In this thesis we Introduce the Agile SW development practices in the context of a medical device company. We will analyze the European Medical Device Directives and international standards. We then propose a set of guidelines for the development of medical device software based on Agile practices while complying with the international standards

An approach to reconcile the agile and CMMI contexts in product line development

Software product line approaches produce reusable platforms and architectures for products set developed by specific companies. These approaches are strategic in nature requiring coordination, discipline, commonality and communication. The Capability Maturity Model (CMM) contains important guidelines for process improvement, and specifies "what" we must have into account to achieve the disciplined processes (among others things). On the other hand, the agile context is playing an increasingly important role in current software engineering practices, specifying "how" the software practices must be addressed to obtain agile processes. In this paper, we carry out a preliminary analysis for reconciling agility and maturity models in software product line domain, taking advantage of both.Postprint (published version

Software systems engineering: a journey to contemporary agile and beyond, do people matter?

publishedVersio

Software systems engineering: a journey to contemporary agile and beyond, do people matter?

It is fascinating to view the evolution of software systems engineering over the decades. At the first glance, it could be perceived that the various approaches and processes are different. Are they indeed different? This paper will briefly discuss such a journey relating to findings from an empirical study in some organisations in the UK. Some of the issues described in the literature and by practitioners are common across different software system engineering approaches over the time. It can be argued that human-element of software development plays an integral part in the success of software systems development endeavour. After all, software engineering is a human-centric craft. In order to understand such issues, we crossed the discipline to other disciplines in order to adapt theories and principles that will help to better understand and tackle such matter. Other disciplines have well established human related theories and principles that can be useful. From Japanese management philosophies, we have adapted Lean and knowledge management theories. From psychology, we have adapted Emotional Intelligence (EI). With such an interdisciplinary view, some of the issues can be addressed adequately. Which bring the question: is it really the process or the people? The second author will reflect on his experience attending the first SQM conference 25 years ago. The reflection will discuss the evolution of software systems engineering, and what was changed since then, if at all changed