Revealing the Vicious Circle of Disengaged User Acceptance: A SaaS Provider's Perspective

User acceptance tests (UAT) are an integral part of many different software engineering methodologies. In this paper, we examine the influence of UATs on the relationship between users and Software-as-a-Service (SaaS) applications, which are continuously delivered rather than rolled out during a one-off signoff process. Based on an exploratory qualitative field study at a multinational SaaS provider in Denmark, we show that UATs often address the wrong problem in that positive user acceptance may actually indicate a negative user experience. Hence, SaaS providers should be careful not to rest on what we term disengaged user acceptance. Instead, we outline an approach that purposefully queries users for ambivalent emotions that evoke constructive criticism, in order to facilitate a discourse that favors the continuous innovation of a SaaS system. We discuss theoretical and practical implications of our approach for the study of user engagement in testing SaaS applications

An Empirical Study of a Software Maintenance Process

This paper describes how a process support tool is used to collect metrics about a major upgrade to our own electronic retail system. An incremental prototyping lifecycle is adopted in which each increment is categorised by an effort type and a project component. Effort types are Acquire, Build, Comprehend and Design and span all phases of development. Project components include data models and process models expressed in an OO modelling language and process algebra respectively as well as C++ classes and function templates and build components including source files and data files. This categorisation is independent of incremental prototyping and equally applicable to other software lifecycles. The process support tool (PWI) is responsible for ensuring the consistency between the models and the C++ source. It also supports the interaction between multiple developers and multiple metric-collectors. The first two releases of the retailing software are available for ftp from oracle.ecs.soton.ac.uk in directory pub/peter. Readers are invited to use the software and apply their own metrics as appropriate. We would be interested to correspond with anyone who does so

The Co-Evolution of Test Maintenance and Code Maintenance through the lens of Fine-Grained Semantic Changes

Automatic testing is a widely adopted technique for improving software quality. Software developers add, remove and update test methods and test classes as part of the software development process as well as during the evolution phase, following the initial release. In this work we conduct a large scale study of 61 popular open source projects and report the relationships we have established between test maintenance, production code maintenance, and semantic changes (e.g, statement added, method removed, etc.). performed in developers' commits. We build predictive models, and show that the number of tests in a software project can be well predicted by employing code maintenance profiles (i.e., how many commits were performed in each of the maintenance activities: corrective, perfective, adaptive). Our findings also reveal that more often than not, developers perform code fixes without performing complementary test maintenance in the same commit (e.g., update an existing test or add a new one). When developers do perform test maintenance, it is likely to be affected by the semantic changes they perform as part of their commit. Our work is based on studying 61 popular open source projects, comprised of over 240,000 commits consisting of over 16,000,000 semantic change type instances, performed by over 4,000 software engineers.Comment: postprint, ICSME 201

An Exploration into Technological Capabilities among early stage Indian product based Telecom start-ups

New technology based start-ups play a very important role in developing the economy of a country. In India, telecom sector has seen unprecedented growth over the last decade and this has led to emergence of several telecom related start-ups. However, product based B2B start-ups are rare and existing ones have to undergo several challenges in commercializing. Surprisingly not much research work has been undertaken in identifying capabilities among early stage start-ups although the early phase represents a very crucial phase for product based firms and has been known to determine the success or failure for start-ups. Present study explores the technological capabilities that enable commercialization among such early stage start-ups by adopting a multiple case (four independent cases) based inductive methodology with Indian telecom start-ups as the context. We have identified architectural design, algorithmic implementation and product adaptation as components of technological capability of such start-ups. We further drill in to each of the sub-components of the technological capabilities to unearth their antecedents and peculiarities in telecom product company context. As a result we also present a classification scheme for studying the product architecture in the telecom context. We analyze and point out differences in technological capability among telecom start-ups vis-�-vis established firms in the sector .

Video Game Development in a Rush: A Survey of the Global Game Jam Participants

Video game development is a complex endeavor, often involving complex software, large organizations, and aggressive release deadlines. Several studies have reported that periods of "crunch time" are prevalent in the video game industry, but there are few studies on the effects of time pressure. We conducted a survey with participants of the Global Game Jam (GGJ), a 48-hour hackathon. Based on 198 responses, the results suggest that: (1) iterative brainstorming is the most popular method for conceptualizing initial requirements; (2) continuous integration, minimum viable product, scope management, version control, and stand-up meetings are frequently applied development practices; (3) regular communication, internal playtesting, and dynamic and proactive planning are the most common quality assurance activities; and (4) familiarity with agile development has a weak correlation with perception of success in GGJ. We conclude that GGJ teams rely on ad hoc approaches to development and face-to-face communication, and recommend some complementary practices with limited overhead. Furthermore, as our findings are similar to recommendations for software startups, we posit that game jams and the startup scene share contextual similarities. Finally, we discuss the drawbacks of systemic "crunch time" and argue that game jam organizers are in a good position to problematize the phenomenon.Comment: Accepted for publication in IEEE Transactions on Game

Proactive Empirical Assessment of New Language Feature Adoption via Automated Refactoring: The Case of Java 8 Default Methods

Programming languages and platforms improve over time, sometimes resulting in new language features that offer many benefits. However, despite these benefits, developers may not always be willing to adopt them in their projects for various reasons. In this paper, we describe an empirical study where we assess the adoption of a particular new language feature. Studying how developers use (or do not use) new language features is important in programming language research and engineering because it gives designers insight into the usability of the language to create meaning programs in that language. This knowledge, in turn, can drive future innovations in the area. Here, we explore Java 8 default methods, which allow interfaces to contain (instance) method implementations. Default methods can ease interface evolution, make certain ubiquitous design patterns redundant, and improve both modularity and maintainability. A focus of this work is to discover, through a scientific approach and a novel technique, situations where developers found these constructs useful and where they did not, and the reasons for each. Although several studies center around assessing new language features, to the best of our knowledge, this kind of construct has not been previously considered. Despite their benefits, we found that developers did not adopt default methods in all situations. Our study consisted of submitting pull requests introducing the language feature to 19 real-world, open source Java projects without altering original program semantics. This novel assessment technique is proactive in that the adoption was driven by an automatic refactoring approach rather than waiting for developers to discover and integrate the feature themselves. In this way, we set forth best practices and patterns of using the language feature effectively earlier rather than later and are able to possibly guide (near) future language evolution. We foresee this technique to be useful in assessing other new language features, design patterns, and other programming idioms