Currently, security is frequently considered late in software life cycle. It is often bolted on late in development, or even during deployment or maintenance, through activities such as add-on security software and penetration-and-patch maintenance. Even if software developers aim to incorporate security into their products from the beginning of the software life cycle, they face an exhaustive amount of ad hoc unstructured information without any practical guidance on how and why this information should be used and what the costs and benefits of using it are. This is due to a lack of structured methods. In this thesis we present a model for secure software development and implementation of a security plug-in that deploys this model in software life cycle. The model is a structured unified process, named S3P (Sustainable Software Security Process) and is designed to be easily adaptable to any software development process. S3P provides the formalism required to identify the causes of vulnerabilities and the mitigation techniques that address these causes to prevent vulnerabilities. We present a prototype of the security plug-in implemented for the OpenUP/Basic development process in Eclipse Process Framework. We also present the results of the evaluation of this plug-in. The work in this thesis is a first step towards a general framework for introducing security into the software life cycle and to support software process improvements to prevent recurrence of software vulnerabilities. / <p>Report code: LiU-Tek-Lic-2008:11.</p>

Dependent type theory is a proven technology for verified functional programming in which programs and their correctness proofs may be developed using the same rules in a single formal system. In practice, large portions of programs developed in this way have no computational relevance to the ultimate result of the program and should therefore be removed prior to program execution. In previous work on identifying and removing irrelevant portions of programs, computational irrelevance is usually treated as an intrinsic property of program expressions. We find that such an approach forces programmers to maintain two copies of commonly used datatypes: a computationally relevant one and a computationally irrelevant one. We instead develop an extrinsic notion of computational irrelevance and find that it yields several benefits including (1) avoidance of the above mentioned code duplication problem; (2) an identification of computational irrelevance with a highly general form of parametric polymorphism; and (3) an elective (i.e., user-directed) notion of proof irrelevance. We also develop a program analysis for identifying irrelevant expressions and show how previously studied types embodying computational irrelevance (including subset types and squash types) are expressible in the extension of type theory developed herein.

Requirements, key artifacts of requirements engineering, are a fundamental part of any software development, used by the different software development roles in their activities, such as designing the interface for a feature, its development, and the creation of test cases made by testers. This study aims to investigate the impact of misalignment in the use, understanding, and intent of requirements between the requirements engineers that create the requirements and other software roles that use them in their work activities and betweendevelopers and testers in their software development and testing activities. The impacted areas that this study focuses on are the work activities of the different roles involved with requirements in the development process, their workload, and their well-being and morale.The two research objectives are:i) How do software development practitioners define the quality of requirements?ii) How do the perceived quality of requirements impact the work of the different roles involved in the software development process?This study was performed as a descriptive interview study that follows the case study guidelines written by Runeson and Höst [14] at a sub-organization of a Nordic bank that developed their own web and apps. The data collection comprises interviewing 20 practitioners:requirements engineers, developers, testers, and newly employed developers, with fiveinterviewees from each group.The results of this study show that there are, in fact, different views across different roles of what makes a requirement good. There are also some similarities between the general characteristics described by the practitioners that they perceive make requirements good and the characteristics described in the ISO [21] and IREB [26] standards.The practitioners stated that, in general, they experienced negative feelings, more work,and overhead communication when they worked with requirements they perceived to be bad. The practitioners also described in general positive effects on their work and feelings when they worked with requirements that they perceived to be good.A conclusion that can be drawn from the study is that the quality of requirements and the requirements engineering process matter to software development and can have big impacts on the morale and effectiveness, and efficiency of the different roles that work with the requirements.

No description available.

Context: Acceptance testing is an important activity that verifies the conformance of a system to its acceptance criteria. It aims to provide a detailed communication of domain knowledge and is used to evaluate whether the customer requirements are met. Existing literature lacks empirical evidence for acceptance testing. Especially in the context of industry practice, it is not in the authors' consideration, except for a few studies, where the authors have investigated the state of practice in a specific domain. Objective: This study aims to recognize the state of research and practice of acceptance testing in Agile Software Development and investigate the similarities and differences in both perspectives. The study contributes to identify the industry-academia gap in the context of acceptance testing. Research Method: To identify the acceptance testing practices and challenges from research, I have conducted a literature review. For the industry perspective on acceptance testing practices and challenges, I have conducted an interview-based survey of the practitioners working in the Agile Software Development environment. I followed the snowball search strategy to search the primary studies, whereas to select the respondents, I used the convenience and snowball sampling method. For data analysis, I followed the approach of thematic synthesis. Results: The results of this thesis are the outcome of a literature review of 20 selected studies and an interview-based survey with 12 practitioners representing10 companies. I identified acceptance testing practices and challenges from research and industry. In the research, the most recommended form of acceptance testing is acceptance test-driven development (ATDD), and the majority of the studies are referring to the use of FIT for acceptance testing. Customer involvement in different phases of acceptance testing is recommended in research. From the interviews, I come across that acceptance testing is manual at large in the industry, and the most challenging aspect is the customer’s involvement. Conclusions: From the findings of this thesis, it is concluded that there is a gap between the research and industry perspective of acceptance testing practices. Currently, acceptance testing in the industry is mostly manual, the research is not focusing on this aspect of acceptance testing. Despite the differences, there are some commonalities as well. Especially, most challenges of acceptance testing are similar in both perspectives. Researchers have to consider the commonalities, and they have to look at how they can minimize the acceptance testing challenges from the perspective of the industry.

