Readiness model for DevOps implementation in software organizations

<div align="center"><span lang="EN-US">DevOps software development approach is widely used in the software engineering discipline. DevOps eliminates the development and operations department barriers. The paper aims to develop a conceptual model for adopting DevOps practices in software development organizations by extending the unified theory of acceptance and use of technology (UTAUT). The research also aims to determine the influencing factors of DevOps practices’ acceptance and adoption in software organizations, determine gaps in the software development literature, and introduce a clear picture of current technology acceptance and adoption research in the software industry. A comprehensive literature review clarifies how users accept and adopt new technologies and what leads to adopting DevOps practices in the software industry as the starting point for developing a conceptual framework for adopting DevOps in software organizations. The literature results have formulated the conceptual framework for adopting DevOps practices. The resulting model is expected to improve understanding of software organizations’ acceptance and adoption of DevOps practices. The research hypotheses must be tested to validate the model. Future work will include surveys and expert interviews for model enhancement and validation. This research fulfills the necessity to study how software organizations accept and adopt DevOps practices by enhancing UTAUT.</span></div>

work of W. Edwards Deming has convinced industry that must first measure quality and then emphasise process to improve quality. In response to Deming's arguments and in light of perception that software industry is unable to produce quality products on schedule, and within budget, more software development organisations are now emphasising process measurement, monitoring, and assessment. This paper describes what is meant by software process and discusses an approach for its measurement and improvement. INTRODUCTION Unreliable software makes big news, from emergency services disasters to social security payment blunders. Improved software quality is essential to ensure reliable products and services, and gain customer satisfaction. While software development has existed for more than four decades, we failed so far to make as an industry and as an engineering discipline rather than craft. Developing reliable and usable software that is delivered on and within budget still represents difficult endeavour for many organisations. As role of software becomes increasingly critical for businesses as well as for human lives, problems caused by software products that are late, over budget, or that do not work, become magnified. If lives are lost or people inconvenienced due to incapable computer software, news media is there to make big stories. Organisations are realising that their fundamental problems is immaturity of their software process. Robert Lai (1993) proposes that process improvement is second maturity wave of software industry. He states that the first wave of software was developed using waterfall model in 1970's. Today we are Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517 216 Software Management in midst of second wave maturity movement as we attempt to formally define development process and best ways to continuously improve it (Lai 1993). Taking lead in this area has been Watts Humphrey (Humphrey 1989, 1990, 1991), and Software Engineering Institute (SEI) at Carnegie Mellon University. SEI started in 1986 to develop process maturity framework to help organisations appraise maturity of their software process, and to provide guidance for organisations to improve their software process capability. A brief description of framework was released in September 1987, including maturity questionnaire. SEI evolved model and questionnaire into 5 -Level Capability Maturity Model (CMM) in 1991. In February 1993, released CMM version 1.1 (Paulk et al 1993). This paper discusses software process and describes capability maturity model (CMM). It also shows how CMM can be used as basis to measure maturity of software process of an organisation and plan its improvement. SOFTWARE QUALITY AND PROCESS IMPROVEMENT In his book Quality is Free Phil Crosby states that: Quality is free. It is not gift, is free. What cost money are unqualify of things all actions that involve not doing jobs right first time (Crosby 1980). If such statement is true for many disciplines, is particularly true for evidence is abundant in number of software products which exceeded their budget, were produced late, failed to satisfy user requirements, and are full of bugs. demand for improved software quality is increasing to ensure reliable products and services. benefits of improved quality comes in form of reduction in failure costs. For software projects failure costs include (DTI 1992): • costs of correcting defects, both before and after delivery • overruns against and budget • unnecessary high maintenance costs • indirect costs which users incur due to poor quality software link between process maturity and software quality is expressed in premise that The quality of software system is governed by quality of process used to develop and maintain it. One stumbling block to improving software quality seems to be that not enough attention is paid to overall development process itself. While software professionals typically devote their to developing, testing or documenting software products, no one has prime responsibility for improving software process. Experience has shown that if Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517 Managing Systems 217 no one is working on software process, orderly improvement is unlikely. process certainly won't improve itself, rather, most likely, will deteriorate over time. Continuous improvement can occur only if process infrastructure is in place. Watts Humphrey argues in an early article published in Datamation, April 1989 that: Without work on process, there will be little or no progress in improving software. THE SOFTWARE PROCESS Adopting process view of software development represents revolutionary change in perspective. A process orientation to software development involves elements of structure, focus, measurement, ownership, skills, and supporting technology. In this section we investigate what is meant by software process. What Is Software Process According to Webster's dictionary, process is a system of operations in producing something .. series of actions, changes, or functions that achieve an end result. Chambers Concise Dictionary defines process as a series of actions or events .. sequence of operations or changes undergone. IEEE defines process as a sequence of steps performed for given purpose. In general business context, process is defined as a structured, measured set of activities designed to produce specified output for particular customer or market (Davenport 1993). These definitions put strong emphasis on HOW work is done, in contrast to product focus's emphasis on WHAT. Accordingly, process can be considered as a specific ordering of work activities across and place, with beginning, an end, and clearly identified inputs and outputs: structure for action. In this paper we will adopt following definitions quoted in (Humphrey 1990, Paulk et al 1993) are intended to encompass software throughout its life, which covers new development, enhancement, and repair. software process is The set of activities, methods, and practices used in production and evolution of software. software engineering process is The total set of software engineering activities needed to transform user's requirements into software. Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517 218 Software Management People and Software Process Software development is still people-intensive activity. Talented people are most important element in any software organisation. Even if you get best people available, if they do not follow common process, if everyone wrote in different programming languages, used different conventions, or didn't co-ordinate their design and code changes with their peers, results will be chaos. Successful software organisations have learned that even best professionals need structured and disciplined environment in which to do cooperative work. Software organisations that do not establish such disciplines condemn their people to endless hours of repetitively solving technically trivial problems. obvious fact is that attracting best people is vital, but is also essential to support them with an effectively managed software process. Technology and Software Process Another myth is widespread belief that some technologically advanced tool or method will provide magic answer to software crisis. This is not only wrong, but is dangerous. Organisations which jumped on bandwagon of CASE tools, and ended up in failure and wasted and effort have learned their lesson hard way. Just ask yourself before introducing technology: What do I want to automate? In absence of defined, practised, and managed process, introducing automation can lead to increased chaos. There are several factors which limit effective use of software technology: an illdefined process, inconsistent process implementation, and poor process management. Software technology cannot be fully effective until these problems have been properly addressed. Need for Defined Process If no effort is made to define and enhance software development process across whole organisation, each software development project latches on to its own tools, methods, and practices with little guidance available on how to use them. This ad hoc approach will not be sufficient to tackle task of developing complex software systems. goal of software process management is to enable organisations to produce software that meets cost, schedules, and quality objectives. principles are same that underpins statistical process control-principles that have been successfully used in controlling scientific experiments and in high -volume manufacturing operations. Statistical concepts have been found to be just as applicable to software development as they are to production of manufactured goods such as motor cars. Applying such concepts will only be possible if there is defined and managed process. Software Process Models Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517

