29,946 research outputs found

    Detecting Coordination Problems in Collaborative Software Development Environments

    Get PDF
    Software development is rarely an individual effort and generally involves teams of developers collaborating to generate good reliable code. Among the software code there exist technical dependencies that arise from software components using services from other components. The different ways of assigning the design, development, and testing of these software modules to people can cause various coordination problems among them. We claim\ud that the collaboration of the developers, designers and testers must be related to and governed by the technical task structure. These collaboration practices are handled in what we call Socio-Technical Patterns.\ud The TESNA project (Technical Social Network Analysis) we report on in this paper addresses this issue. We propose a method and a tool that a project manager can use in order to detect the socio-technical coordination problems. We test the method and tool in a case study of a small and innovative software product company

    Applying tropos to socio-technical system design and runtime configuration

    Get PDF
    Recent trends in Software Engineering have introduced the importance of reconsidering the traditional idea of software design as a socio-tecnical problem, where human agents are integral part of the system along with hardware and software components. Design and runtime support for Socio-Technical Systems (STSs) requires appropriate modeling techniques and non-traditional infrastructures. Agent-oriented software methodologies are natural solutions to the development of STSs, both humans and technical components are conceptualized and analyzed as part of the same system. In this paper, we illustrate a number of Tropos features that we believe fundamental to support the development and runtime reconïŹguration of STSs. Particularly, we focus on two critical design issues: risk analysis and location variability. We show how they are integrated and used into a planning-based approach to support the designer in evaluating and choosing the best design alternative. Finally, we present a generic framework to develop self-reconïŹgurable STSs

    A framework for the definition of metrics for actor-dependency models

    Get PDF
    Actor-dependency models are a formalism aimed at providing intentional descriptions of processes as a network of dependency relationships among actors. This kind of models is currently widely used in the early phase of requirements engineering as well as in other contexts such as organizational analysis and business process reengineering. In this paper, we are interested in the definition of a framework for the formulation of metrics over these models. These metrics are used to analyse the models with respect to some properties that are interesting for the system being modelled, such as security, efficiency or accuracy. The metrics are defined in terms of the actors and dependencies of the model. We distinguish three different kinds of metrics that are formally defined, and then we apply the framework at two different layers of a meeting scheduler system.Postprint (published version

    Responsibility modelling for civil emergency planning

    Get PDF
    This paper presents a new approach to analysing and understanding civil emergency planning based on the notion of responsibility modelling combined with HAZOPS-style analysis of information requirements. Our goal is to represent complex contingency plans so that they can be more readily understood, so that inconsistencies can be highlighted and vulnerabilities discovered. In this paper, we outline the framework for contingency planning in the United Kingdom and introduce the notion of responsibility models as a means of representing the key features of contingency plans. Using a case study of a flooding emergency, we illustrate our approach to responsibility modelling and suggest how it adds value to current textual contingency plans

    The i* framework for goal-oriented modeling

    Get PDF
    The final publication is available at Springer via http://dx.doi.org/10.1007/978-3-319-39417-6i* is a widespread framework in the software engineering field that supports goal-oriented modeling of socio-technical systems and organizations. At its heart lies a language offering concepts such as actor, dependency, goal and decomposition. i* models resemble a network of interconnected, autonomous, collaborative and dependable strategic actors. Around this language, several analysis techniques have emerged, e.g. goal satisfaction analysis and metrics computation. In this work, we present a consolidated version of the i* language based on the most adopted versions of the language. We define the main constructs of the language and we articulate them in the form of a metamodel. Then, we implement this version and a concrete technique, goal satisfaction analys is based on goal propagation, using ADOxx. Throughout the chapter, we used an example based on open source software adoption to illustrate the concepts and test the implementation.Peer ReviewedPostprint (author's final draft

    Collaborative design : managing task interdependencies and multiple perspectives

    Get PDF
    This paper focuses on two characteristics of collaborative design with respect to cooperative work: the importance of work interdependencies linked to the nature of design problems; and the fundamental function of design cooperative work arrangement which is the confrontation and combination of perspectives. These two intrinsic characteristics of the design work stress specific cooperative processes: coordination processes in order to manage task interdependencies, establishment of common ground and negotiation mechanisms in order to manage the integration of multiple perspectives in design

    The Mirroring Hypothesis: Theory, Evidence and Exceptions

    Get PDF
    The mirroring hypothesis predicts that the organizational patterns of a development project (e.g. communication links, geographic collocation, team and firm co-membership) will correspond to the technical patterns of dependency in the system under development. Scholars in a range of disciplines have argued that mirroring is either necessary or a highly desirable feature of development projects, but evidence pertaining to the hypothesis is widely scattered across fields, research sites, and methodologies. In this paper, we formally define the mirroring hypothesis and review 102 empirical studies spanning three levels of organization: within a single firm, across firms, and in open community-based development projects. The hypothesis was supported in 69% of the cases. Support for the hypothesis was strongest in the within-firm sample, less strong in the across-firm sample, and relatively weak in the open collaborative sample. Based on a detailed analysis of the cases in which the mirroring hypothesis was not supported, we introduce the concept of actionable transparency as a means of achieving coordination without mirroring. We present examples from practice and describe the more complex organizational patterns that emerge when actionable transparency allows designers to 'break the mirror.'Modularity, innovation, product and process development, organization design, design structure, organizational structure, organizational ties

    The institutional character of computerized information systems

    Get PDF
    We examine how important social and technical choices become part of the history of a computer-based information system (CB/SJ and embedded in the social structure which supports its development and use. These elements of a CBIS can be organized in specific ways to enhance its usability and performance. Paradoxically, they can also constrain future implementations and post-implementations.We argue that CBIS developed from complex, interdependent social and technical choices should be conceptualized in terms of their institutional characteristics, as well as their information-processing characteristics. The social system which supports the development and operation of a CBIS is one major element whose institutional characteristics can effectively support routine activities while impeding substantial innovation. Characterizing CBIS as institutions is important for several reasons: (1) the usability of CBIS is more critical than the abstract information-processing capabilities of the underlying technology; (2) CBIS that are well-used and have stable social structures are more difficult to replace than those with less developed social structures and fewer participants; (3) CBIS vary from one social setting to another according to the ways in which they are organized and embedded in organized social systems. These ideas are illustrated with the case study of a failed attempt to convert a complex inventory control system in a medium-sized manufacturing firm

    A goal model for crowdsourced software engineering

    Get PDF
    Crowdsourced Software Engineering (CSE) is the act of undertaking any external software engineering tasks by an undefined, potentially large group of online workers in an open call format. Using an open call, CSE recruits global online labor to work on various types of software engineering tasks, such as requirements extraction, design, coding and testing. The field is rising rapidly and touches various aspects of software engineering. CSE has grown significance in both academy and industry. Despite of the enormous usage and significance of CSE, there are many open challenges reported by various researchers. In order to overcome the challenges and realizing the full potential of CSE, it is highly important to understand the concrete advantages and goals of CSE. In this paper, we present a goal model for CSE, to understand the real environment of CSE, and to explore the aspects that can somehow overcome the aforementioned challenges. The model is designed using RiSD, a method for building Strategic Dependency (SD) models in the i* notation, applied in this work using iStar2.0. This work can be considered useful for CSE stakeholders (Requesters, Workers, Platform owners and CSE organizations).Peer ReviewedPostprint (published version
    • 

    corecore