5 research outputs found

    Selection of third party software in Off-The-Shelf-based software development: an interview study with industrial practitioners

    Get PDF
    The success of software development using third party components highly depends on the ability to select a suitable component for the intended application. The evidence shows that there is limited knowledge about current industrial OTS selection practices. As a result, there is often a gap between theory and practice, and the proposed methods for supporting selection are rarely adopted in the industrial practice. This paper's goal is to investigate the actual industrial practice of component selection in order to provide an initial empirical basis that allows the reconciliation of research and industrial endeavors. The study consisted of semi-structured interviews with 23 employees from 20 different software-intensive companies that mostly develop web information system applications. It provides qualitative information that help to further understand these practices, and emphasize some aspects that have been overlooked by researchers. For instance, although the literature claims that component repositories are important for locating reusable components; these are hardly used in industrial practice. Instead, other resources that have not received considerable attention are used with this aim. Practices and potential market niches for software-intensive companies have been also identified. The results are valuable from both the research and the industrial perspectives as they provide a basis for formulating well-substantiated hypotheses and more effective improvement strategies.Peer ReviewedPostprint (author's final draft

    Bridging the gap among academics and practitioners in non-functional requirements management: some reflections and proposals for the future

    Get PDF
    The software engineering community has paid a lot of attention to the study of non-functional requirements (NFRs). Along time, framing NFRs into an articulated framework has become an elusive target. As a consequence, prac-titioners usually integrate NFRs in the different system life-cycle activities in an ad-hoc manner. In this work, we summarise the results of a recent empirical study involving 13 software architects from the Spanish. These results serve as the basis for discussion about possible ways to bridge the gap between academics and practitioners in the management of NFRs.Postprint (author’s final draft

    System requirements-OSS components: matching and mismatch resolution practices – an empirical study

    Get PDF
    Developing systems by integrating Open Source Software (OSS) is increasingly gaining importance in the software industry. Although the literature claims that this approach highly impacts Requirements Engineering (RE) practices, there is a lack of empirical evidence to demonstrate this statement. To explore and understand problems and challenges of current system requirement–OSS component matching and mismatches resolution practices in software development projects that integrate one or more OSS components into their software products. Semi-structured in-depth interviews with 25 respondents that have performed RE activities in software development projects that integrate OSS components in 25 different software development companies in Spain, Norway, Sweden, and Denmark. The study uncovers 15 observations regarding system requirements-OSS components matching and mismatch resolution practices used in industrial projects that integrate OSS components. The assessed projects focused mainly on pre-release stages of software applications that integrate OSS components in an opportunistic way. The results also provide details of a set of previously unexplored scenarios when solving system requirement–OSS component mismatches; and clarify some challenges and related problems. For instance, although licensing issues and the potential changes in OSS components by their corresponding communities and/or changes in system requirements have been greatly discussed in the RE literature as problems for OSS component integration, they did not appear to be relevant in our assessed projects. Instead, practitioners highlighted the problem of getting suitable OSS component documentation/information.Peer ReviewedPostprint (author's final draft

    Definition and use of software requirement patterns in requirements engineering

    Get PDF
    The final quality of software products and services depends on the requirements stated in the Software Requirements Specifications (SRSs). However, some problems like ambiguity, incompleteness and inconsistency have been reported in the writing of SRSs, especially when natural language is used. Requirements reuse has been proposed as a key asset for requirements engineers to efficiently elicit, validate and document software requirements and, as a consequence, obtain SRSs of better quality through more effective engineering processes. Among all the possible techniques to achieve reuse, patterns hold a prominent position. In their most classical form, patterns describe problems that occur over and over again, and then describe the core of the solution to these problems. Software engineering practitioners have adopted the notion of pattern in several contexts, remarkably related to software design (e.g., design patterns and software architectural patterns), but also in other software development phases, both earlier and later. Following this strategy, requirement patterns emerge as a natural way to reuse knowledge during the Requirements Engineering (RE) stage. Although there have been several techniques proposed to reuse requirements, it has been observed that no concrete proposal has achieved a wide acceptance, neither any covered all the necessary elements to encourage organizations to adopt requirements reuse. As a consequence, this thesis proposes the use of Software Requirement Patterns (SRPs) as a means to capture and reuse requirements knowledge in the context of information technology projects. Following the typical context-problem-solution structure of patterns, an SRP mainly consists of: a template (solution) that may generate one or more requirements when applied in a certain project, and some information (context-problem) to identify its applicability in that project. To facilitate their use, SRPs are encapsulated inside the PABRE (PAttern-Based Requirements Elicitation) framework. The framework covers all the elements that could be critical for the adoption of a requirements reuse technique. Specifically, the framework includes: - A metamodel that describes the structure and semantics of SRPs and their organization inside a catalogue. - An SRP catalogue composed by non-functional, non-technical and functional SRPs, the functional ones being specific for the content management system domain. - A method for guiding the use of an SRP catalogue during requirements elicitation and specification, as well as another one for constructing and updating it. - An economic model to perform cost-benefit analysis on the adoption of SRPs based on return-on-investment. - The PABRE system as technological support. In order to analyse the benefits and drawbacks of the SRPs proposed in this thesis, two empirical studies have been carried out to investigate the perception of participants about requirement patterns in general and SRPs in particular. The first one is an exploratory survey addressed to information technology people with industrial experience in RE, which analyses the current state of the practice of requirement patterns approaches. The second one corresponds to a set of semi-structured interviews, focussed on the SRP approach, conducted to requirements engineers of Swedish organizations. Moreover, as it has been discovered that there are few empirical studies showing the state of the practice of requirements reuse in industry, the first study also explores the current situation of requirements reuse practices in organizations.La qualitat final dels productes i serveis de software depèn del requisits definits en l’especificació de Requisits Software (ERS). Tot i així, alguns problemes com la ambigüitat, incompletesa i inconsistència han sigut detectats en la escriptura dels ERS, especialment quan el llenguatge natural és usat per escriure’ls. La reutilització de requisits ha sigut proposada com un recurs clau pels enginyers de requisits per tal d’obtenir, validar i documentar requisits software i, com a conseqüència, obtenir ERS de millor qualitat usant processos d’enginyeria més efectius. Entre totes les tècniques possibles per aconseguir la reutilització, els patrons tenen una posició destacada. En la seva forma més clàssica, els patrons descriuen problemes que ocorren sovint, i després descriuen la part central de la solució a aquests problemes. Els professionals de la enginyeria del software han adoptat la noció de patró en diferents àmbits, especialment en els relacionats amb el disseny del software (per exemple, els patrons de disseny i els patrons d’arquitectura del software), però també en altres etapes del desenvolupament del software, tant abans com després del seu disseny. Seguint aquesta estratègia, els patrons de requisits emergeixen com una manera natural de reutilitzar coneixement durant l’etapa d’enginyeria de requisits. Tot i que hi ha hagut varies tècniques proposades per reutilitzar requisits, s’ha observat que no hi ha cap proposta concreta que hagi aconseguit una àmplia acceptació, ni cap proposta completa que cobreixi tots els elements necessaris per animar a les organitzacions a adoptar la reutilització de requisits. Com a conseqüència, aquesta tesis proposa l’ús de Patrons de Requisits Software (en anglès Software Requirement Patterns o SRPs) com un medi per capturar i reutilitzar coneixement de requisits en l’àmbit de projectes de tecnologia de la informació. Seguint la estructura típica dels patrons de context-problema-solució, un SRP consisteix en: una plantilla (solució) que pot generar un o més requisits quan és aplicat en un projecte específic, i informació relacionada (context-problema) per identificar la seva aplicabilitat en un projecte. Per facilitar el seu ús, els SRP han sigut encapsulats dintre del framework PABRE (de l’anglès PAttern-Based Requirements Elicitation). El framework cobreix tots els elements que podrien ser crítics per adoptar una tècnica de reutilització de requisits. Més detalladament, el framework inclou: - Un meta model que descriu la estructura i semàntica dels SRPs i la seva organització dintre d’un catàleg.Postprint (published version

    How Important Is Evidence, Really?

    No full text
    corecore