Software process is the most important part of software project management, and software process models are important means of implementing the software process in any software organization. When there is need to improve the software process, then the need to improve the work-task part (software process models) of the software process must arise. As, there is need of increasing the commitment of software project managers through out the software development life cycle (SDLC), so we need to give them the list of activities in Waterfall Model, which should be made efficient by the software development team, to get the 80% productivity (output) easily, by reducing the effort of software development and ultimately increasing the performance of the software process. So, the idea of 80/20 rule (Pareto Principle, 1935) can be applied in the software engineering process model, in this regard. The Pareto Principle (1935) directed us to focus on what is really important in any field and field's work. Software process is most important part of software project management (SPM). This is also then ultimately needed for software project management (SPM) improvement. Our main research work is to improve the work-task part of the software process (i.e. software process models by applying the Pareto Principle - 80/20 Rule (1935) (or law of vital few) (1935), in the software engineering process models (or work-task part of the software process). This will be to facilitate the software project manager, using the software process models practically more efficient than without application of 80/20 Rule in software engineering Waterfall model. This has resulted in the reduction of the software development effort and increase in the performance of the software process. The results (efficient and improved software process models) will be implemented in the software industry, by software project managers, by focusing on the list of activities giving 80 percent of the overall productivity of the software process. The results will be the list of activities having the capability to give 20 percent of the overall productivity of the software Waterfall process, to be ignored, eliminated or designated to reduce the effort.

