Integrating Shadows in Model Driven Engineering for Agile Software Development

Structural operational semantics is a simple, yet powerful mathematical theory for describing the behaviour of programs in an implementation-independent manner. This book provides a self-contained introduction to structural operational semantics, featuring semantic definitions using big-step and small-step semantics of many standard programming language constructs, including control structures, structured declarations and objects, parameter mechanisms and procedural abstraction, concurrency, nondeterminism and the features of functional programming languages. Along the way, the text introduces and applies the relevant proof techniques, including forms of induction and notions of semantic equivalence (including bisimilarity). Thoroughly class-tested, this book has evolved from lecture notes used by the author over a 10-year period at Aalborg University to teach undergraduate and graduate students. The result is a thorough introduction that makes the subject clear to students and computing professionals without sacrificing its rigour. No experience with any specific programming language is required.

Software development is an iterative process by which software is created using a specific programming language through the combination of interrelated logic and functionality. Several factors cause software to change. The methods being used to manage projects in some businesses is very unstructured and cluttered. This paper reports on a systematic review of literature of 38 papers that consider how redundancy can be reduced in software development by fixing project management redundancies. The researcher recommends that agile methodologies can possibly solve the redundancy issue, as the plausible solutions discussed in the paper is applied within the agile methodology.

Agile practices have recently gained popularity among large number of companies as a mechanism for reducing cost and increasing ability to handle change in dynamic market conditions. Based on the principles of the Agile manifesto [1, 2], researchers and practitioners have proposed several software development approaches such as Extreme Programming, Scrum and Feature-Driven Development. These and other agile approaches have had significant impact on industrial software development practices. However, there is also a significant concern and perplexity about the role and importance of the issues related to a system’s software architecture, which is considered one of the most important initial design artefacts. It is argued that software architecture is an effective tool to cut development cost and time and to increase the quality of a system. Many practitioners of Agile approaches appear to view software architecture in the context of the plan-driven development paradigm [3]. For them, upfront design and evaluation of software architecture requires too much work, which may have very little value to the customers of a system. Hence, they perceive architectural work as part of high ceremony processes, which usually require large amount of documentation. We maintain that these two seemingly opposing views to software engineering can be integrated but it requires that experts from both fields work together to overcome evident challenges in bridging these two paradigms together. Indeed, software architecture researchers and practitioners appear to believe that sound architectural practices cannot be followed using Agile approaches. However, these two extreme views of Agile and architecture appear to neglect that many agile experts emphasises the importance of paying attention to good design and architecture early in the development process [4, 5]. Recently, there is growing recognition of the importance of paying more attention to architectural aspects in agile approaches [3, 6, 7]. We argue that there is a vital need for devising a research agenda for identifying and dealing with architecture-centric challenges in agile software development. Such research agenda should make it possible to guide the future research on integrating architecture-centric methods in agile approaches and give advice to the software industry on dealing with architecture related challenges. Some of the questions to stimulate discussion in the workshop are: What is the role of software architecture in Agile software development? What are the key architecture-centric challenges and potential solutions in Agile software development projects? What is the strength of the evidence that attention to architectural issues can be counterproductive in Agile development or vice versa? What are the prerequisites for integrating Architecture-Centric methods in agile development and potential implications of such integration?

Organizations of all sorts adopt agile software development, but they rarely implement it “by the book.” Instead, agile practices evolve after initial adoption and often drift in different directions as organizations translate agile into their institutional environments. We studied the implementation of agile development in four organizations from much different institutional contexts: a startup technology company, a consulting firm, a government organization, and an industrial manufacturer. We found two core dimensions of their institutional contexts that shape agile translation: dynamism and pluralism. Dynamism refers to how fast requirements and environments change, and pluralism refers to how many diverse stakeholders are involved. These two dimensions influence the direction of agile translation. We show that agile practices evolve through a “ratcheting” process, whereby a sequence of incremental, interdependent changes gradually move teams closer to or further away from canonical agile practices. High pluralism in the institutional context, for example, tends to increase documentation, whereas low dynamism appears to slow iteration cycles. Agile software development is no longer limited to startups or software teams; it is adapted by all sorts of organizations as a way to flexibly innovate. Understanding why agile evolves differently across contexts helps managers move beyond one-size-fits-all prescriptions and set realistic expectations for agile development in their organizations.

We describe ongoing work on building an environment to support reasoning in proof assistants that represent formal systems using higher-order abstract syntax (HOAS). We use a simple and general specification language whose syntax supports HOAS. Using this language, we can encode the syntax and inference rules of a variety of formal systems, such as programming languages and logics. We describe our tool, implemented in OCaml, which parses this syntax, and translates it to a Coq library that includes definitions and hints for aiding automated proof in the Hybrid system. Hybrid itself is implemented in Coq, and designed specifically to reason about such formal systems. Given an input specification, the library that is automatically generated by our tool imports the general Hybrid library and adds definitions and hints for aiding automated proof in Hybrid about the specific programming language or logic defined in the specification. This work is part of a larger project to compare reasoning in systems supporting HOAS. Our current work focuses on Hybrid, Abella, Twelf, and Beluga, and the specification language is designed to be general enough to allow the automatic generation of libraries for all of these systems from a single specification.

