Changing situational contexts present a constant challenge to software developers.

A software process can take many forms and its optimality demands that it should be harmonised with the needs of the given software development situational context. This theoretical proposition is reasonably clear. However, the finer details of the interaction between the software process and the factors of the situational context are much less obvious. In previously published research, the authors have elaborated a reference framework that identifies the factors of a situational context that affect the software process [1]. In this paper, we report on the application of our reference framework in an examination of the changing nature of software development situational contexts. Our corresponding study of fifteen software development companies indicates that certain factors appear more subject to change than others. This finding is a potentially important insight that can help us with the recurring challenge of adapting the software process to changing circumstances

A Conceptual Model of Client-driven Agile Requirements Prioritization: Results of a Case Study

ABSTRACT Requirements (re)prioritization is an essential mechanism of agile development approaches to maximize the value for the clients and to accommodate changing requirements. Yet, in the agile Requirements Engineering (RE) literature, very little is known about how agile (re)prioritization happens in practice. Conceptual models about this process are missing, which, in turn, makes it difficult for both practitioners and researchers to reason about requirements decision-making at inter-iteration time. We did a multiple case study on agile requirements prioritization methods to yield a conceptual model for understanding the inter-iteration prioritization process. The model is derived by using interview data from practitioners in 8 development organizations. Such a model makes explicit the concepts that are used tacitly in the agile requirements prioritization practice and can be used for structuring future empirical investigations about this topic, and for analyzing, supporting, and improving the process in real-life projects

The changing role of the software engineer

In this paper we will discuss the changing role of a software engineer. We will examine this from four major standpoints, the software development life cycle, the influence of open source software, testing and deployment and the emergence of new technologies. We will first analyze what the role of a software engineer was in the past. We will examine limitations associated with software development life cycle models, and software failures that catalyzed increased importance for quality assurance. We then outline the current role of a software engineer. We discuss the impact of agile software development and automation on the software development cycle, the influence of open source software and how new technologies such as Function-as-a-Service and machine learning may impacted the role. Based on our research, we analyze why the software engineer role has changed and postulate prospective changes to the role of software engineer, and in particular how new responsibilities may affect the day to day work of future software engineers. We ultimately find that the role of a “software engineer” is nowadays widely varied and very broad, and it only generally indicates the type of work that the software engineer may undertake

Managing Evolutionary Method Engineering by Method Rationale

This paper explores how to integrate formal meta-models with an informal method rationale to support evolutionary (continuous) method development. While the former provides an exact and computer-executable specification of a method, the latter enables concurrent learning, expansion, and refinement of method use (instances of meta-models) and meta-models (evolution of method specifications). We explain the need for method rationale by observing the criticality of evolving method knowledge in helping software organizations to learn, as well as by the recurrent failure to introduce rigid and stable methods. Like a design rationale, a method rationale establishes a systematic and organized trace of method evolution. Method rationale is located at two levels of type-instance hierarchy depending on its type of use and the scope of the changes traced. A method construction rationale garners a history of method knowledge evolution as part of the method engineering process, which designs and adapts the method to a given organizational context. A method use rationale maintains knowledge of concrete use contexts and their history and justifies further method deployment in alternative contexts, reveals limitations in its past use, and enables sharing of method use experience. The paper suggests how a method rationale helps share knowledge of methods between method users and engineers, explores how method engineers coordinate the evolution of the existing method base through it, and suggests ways to improve learning through method rationale

Refactoring software development process terminology through the use of ontology

In work that is ongoing, the authors are examining the extent of software development process terminology drift. Initial findings suggest there is a degree of term confusion, with the mapping of concepts to terms lacking precision in some instances. Ontologies are concerned with identifying the concepts of relevance to a field of endeavour and mapping those concepts to terms such that term confusion is reduced. In this paper, we discuss how ontologies are developed. We also identify various sources of software process terminology. Our work to date indicates that the systematic development of a software development process ontology would be of benefit to the entire software development community. The development of such an ontology would in effect represent a systematic refactoring of the terminology and concepts produced over four decades of software process innovation

Blinded by Simplicity: Locating the Social Dimension in Software Development Process Literature