Background: As contemporary software development organizations are dominated by males, occurrences of misogynistic and sexist remarks are abundant in many communities. Such remarks are barriers to promoting diversity and inclusion in the software engineering (SE) domain. Aims: This study aims to develop a rubric to identify misogynistic remarks and sexist jokes specifically from software developer communications. Method: We have followed the systematic literature review protocol to identify 10 primary studies that have characterized misogynistic and sexist texts in various domains. Results: Based on our syntheses of the primary studies, we have developed a rubric to manually identity various categories of misogynistic or sexist remarks. We have also provided SE domain specific examples of those categories. Conclusions: Our annotation guideline will pave the path towards building automated misogynistic text classifier for the SE domain.

Background: Systematic literature reviews (SLRs) have become an established methodology in software engineering (SE) research however they can be very time consuming and error prone. Aim: The aims of this study are to identify and classify tools that can help to automate part or all of the SLR process within the SE domain. Method: A mapping study was performed using an automated search strategy plus snowballing to locate relevant papers. A set of known papers was used to validate the search string. Results: 14 papers were accepted into the final set. Eight presented text mining tools and six discussed the use of visualisation techniques. The stage most commonly targeted was study selection. Only two papers reported an independent evaluation of the tool presented. The majority were evaluated through small experiments and examples of their use. Conclusions: A variety of tools are available to support the SLR process although many are in the early stages of development and usage.

The evidence-based software engineering approach advocates the use of evidence from empirical studies to support the decisions on the adoption of software technologies by practitioners in the software industry. To this end, many guidelines have been proposed to contribute to the execution and repeatability of literature reviews, and to the confidence of their results, especially regarding systematic literature reviews (SLR). To investigate similarities and differences, and to characterize the challenges and pitfalls of the planning and generated results of SLR research protocols dealing with the same research question and performed by similar teams of novice researchers in the context of the software engineering field. We qualitatively compared (using Jaccard and Kappa coefficients) and evaluated (using DARE) same goal SLR research protocols and outcomes undertaken by similar research teams. Seven similar SLR protocols regarding quality attributes for use cases executed in 2010 and 2012 enabled us to observe unexpected differences in their planning and execution. Even when the participants reached some agreement in the planning, the outcomes were different. The research protocols and reports allowed us to observe six challenges contributing to the divergences in the results: researchers' inexperience in the topic, researchers' inexperience in the method, lack of clearness and completeness of the papers, lack of a common terminology regarding the problem domain, lack of research verification procedures, and lack of commitment to the SLR. According to our findings, it is not possible to rely on results of SLRs performed by novices. Also, similarities at a starting or intermediate step during different SLR executions may not directly translate to the next steps, since non-explicit information might entail differences in the outcomes, hampering the repeatability and confidence of the SLR process and results. Although we do have expectations that the presence and follow-up of a senior researcher can contribute to increasing SLRs' repeatability, this conclusion can only be drawn upon the existence of additional studies on this topic. Yet, systematic planning, transparency of decisions and verification procedures are key factors to guarantee the reliability of SLRs.

The software development industry or organizations increasingly emerging day by day have adopted global software development (GSD) practices due to the large significance of outsourcing. These industries face many challenges due to a lack of understanding customer perspective in the GSD environment. For any organization, the customer is the major stakeholder, and customer relationship management (CRM) plays a vital role in customer satisfaction with software development projects. These challenges create serious risks for any software development project’s success. Thus, CRM is a crucial challenge in the success of software projects in the GSD environment. This research study aims to address the factors that negatively influence CRM implementation in the global context and proposes a conceptual model based on the identified factors for enhancing software product quality. The systematic literature review (SLR) phase investigates the potential barriers to CRM implementation in GSD. Based on identified barriers, an initial conceptual model is developed. The proposed conceptual model is validated using a questionnaire survey of the GSD industry and CRM practitioners of Pakistan. Statistical analysis and several suitable tests are also performed to develop the final conceptual model for CRM implementation in the GSD environment. This research is performed from the client’s perspective. The results are promising and accommodating to avoid any software project failure due to customer-related issues in a GSD environment.

A process capability based assessment model for software workforce in emergent software organizations