Today, the most vital step is software testing, especially in product quality. Agile software development is exceedingly difficult and has contentious issues in literature and business. Since most Agile techniques place more emphasis on development than software testing activities, different people have varying opinions about how software testing fits into these methodologies. Agile places a high emphasis on frequent deliveries and tight client connections. However, software testing is complex because agile does not incorporate many destructive testing techniques typically required for a product of higher-quality. The study reveals industry-wide Agile testing procedures and the main problems that arise when Agile development is used. Additionally covered are the differences between manual and automated testing, best automation practices, and ways to lead different testing teams in an agile testing environment. This study covers every facet of the Agile software testing process. Agile development has shown that testing is not a distinct stage but rather a crucial component of software development along with the coding. The agile team employs an overall strategy to produce software products of the highest quality. As part of an agile team, testers collect customer samples of the desired behaviour and collaborate with the developer's team to help the coders translate these examples into executable specifications. Coding and testing are done iteratively and incrementally, developing every item until it is valuable enough to release in production. It addresses several testing modalities. The classification provided by its quadrants aids teams in determining and organizing the necessary tests. To increase quality assurance, this article will examine various and improved Agile Testing Processes and methodologies. Additionally, the topic of Agile development's software testing method is covered. Agile development processes can be improved and more advantageous by incorporating testing procedures.

Various methods are used to describe communication protocols. The search for suitable description methods for communication protocols in the 1980s yielded a broad range of approaches out of which some fundamental methods have crystallized. These methods constitute the basis of the semantic models of the various formal description techniques. Therefore we first consider the most important description methods in this chapter before we turn to the formal description techniques. From these, finite state machines, Petri nets, process calculi, and temporal logics have crystallized as the most important and most common ones. Apart from these methods, other approaches were also investigated, such as the use of grammars, data flow languages, and functional languages. They did not receive wider attention because they were not applied to real-life protocols. The use of high-level programming languages was considered likewise. Programming languages support the algorithmic description of protocol procedures as well as the generation of prototypes, but they usually do not possess a formally defined semantics. In addition, programming languages are primarily implementation languages and not specification languages. They often yield descriptions which are close to an implementation. For that reason, high-level programming languages are not used for protocol description. Many formal description techniques, however, use programming language features.

Different semantic models for a nondeterministic programming language are defined, analysed, and compared in the formal framework of algebraic specifications of programming languages by abstract types. Four abstract types are given representing choice ("erratic") nondeterminism, backtrack ("demonic") nondeterminism, unbounded ("angelic") nondeterminism and loose nondeterminism. The classes of algebras of these types represent classes of semantic models. A comparison of these classes of semantic models shows the connections and differences between the four different concepts of nondeterminism as found in programming languages.

Bridging knowledge boundaries among project team members is essential to prevent delays or complete failure of software development projects. Prior researchers have reported that software prototypes can be used to help bridge knowledge boundaries between team members in traditional software development settings, yet their use in an agile development setting remains unexplored. Agile development centers the interactions between team members on emerging representations of the prototype whose properties are prone to change over time. Therefore, we conducted an in‐depth study of an agile development project to enhance our understanding on how software prototypes are used as boundary objects in a distributed team setting. Our analyses of team member interactions during 46 virtual meetings that took place over a period of 6 months revealed four different prototype use practices (exemplifying, contrasting, relating, framing) that were effective in bridging syntactic, semantic, or pragmatic knowledge boundaries. We also provide empirically grounded evidence of how variations in object properties can afford different use practices, how the use practices take advantage of these properties, and how object properties are reshaped through these use practices as different types of knowledge boundaries are bridged. These findings bear important implications for research on prototypes as boundary objects in software development in particular and boundary object use in general.

Since the late 1990s, agile or lightweight software development methodologies have experienced a meteoric rise of interest among systems developers who consider traditional systems development methodologies (such as Structured Systems Development, Information Engineering, and Rational Unified Process) too inflexible for building systems having unpredictable and changing requirements. Agile methodologies try to adapt to rapid requirement changes by having short, iterative development cycles and by encouraging frequent, open communication with customers. However, agile methodologies are still in the process of devising systematic approaches on how to be adaptive to unpredictable and changing requirements and how to incorporate customers into the systems development process. In this study, we show how an ethnographic research process called Strip Resolution can be applied as a systematic complement to projects applying agile development principles. We illustrate, in detail, how the Strip Resolution Process (SRP) enabled us, in the role of systems developers, to adapt to changing and unpredictable user requirements and to incorporate customers into the systems development process.

