212 research outputs found

    Using quality models in software package selection

    Get PDF
    The growing importance of commercial off-the-shelf software packages requires adapting some software engineering practices, such as requirements elicitation and testing, to this emergent framework. Also, some specific new activities arise, among which selection of software packages plays a prominent role. All the methodologies that have been proposed recently for choosing software packages compare user requirements with the packages' capabilities. There are different types of requirements, such as managerial, political, and, of course, quality requirements. Quality requirements are often difficult to check. This is partly due to their nature, but there is another reason that can be mitigated, namely the lack of structured and widespread descriptions of package domains (that is, categories of software packages such as ERP systems, graphical or data structure libraries, and so on). This absence hampers the accurate description of software packages and the precise statement of quality requirements, and consequently overall package selection and confidence in the result of the process. Our methodology for building structured quality models helps solve this drawback.Peer ReviewedPostprint (published version

    An empirical study on the use of i* by non-technical stakeholders: the case of strategic dependency diagrams

    Get PDF
    Early phases of information systems engineering include the understanding of the enterprise’s context and the construction of models at different levels of decomposition, required to design the system architecture. These time-consuming activities are usually conducted by relatively large teams, composed of groups of non-technical stakeholders playing mostly an informative role (i.e. not involved in documentation and even less in modelling), led by few experienced technical consultants performing most of the documenting and modelling effort. This paper evaluates the ability of non-technical stakeholders to create strategic dependency diagrams written with the i* language in the design of the context model of a system architecture, and find out which difficulties they may encounter and what the quality of the models they build is. A case study involving non-technical stakeholders from 11 organizational areas in an Ecuadorian university held under the supervision and coordination of the two authors acting as consultants. The non-technical stakeholders identified the majority of the dependencies that should appear in the case study’s context model, although they experienced some difficulties in declaring the type of dependency, representing such dependencies graphically and applying the description guidelines provided in the training. Managers were observed to make more mistakes than other more operational roles. From the observations of these results, a set of methodological advices were compiled for their use in future, similar endeavours. It is concluded that non-technical stakeholders can take an active role in the construction of the context model. This conclusion is relevant for both researchers and practitioners involved in technology transfer actions with use of i*.Peer ReviewedPostprint (author's final draft

    A quality-model-based approach for describing and evaluating software packages

    Get PDF
    Selection of software packages from user requirements is a central task in software engineering. Selection of inappropriate packages may compromise business processes and may interfere negatively in the functioning of the involved organization. Success of package selection is endangered because of many factors, one of the most important being the absence of structured descriptions of both package features and user quality requirements. In this paper, we propose a methodology for describing quality factors of software packages using the ISO/IEC quality standard as a framework. Following this standard, relevant attributes for a specific software domain are identified and structured as a hierarchy, and metrics for them are chosen. Software packages in this domain can then be described in a uniform and comprehensive way. Therefore, selection of packages can be ameliorated by transforming user quality requirements into requirements expressed in terms of quality model attributes. We illustrate the approach by presenting, in some depth, a quality model for the mail server domain.Peer ReviewedPostprint (published version

    A framework for selecting workflow tools in the context of composite information systems

    Get PDF
    When an organization faces the need of integrating some workflow-related activities in its information system, it becomes necessary to have at hand some well-defined informational model to be used as a framework for determining the selection criteria onto which the requirements of the organization can be mapped. Some proposals exist that provide such a framework, remarkably the WfMC reference model, but they are designed to be appl icable when workflow tools are selected independently from other software, and departing from a set of well-known requirements. Often this is not the case: workflow facilities are needed as a part of the procurement of a larger, composite information syste m and therefore the general goals of the system have to be analyzed, assigned to its individual components and further detailed. We propose in this paper the MULTSEC method in charge of analyzing the initial goals of the system, determining the types of components that form the system architecture, building quality models for each type and then mapping the goals into detailed requirements which can be measured using quality criteria. We develop in some detail the quality model (compliant with the ISO/IEC 9126-1 quality standard) for the workflow type of tools; we show how the quality model can be used to refine and clarify the requirements in order to guarantee a highly reliable selection result; and we use it to evaluate two particular workflow solutions a- ailable in the market (kept anonymous in the paper). We develop our proposal using a particular selection experience we have recently been involved in, namely the procurement of a document management subsystem to be integrated in an academic data management information system for our university.Peer ReviewedPostprint (author's final draft

    A catalogue of reusable context model elements based on the i* framework

    Get PDF
    The definition of the context of a system is one of the most relevant activities in the early phases of information systems engineering. It allows system engineers to narrow the system scope, by defining well established system boundaries. In practice, outlining a system context model is complex and cumbersome. In order to support context modeling, in this paper we propose a catalogue of context model elements expressed in i*, which can be reused as building blocks in the construction of context models for new systems. We describe the process used for the identification of a set of actors and dependencies recurrently appearing in several academic and industrial cases, and the process to store them into a catalogue of reusable i* context dependencies.Peer ReviewedPostprint (author's final draft

    i* in practice: identifying frequent problems in its application

    Get PDF
    Several notations have been proposed in the last decades to support information system architecting, design and implementation. Although some of them have been widely adopted, their practical application remains cumbersome. Reasons are manifold: ambiguous semantics, confusing graphical representation, lack of safe guidelines, etc. In this paper, we explored the use of the i* framework in industry for modeling organizational context. We review the models resulting from 36 industrial collaborations conducted in the last five years, where i* has been intensively used by novice modellers, without previous exposure to i*, acting as junior consultants in the organizations. We identify and categorize the main problems that they faced and as a result, we propose a set of guidelines to improve the adoption and practical application of the framework.Peer ReviewedPostprint (author's final draft

    DesCOTS: a software system for selecting COTS components

    Get PDF
    Selection of commercial-off-the-shelf software components (COTS components) has a growing importance in software engineering. Unfortunately, selection projects have a high risk of ending up into abandonment or yielding an incorrect selection. The use of some software engineering practices such as the definition of quality models can reduce this risk. We defined a process for COTS components selection based on the use of quality models and we started to apply it in academic and industrial cases. The need of having a tool to support this process arose and, although some tools already exist to partially support the involved activities, none of them was suitable enough. Because of this we developed DesCOTS, a software system that embraces several tools that interact to support the different activities of our process. The system has been designed taking into account not only functional concerns but also nonfunctional aspects such as reusability, interoperability and portability. We present in this paper the different subsystems of DesCOTS and discuss about their applicability.Peer ReviewedPostprint (published version

    Towards the definition of a quality model for mail servers

    Get PDF
    The paper presents an approach for building a Mail Server Quality Model, based on the ISO/IEC software quality standard. We start by defining the mail system domain to be used as general framework and the relevant technologies involved. Then a general overview of the ISO/IEC standard is given. The basic steps, the relevant considerations and criteria used to select the appropriated subcharacteristics and quality attributes are also presented. The selected attributes are categorized under the six ISO/IEC quality characteristics conforming the model. Finally some case studies requirements and two commercial mail server tools are used to evaluate the model.Postprint (published version

    Lessons learned on the use of i* by non-technical users

    Get PDF
    Enterprise Architecting activities, particularly the mapping from business strategies to information systems architectures, are time-consuming activities usually conducted by relatively large teams, composed of groups of nontechnical stakeholders playing mostly an informative role, led by few experienced technical consultants performing most of the documenting and modelling effort. Lately, several works have been reported that propose and use i* to support these modelling activities. In spite of this increasing adoption and experiences in different domains, there exists little work in relation to the practical use of i* by non-technical stakeholders and the ability that the notation may provide them to become more proactive in system modelling activities. We present here 10 lessons learned in a study conducted in an Ecuadorian University to gain empirical evidence in relation to the use of i* by non-technical stakeholders.Peer ReviewedPostprint (published version
    corecore