: In this era of increasingly complex software and mushrooming software development and maintenance costs, the software engineering community needs to improve its practices to remain competitive and to produce software that can meet complex software requirements. Projects often overrun costs, miss deadlines, and fail to meet the requirements of the customer. Now new software process technologies are evolving to help address these concerns in the areas of process assessment, definition, simulation, and enactment. A software process is a set of activities, methods, practices, and transformations that people use to develop and maintain software and associated products. The quality of a product stems, in large part, from the quality of the process used to create it. To consistently improve products, the process used for developing them should be understood, defined, measured, and progressively improved. Software process assessment is the act of determining the maturity of an organization's software process. Software process definition is the act of specifying in some detail an organization's software process. Software process simulation is the act of executing a software process definition. The term modeling will often be used in this report to encompass both process definition and simulation. The term enactment denotes the use of a formal process definition to guide and control the software process. In this report, software process technologies will be described, their benefits outlined, and their implications assessed. Technology maturity will be discussed and recommendations will be given for technologies that can be effectively used today.

Transformers are the current state-of-the-art of natural language processing in many domains and are using traction within software engineering research as well. Such models are pre-trained on large amounts of data, usually from the general domain. However, we only have a limited understanding regarding the validity of transformers within the software engineering domain, i.e., how good such models are at understanding words and sentences within a software engineering context and how this improves the state-of-the-art. Within this article, we shed light on this complex, but crucial issue. We compare BERT transformer models trained with software engineering data with transformers based on general domain data in multiple dimensions: their vocabulary, their ability to understand which words are missing, and their performance in classification tasks. Our results show that for tasks that require understanding of the software engineering context, pre-training with software engineering data is valuable, while general domain models are sufficient for general language understanding, also within the software engineering domain.

Systems, software, and quality engineering: Applying defect behavior theory to programming: Arthur E Ferdinand Van Nostrand Reinhold New York (1993) 416 pp £51.50 ISBN 0 442 01730 8

A systematic literature review on software measurement programs

Background: Software organizations increasingly need developers with high skills for social interactions. Managers, leaders, and academics need to know the human factors influencing the individuals, the development team, and the software project activities. Despite the increasing number of secondary studies about human factors in Software Engineering (SE) and in Agile Software Development (ASD), there is no study synthesizing which human factors influence software development without a specific perspective from SE or human factor thematic. Objective: We aim to summarise human factors and their influence on SE development teams and ASD teams. Method: We executed a tertiary study. We used thematic analysis to examine the resulting data. Results: We found 29 systematic literature reviews and systematic mapping studies addressing the human perspective in SE teams. We identified 101 human factors and 79 influences grouped in 4 categories (Team member, Team, Project, and Organization). Also, we identified 71 human factors and 60 influences on ASD. The most investigated human factors are Communication, Collaboration, Knowledge, and Motivation. Conclusions: The identified human factors and their influences can be considered most significant by software organizations, researchers, and academics in SE practices. Based on our results, practitioners might propose activities that enhance human capital behaviors that influence individual motivation, agile mindset, team climate, software quality, or agile transition in traditional organizations.

The Software Engineering Institute's Softwares Process Maturity Model was developed to provide a basis for assessing an organization's ability to perform software engineering activities. It also provides a guide for improving an organization's software engineering capability. The maturity model was designed on the basis of concepts associated with developing new, large, complex systems. This has led to difficulties in applying the model to organizations involved entirely in software maintenance. The author addresses the tailoring issues encountered in applying the software maturity model to a large maintenance organization at Paramax Space Systems Operation. It is concluded that the issues that arise when the Capability Maturity Model is applied to a software sustaining engineering organization are significant but do not prohibit the use of the model as a guide for software process improvement. Issues mainly arise with the treatment requirements and differences in project management needs. The primary tailoring issues are ones of wording as opposed to applicability to maintenance activities. >

Distributed Software Development (DSD) emerged from the need to achieve geographically distant customers and currently, allows organizations have global customers and other benefits. This scenario has given rise to new Software Engineering challenges resulting from DSD particularities. Several Systematic Reviews were conducted to address these new challenges. The objective of this paper is to categorize systematic reviews conducted in DSD context. We used the systematic review method to identify SLRs (Systematic Literature Reviews) that address DSD aspects. This study is categorized as a tertiary review. Of fourteen SLRs, seven address aspects of managing distributed development. Four SLRs addressed topics of engineering process. The three remaining are related to Requirements, Design and Software Engineering Education in DSD. The topic areas covered by SLRs are limited, where the majority are focused on summarize the current knowledge concerning a research question. Despite the number of SLRs, the amount of empirical studies is relatively small.