Modern data collection and analysis pipelines often involve a sophisticated mix of applications written in general purpose and specialized programming languages. Many formats commonly used to import and export data between different programs or systems, such as CSV or JSON, are verbose, inefficient, not type-safe, or tied to a specific programming language. Protocol Buffers are a popular method of serializing structured data between applications - while remaining independent of programming languages or operating systems. They offer a unique combination of features, performance, and maturity that seems particularly well suited for data-driven applications and numerical computing. The RProtoBuf package provides a complete interface to Protocol Buffers from the R environment for statistical computing. This paper outlines the general class of data serialization requirements for statistical computing, describes the implementation of the RProtoBuf package, and illustrates its use with example applications in large-scale data collection pipelines and web services.

Modern science commonly uses computer modelling. Thousands of scientific model are daily transformed to computers programs and tested. The transformation must overcome the gap between abstract human formal notation and low level semantics of contemporary programming languages. The simultaneous knowledge of specific scientific models and programming languages is an unpleasant necessity for a significant proportion of scientists and practitioners (engineers, economist, etc.). But a solution exists - accommodation of programming languages to mental models of their users. The article discuss one partial solution - implementation of domain specific languages in the heart of existing universal languages by mechanisms of metaprogramming. This mechanism overcomes limitations of classical programming languages and complexity of creation new languages from scratch. However, the support of metaprogramming in contemporary languages is limited to isolated and peripheral constructs in very few languages. These constructs are demonstrated by simplified but real examples (metaobject system of Python, monads in F# and macro-based metaprogramming of Boo language) together with discussion of their advantages and disadvantages. The discussion of examples is aimed to finding requirements for new languages and their implementation in a original (parent) language.

This is the 23rd Self-Assessment Procedure. 1 The purpose of this procedure is to let its readers test their knowledge of some of the more important features of significant programming languages. The features of imperative languages like Fortran, Algol 60, PL/I, Pascal, Modula-2, C, and Ada considered are data types, data structures, control structures, program units, scope of names, and parameter passing. Some of the corresponding features of functional languages like Lisp, logic programming languages like Prolog, and ohject-oriented programming languages like C++ and Smalltalk, are reviewed. Finally brief consideration is given to syntax and semantics, chiefly by reference to the Backus-Naur form, BNF. The features of programming languages affect all aspects of programming, including the ease of writing and maintaining programs, the reliahility of software, and the efficiency and portability of programs. Knowledge of programming language concepts and constructs is of importance to software developers, programmers, and designers of programming languages and compilers. The topic of this procedure should be of interest to any computer science student or practitioner who wishes to test his or her knowledge and learn more about one of the most important and broad areas in the computer field. The language used most often in the questions is Pascal, with Ada, Lisp, and Prolog also featured prominently. A glossary is included which defines some of the terms used in the procedure. The questions are either multiple-choice or short answer. Some of the multiple-choice questions allow for more than one correct answer.

Effort estimation is an important practice in agile software development. The agile community believes that developers’ estimates get more accurate over time due to the cumulative effect of learning from short and frequent feedback. However, there is no empirical evidence of an improvement in estimation accuracy over time, nor have prior studies examined effort estimation in different development activities, which are associated with substantial costs. This study fills the knowledge gap in the field of software estimation in agile software development by investigating estimations across time and different development activities based on data collected from a large agile project. This study investigated effort estimation in various development activities, including feature development, bug fixing, and refactoring in agile software development. The results indicate that estimation of agile development does not improve over time, as claimed in the literature. Our data also indicate that no difference exists in the magnitude of estimation errors between feature tasks and bug-fixing/refactoring tasks, while bug-fixing and refactoring tasks are overestimated more frequently than feature tasks. This study also contributes to our knowledge about overestimation and underestimation patterns in agile software development.

Software quality assurance is concerned with the efficient and effective development of large, reliable, and high-quality software systems. In agile software development and maintenance, refactoring is an important phase for the continuous improvement of a software system by removing quality defects like code smells. As time is a crucial factor in agile development, not all quality defects can be removed in one refactoring phase (especially in one iteration). Documentation of quality defects that are found during automated or manual discovery activities (e.g., pair programming) is necessary to avoid wasting time by rediscovering them in later phases. Unfortunately, the documentation and handling of existing quality defects and refactoring activities is a common problem in software maintenance. To recall the rationales why changes were carried out, information has to be extracted from either proprietary documentations or software versioning systems. In this chapter, we describe a process for the recurring and sustainable discovery, handling, and treatment of quality defects in software systems. An annotation language is presented that is used to store information about quality defects found in source code and that represents the defect and treatment history of a part of a software system. The process and annotation language can not only be used to support quality defect discovery processes, but is also applicable in testing and inspection processes.