Traditional software development methodologies are historically used for the creation of software products in separate departments, namely development and operations departments. The development department typically codes and tests the software, whilst the operations department is responsible for its deployment. This siloed arrangement is not aligned to modern practices, which require a timeous response to changes without necessarily delaying the product release. DevOps culture addresses this silos problem by creating an enabling environment for the two departments to collaborate throughout the software development life cycle. The successful implementation of the DevOps culture should give an organisation a competitive advantage over its rivals by responding to changes much faster than when traditional methodologies are employed. However, there is no coherent framework on how organisations should implement DevOps culture. Hence, this study was aimed at developing a framework for the implementation of DevOps culture by identifying important factors that should be included in the framework. The literature survey revealed that open communication, roles and responsibility alignment, respect and trust are the main factors that constitute DevOps collaboration culture. The proposed framework was underpinned by the Information System Development Model which suggests that the acceptance of a new technology by software developers is influenced by social norm, organisational usefulness and perceived behavioural control. A sequential mixed method was used to survey and interview respondents from South Africa, which were selected using convenience and purposive sampling. Statistical analysis of the quantitative data acquired through the questionnaire followed by a qualitative analysis of interviews were undertaken. The results showed that open communication, respect and trust are the key success factors to be included in the framework. The role and responsibility factor was found not to be statistically significant. This study contributes towards the understanding of factors necessary for the acceptance of DevOps culture in a software development organisation. DevOps managers can use the results of this study to successfully adopt and implement DevOps culture. This study also contributes to the theoretical literature on software development by identifying factors that are important in the acceptance of DevOps collaboration culture. / School of Computing / Ph. D. (Computer Science)

This thesis investigates the concept of citizen developers, in which employees in an organisation take on the role of developers and create software using low-code tools. The primary focus of this report is to examine the necessary steps an organisation must take when introducing citizen developers, particularly regarding solution maintenance. The purpose, therefore, is to establish a foundation for utilising the concept of citizen developers in the workplace, bridging the gap between users and developers. Furthermore, this study aims to explore the organisational structure required to incorporate citizen developers and identify the advantages and drawbacks associated with an organisational structure tailored for citizen developers. Citizen developers possess distinct roles and responsibilities within an organisation, making them experts in their respective fields. This expertise renders citizen developers a valuable resource, as they develop solutions to enhance their own work efficiency and effectiveness. A case company has been selected for this study, and interviews have been conducted with multiple employees from the organisation. Through analysis of these interviews and a comprehensive literature review, a governance model has been developed. The governance model delineates the level of responsibility citizen developers should assume, and an evaluation of the model also uncovers potential advantages and drawbacks of introducing citizen developers within an organisation. Ultimately, this thesis aims to contribute to research on the subject of citizen developers, with particular emphasis on solution maintenance.

Low-code development is an alternative to regular software development where the developer is able to build software and websites using a drag and drop interface instead of writing code. Low-code development has gained popularity in recent years, one of the reasons for this is the broader targeted audience which is citizen developers, people with no previous knowledge and experience in programming and web development. However it is unclear if low-code development can uphold the standards set by software development best practices. The purpose of this study is to investigate how low-code development corresponds to best practices in software development. Maintainability, flexibility, portability, reusability, readability, and testability are the six best practices that are specifically investigated in this study. Design and creation was used as the methodology to investigate whether these best practices can be used in low-code development. A system and a website was built in partnership with CGI, using Microsoft Power Platform as the low-code development tool.  The findings of the study indicate that low-code development has a number of limitations when compared to best practices in software development. The limited ability to customize code makes it difficult to accomplish maintainability, flexibility, and testability in low-code development. Additionally, it might be challenging to accomplish portability because low-code development platforms are not always interoperable, and reusability is limited due to the differences in implementation between platforms. Furthermore, it is often difficult to follow the logic flow of a low-code system which makes readability a challenge in low-code development.  While some best practices can be adapted to low-code development, the study draws the conclusion that low-code development still has a long way to go before it can fully live up to best practices in software development. In summary, this study highlights the limitations of low-code development in comparison to best practices for software development and proposes that additional research is required to overcome these limitations.

Many large companies use various business intelligence solutions to filter, process, and visualize their software source code repository data. These tools focus on improving continuous integration and are used to get insights about people, products, and projects in the organization. However, research has shown that the quality of measurement programs in software engineering often is low since the science behind them is unexplored. In addition, code repositories contain a considerable amount of information about the developers, and several ethical and legal aspects need to be considered before using these tools, such as compliance with GDPR. This thesis aims to investigate how companies can use repository metrics and these business intelligence tools in a safe and valuable way. In order to answer the research questions, a case study was conducted in a Swedish company, and repository metrics from a real business intelligence tool were analyzed based on several questions. These questions were related to software measurement theory, ethical and legal aspects of software engineering and metrics, and institutionalized theory. The results show how these metrics could be of value to a company in different ways, for instance by visualization collaboration in a project or by differentiating between read and active repositories. These metrics could also be valuable by linking them to other data in the company such as bug reports and repository downloads. The findings show that the visualizations could potentially be perceived as a type of performance monitoring by developers, causing stress and unhealthy incitements in the organization. In addition, repository metrics are based on identifiable data from Git, which according to the GDPR is classified as personal data. Further, there is a risk that these tools are used simply because they are available, as a way to legitimize the company. In order to mitigate these risks, the thesis states that the metrics should be anonymized, and the focus of the metrics should be on teams and processes rather than individual developers. The teams themself should be a part of creating the Goal-Question-Metrics that link the metrics to what the teams wish to establish.

No description available.