The software development process is a complex human, intellectual and labor-intensive activity and human related factors have shown to be the most significant contributors to software system failures. Lacking the ability to identify or quantify these factors, software practitioners will not learn from the failures caused by them. Although, social factors give rise to high failure rates in software development projects they tend to be ignored. Business continues as usual. The inability for software engineers to attain a holistic and inclusive approach will leave the social dimension out and undermine the realization of a fully sustainable software development process.This paper builds on the master’s thesis with the same title completed in December 2019 at Stockholm University. The thesis demonstrates how research literature on software development processes addresses (or not) the social dimension of sustainability from a holistic point of view. The results indicate that the practice of dealing holistically with complexity including the social dimension is still underdeveloped. Further research is suggested regarding the development of adequate supporting tools, social skills, and managerial attitudes and behaviors

Refactoring software development process terminology through the use of ontology

peer-reviewedIn work that is ongoing, the authors are examining the extent of software development process terminology drift. Initial findings suggest there is a degree of term confusion, with the mapping of concepts to terms lacking precision in some instances. Ontologies are concerned with identifying the concepts of relevance to a field of endeavour and mapping those concepts to terms such that term confusion is reduced. In this paper, we discuss how ontologies are developed. We also identify various sources of software process terminology. Our work to date indicates that the systematic development of a software development process ontology would be of benefit to the entire software development community. The development of such an ontology would in effect represent a systematic refactoring of the terminology and concepts produced over four decades of software process innovation

PRIMA — Privacy research through the perspective of a multidisciplinary mash up

Based on a summary description of privacy protection research within three fields of inquiry, viz. social sciences, legal science, and computer and systems sciences, we discuss multidisciplinary approaches with regard to the difficulties and the risks that they entail as well as their possible advantages. The latter include the identification of relevant perspectives of privacy, increased expressiveness in the formulation of research goals, opportunities for improved research methods, and a boost in the utility of invested research efforts

Models for Learning (Mod4L) Final Report: Representing Learning Designs

The Mod4L Models of Practice project is part of the JISC-funded Design for Learning Programme. It ran from 1 May – 31 December 2006. The philosophy underlying the project was that a general split is evident in the e-learning community between development of e-learning tools, services and standards, and research into how teachers can use these most effectively, and is impeding uptake of new tools and methods by teachers. To help overcome this barrier and bridge the gap, a need is felt for practitioner-focused resources which describe a range of learning designs and offer guidance on how these may be chosen and applied, how they can support effective practice in design for learning, and how they can support the development of effective tools, standards and systems with a learning design capability (see, for example, Griffiths and Blat 2005, JISC 2006). Practice models, it was suggested, were such a resource. The aim of the project was to: develop a range of practice models that could be used by practitioners in real life contexts and have a high impact on improving teaching and learning practice. We worked with two definitions of practice models. Practice models are: 1. generic approaches to the structuring and orchestration of learning activities. They express elements of pedagogic principle and allow practitioners to make informed choices (JISC 2006) However, however effective a learning design may be, it can only be shared with others through a representation. The issue of representation of learning designs is, then, central to the concept of sharing and reuse at the heart of JISC’s Design for Learning programme. Thus practice models should be both representations of effective practice, and effective representations of practice. Hence we arrived at the project working definition of practice models as: 2. Common, but decontextualised, learning designs that are represented in a way that is usable by practitioners (teachers, managers, etc).(Mod4L working definition, Falconer & Littlejohn 2006). A learning design is defined as the outcome of the process of designing, planning and orchestrating learning activities as part of a learning session or programme (JISC 2006). Practice models have many potential uses: they describe a range of learning designs that are found to be effective, and offer guidance on their use; they support sharing, reuse and adaptation of learning designs by teachers, and also the development of tools, standards and systems for planning, editing and running the designs. The project took a practitioner-centred approach, working in close collaboration with a focus group of 12 teachers recruited across a range of disciplines and from both FE and HE. Focus group members are listed in Appendix 1. Information was gathered from the focus group through two face to face workshops, and through their contributions to discussions on the project wiki. This was supplemented by an activity at a JISC pedagogy experts meeting in October 2006, and a part workshop at ALT-C in September 2006. The project interim report of August 2006 contained the outcomes of the first workshop (Falconer and Littlejohn, 2006). The current report refines the discussion of issues of representing learning designs for sharing and reuse evidenced in the interim report and highlights problems with the concept of practice models (section 2), characterises the requirements teachers have of effective representations (section 3), evaluates a number of types of representation against these requirements (section 4), explores the more technically focused role of sequencing representations and controlled vocabularies (sections 5 & 6), documents some generic learning designs (section 8.2) and suggests ways forward for bridging the gap between teachers and developers (section 2.6). All quotations are taken from the Mod4L wiki unless otherwise stated