Formalising responsibility modelling for automatic analysis

Modelling the structure of social-technical systems as a basis for informing software system design is a difficult compromise. Formal methods struggle to capture the scale and complexity of the heterogeneous organisations that use technical systems. Conversely, informal approaches lack the rigour needed to inform the software design and construction process or enable automated analysis. We revisit the concept of responsibility modelling, which models social technical systems as a collection of actors who discharge their responsibilities, whilst using and producing resources in the process. Responsibility modelling is formalised as a structured approach for socio-technical system requirements specification and modelling, with well-defined semantics and support for automated structure and validity analysis. The effectiveness of the approach is demonstrated by two case studies of software engineering methodologies

Estimating, planning and managing Agile Web development projects under a value-based perspective

Context: The processes of estimating, planning and managing are crucial for software development projects, since the results must be related to several business strategies. The broad expansion of the Internet and the global and interconnected economy make Web development projects be often characterized by expressions like delivering as soon as possible, reducing time to market and adapting to undefined requirements. In this kind of environment, traditional methodologies based on predictive techniques sometimes do not offer very satisfactory results. The rise of Agile methodologies and practices has provided some useful tools that, combined with Web Engineering techniques, can help to establish a framework to estimate, manage and plan Web development projects. Objective: This paper presents a proposal for estimating, planning and managing Web projects, by combining some existing Agile techniques with Web Engineering principles, presenting them as an unified framework which uses the business value to guide the delivery of features. Method: The proposal is analyzed by means of a case study, including a real-life project, in order to obtain relevant conclusions. Results: The results achieved after using the framework in a development project are presented, including interesting results on project planning and estimation, as well as on team productivity throughout the project. Conclusion: It is concluded that the framework can be useful in order to better manage Web-based projects, through a continuous value-based estimation and management process.Ministerio de Economía y Competitividad TIN2013-46928-C3-3-

Reconciling agility and discipline in COTS selection processes

Currently, information systems are mainly built by integrating or customizing commercial off-the-shelf (COTS) components acquired or licensed from the marketplace. The processes necessary to steer a suitable acquisition are different from traditional software development processes. Among them, we are interested in the process of selection of COTS components. COTS selection requires discipline to coordinate the selection team and the set of new activities that are necessary to support a successful selection. The Capability Maturity Model (CMM) contains important guidelines for process improvement, and specifiesPeer ReviewedPostprint (published version

Structured software development with the IPIDDDT method - A lean method for small agile organizations

A software development process is a predetermined sequence of steps to create a piece of software. A software development process is used, so that an implementing organization could gain significant benefits. The benefits for software development companies, that can be attributed to software process improvement efforts, are improved predictability in the development effort and improved quality software products. The implementation, maintenance, and management of a software process as well as the software process improvement efforts are expensive. Especially the implementation phase is expensive with a best case scenario of a slow return on investment. Software processes are rare in very small software development companies because of the cost of implementation and an improbable return on investment. This study presents a new method to enable benefits that are usually related to software process improvement to small companies with a low cost. The study presents reasons for the development of the method, a description of the method, and an implementation process for the method, as well as a theoretical case study of a method implementation. The study's focus is on describing the method. The theoretical use case is used to illustrate the theory of the method and the implementation process of the method. The study ends with a few conclusions on the method and on the method's implementation process. The main conclusion is that the method requires further study as well as implementation experiments to asses the value of the method.Siirretty Doriast

Scrum for product innovation : a longitudinal embedded case study

This article describes the innovation processes used in a partnership between Add Latent Ltd., an asset integrity and maintenance management consulting services provider in the energy sector and University of Salford. The challenge faced by the company is to make their in-house expertise more readily available to a worldwide audience. A longitudinal embedded case study has been used to investigate how installable desktop software applications have been redesigned to create a new set of cloud hosted software services. The innovation team adapted an agile scrum process to include exploratory prototyping and manage the geographical distribution of the team members. A minimum viable product was developed that integrated functional elements of previous software tools into an end-to-end data collection, analysis and visualisation product called AimHi which uses a cloud-hosted web services approach. Field trials were conducted using the software at the Uniper, Isle of Grain power station in Kent, UK. Enhancements were made to the AimHi product which was adopted for use at the Uniper site. The product emerged from a Knwledge Transfer Partnership whci was evaluated on cmplettion by InnovateUK and awarded the highest possible “outstanding” grade. The article illustrates how the scrum software development method was tailored for a product innovation context. Extended periods of evaluation and reflection, prototyping and requirement refinement were combined with periods of incremental feature development using sprints. The AimHi product emerged from a technology transfer and innovation project that has successfully reconciled conflicting demands from customers, universities, partner companies and project staff members

Artefacts and agile method tailoring in large-scale offshore software development programmes

Context: Large-scale offshore software development programmes are complex, with challenging deadlines and a high risk of failure. Agile methods are being adopted, despite the challenges of coordinating multiple development teams. Agile processes are tailored to support team coordination. Artefacts are tangible products of the software development process, intended to ensure consistency in the approach of teams on the same development programme. Objective: This study aims to increase understanding of how development processes are tailored to meet the needs of large-scale offshore software development programmes, by focusing on artefact inventories used in the development process. Method: A grounded theory approach using 46 practitioner interviews, supplemented with documentary sources and observations, in nine international companies was adopted. The grounded theory concepts of open coding, memoing, constant comparison and saturation were used in data analysis. Results: The study has identified 25 artefacts, organised into five categories: feature, sprint, release, product and corporate governance. It was discovered that conventional agile artefacts are enriched with artefacts associated with plan-based methods in order to provide governance. The empirical evidence collected in the study has been used to identify a primary owner of each artefact and map each artefact to specific activities within each of the agile roles. Conclusion: The development programmes in this study create agile and plan-based artefacts to improve compliance with enterprise quality standards and technology strategies, whilst also mitigating risk of failure. Management of these additional artefacts is currently improvised because agile development processes lack corresponding ceremonies

Management of quality requirements in agile and rapid software development: A systematic mapping study

Context: Quality requirements (QRs) describe the desired quality of software, and they play an important role in the success of software projects. In agile software development (ASD), QRs are often ill-defined and not well addressed due to the focus on quickly delivering functionality. Rapid software development (RSD) approaches (e.g., continuous delivery and continuous deployment), which shorten delivery times, are more prone to neglect QRs. Despite the significance of QRs in both ASD and RSD, there is limited synthesized knowledge on their management in those approaches. Objective: This study aims to synthesize state-of-the-art knowledge about QR management in ASD and RSD, focusing on three aspects: bibliometric, strategies, and challenges. Research method: Using a systematic mapping study with a snowballing search strategy, we identified and structured the literature on QR management in ASD and RSD. Results: We found 156 primary studies: 106 are empirical studies, 16 are experience reports, and 34 are theoretical studies. Security and performance were the most commonly reported QR types. We identified various QR management strategies: 74 practices, 43 methods, 13 models, 12 frameworks, 11 advices, 10 tools, and 7 guidelines. Additionally, we identified 18 categories and 4 non-recurring challenges of managing QRs. The limited ability of ASD to handle QRs, time constraints due to short iteration cycles, limitations regarding the testing of QRs and neglect of QRs were the top categories of challenges. Conclusion: Management of QRs is significant in ASD and is becoming important in RSD. This study identified research gaps, such as the need for more tools and guidelines, lightweight QR management strategies that fit short iteration cycles, investigations of the link between QRs challenges and technical debt, and extension of empirical validation of existing strategies to a wider context. It also synthesizes QR management strategies and challenges, which may be useful for practitioners.Peer ReviewedPostprint (author's final draft

What Makes Agile Test Artifacts Useful? An Activity-Based Quality Model from a Practitioners' Perspective

Background: The artifacts used in Agile software testing and the reasons why these artifacts are used are fairly well-understood. However, empirical research on how Agile test artifacts are eventually designed in practice and which quality factors make them useful for software testing remains sparse. Aims: Our objective is two-fold. First, we identify current challenges in using test artifacts to understand why certain quality factors are considered good or bad. Second, we build an Activity-Based Artifact Quality Model that describes what Agile test artifacts should look like. Method: We conduct an industrial survey with 18 practitioners from 12 companies operating in seven different domains. Results: Our analysis reveals nine challenges and 16 factors describing the quality of six test artifacts from the perspective of Agile testers. Interestingly, we observed mostly challenges regarding language and traceability, which are well-known to occur in non-Agile projects. Conclusions: Although Agile software testing is becoming the norm, we still have little confidence about general do's and don'ts going beyond conventional wisdom. This study is the first to distill a list of quality factors deemed important to what can be considered as useful test artifacts