Introducing use cases in a small organization: An experience and lessons learned

In this paper we report the adoption of use cases by a small organization in a university setting. Use cases were first introduced in the middle of a huge project and adopted thereafter for later projects. The paper mostly focuses in the first experience, whose most interesting characteristics were the large size of the resulting specification, the fact that it took place once the project had started (for documentation purposes instead of driving the development) and the limitation that resources allocated were not as much as required. We present the lessons learned from this experience

Risk assessment in open source systems

Adopting Open Source Software (OSS) components offers many advantages to organizations but also introduces risks related to the intrinsic fluidity of the OSS development projects. Choosing the right components is a critical decision, as it could contribute to the success of any adoption process. Making the right decision requires to evaluate the technical capabilities of the components and also related strategic aspects, including possible impacts on high level objectives. This can be achieved through a portfolio of risk assessment and mitigation methods. In this briefing we introduce the basic concepts related to OSS ecosystems and to risk representation and reasoning. We illustrate how risk management activities in OSS can benefit from the large amount of data available from OSS repositories and how they can be connected to business goals for strategic decision-making. The concepts are illustrated with a software platform developed in the context of the EU FP7 project RISCOSS.Peer ReviewedPostprint (author's final draft

Synthesis of OCL Pre-conditions for Graph Transformation Rules

Proceedings of: Third International Conference on Model Transformation (ICMT 2010): Theory and Practice of Model Transformation. Málaga, Spain, 28 June-02 July, 2010Graph transformation (GT) is being increasingly used in Model Driven Engineering (MDE) to describe in-place transformations like animations and refactorings. For its practical use, rules are often complemented with OCL application conditions. The advancement of rule post-conditions into pre-conditions is a well-known problem in GT, but current techniques do not consider OCL. In this paper we provide an approach to advance post-conditions with arbitrary OCL expressions into pre-conditions. This presents benefits for the practical use of GT in MDE, as it allows: (i) to automatically derive pre-conditions from the meta-model integrity constraints, ensuring rule correctness, (ii) to derive pre-conditions from graph constraints with OCL expressions and (iii) to check applicability of rule sequences with OCL conditions.Work funded by the Spanish Ministry of Science and Innovation through projects “Design and construction of a Conceptual Modeling Assistant” (TIN2008-00444/TIN - Grupo Consolidado), “METEORIC” (TIN2008-02081),mobility grants JC2009-00015 and PR2009-0019, and the R&D program of the Community of Madrid (S2009/TIC-1650, project “e-Madrid”).Publicad

The conceptual schema of Ethereum

There is an abundant literature on Ethereum, but as far as we know what is missing is its explicit conceptual schema. We present here the conceptual schema of Ethereum in UML. The schema should be useful to those that want to understand Ethereum. We also show that the schema is necessary for developing the schema of Ethereum–based DApps. We present a few population constraints, and show that they suffice for the specification at the conceptual level of what is understood by immutability of a blockchain. We also show that the well–known reification construct and an initial constraint suffice to specify at the conceptual level that the Ethereum blockchain stores the full state history.Peer ReviewedPreprin

Modelling and Applying Oss Adoption Strategies

Increasing adoption of Open Source Software (OSS) in information system engineering has led to the emergence of different OSS business strategies that affect and shape organizations’ business models. In this context, organizational modeling needs to reconcile efficiently OSS adoption strategies with business strategies and models. In this paper, we propose to embed all the knowledge about each OSS adoption strategy into an i* model that can be used in the intentional modeling of the organization. These models describe the consequences of adopting one such strategy or another: which are the business goals that are supported, which are the resources that emerge, etc. To this aim, we first enumerate the main existing OSS adoption strategies, next we formulate an ontology that comprises the activities and resources that characterise these strategies, then based on the experience of 5 industrial partners of the RISCOSS EU-funded project, we explore how these elements are managed in each strategy and formulate the corresponding model using the i* framewor

The Cause-Effect Rules of ROSES

This paper presents a new behavioural specification approach for conceptual modelling of Information Systems (IS). We call it the Cause-effect rule approach because the specification consists of a number of independent rules, each of which establishing a relationship between a cause and an effect. Such rules are common in the active database systems field [WiC96], but their potential use in conceptual modelling of IS has not been explored in depth. Our approach has been developed in the context of the ongoing ROSES (Rules, ObjectS and EventS) project, whose aim is, among others, to explore the application of causeeffect rules in the formal specification of the behaviour of IS. However, we believe that the approach is general, and that it might inspire some ideas helpful in other contexts or languages. In some respects, our work has some points in common with the work reported in [HR92, MHCM96], and some similarity with the Chimera language [CeF97], as will be described later. We review, in the next section, the components of a conceptual model and characterise the main existing approaches with respect to the behavioural model. Sections 3 to 6 describe our approach, with emphasis on the behavioural model, and section 7 gives some elements for a comparison between our approach and the most popular ones

Deriving Operation Contracts from UML Class Diagrams

Class diagrams must be complemented with a set of system operations that describes how users can modify and evolve the system state. To be useful, such a set must be complete (i.e. through these operations, users should be able to modify the population of all elements in the class diagram) and executable (i.e. for each operation, there must exist a system state over which the operation can be successfully applied). Manual specification of these operations is an error-prone and time-consuming activity. Therefore, the goal of this paper is to automatically provide a basic set of system operations that verify these two properties. Operations are drawn from the elements (classes, attributes, etc) of the class diagram and take into account the possible dependencies between the different change events (i.e. inserts/updates/deletes) that may be applied to them. Afterwards, the designer could reuse our proposal to build up more complex operations

Non-functional requirements documentation in agile software development:challenges and solution proposal

Abstract Non-functional requirements (NFRs) are determinant for the success of software projects. However, they are characterized as hard to define, and in agile software development (ASD), are often given less priority and usually not documented. In this paper, we present the findings of the documentation practices and challenges of NFRs in companies utilizing ASD and propose guidelines for enhancing NFRs documentation in ASD. We interviewed practitioners from four companies and identified that epics, features, user stories, acceptance criteria, Definition of Done (DoD), product and sprint backlogs are used for documenting NFRs. Wikis, word documents, mockups and spreadsheets are also used for documenting NFRs. In smaller companies, NFRs are communicated through white board and flip chart discussions and developers’ tacit knowledge is prioritized over documentation. However, loss of traceability of NFRs, the difficulty in comprehending NFRs by new developers joining the team and limitations of documentation practices for NFRs are challenges in ASD. In this regard, we propose guidelines for documenting NFRs in ASD. The proposed guidelines consider the diversity of the NFRs to document and suggest different representation artefacts depending on the NFRs scope and level of detail. The representation artefacts suggested are among those currently used in ASD in order not to introduce new specific ones that might hamper actual adoption by practitioners

Adoption of OSS components: A goal-oriented approach

Open Source Software (OSS) has become a strategic asset for a number of reasons, such as short time-to-market software delivery, reduced development and maintenance costs, and its customization capabilities. Therefore, organizations are increasingly becoming OSS adopters, either as a result of a strategic decision or because it is almost unavoidable nowadays, given the fact that most commercial software also relies at some extent in OSS infrastructure. The way in which organizations adopt OSS affects and shapes their businesses. Therefore, knowing the impact of different OSS adoption strategies in the context of an organization may help improving the processes undertaken inside this organization and ultimately pave the road to strategic moves. In this paper, we propose to model OSS adoption strategies using a goal-oriented notation, in which different actors state their objectives and dependencies on each other. These models describe the consequences of adopting one such strategy or another: which are the strategic and operational goals that are supported, which are the resources that emerge, etc. The models rely on an OSS ontology, built upon a systematic literature review, which comprises the activities and resources that characterize these strategies. Different OSS adoption strategy models arrange these ontology elements in diverse ways. In order to assess which is the OSS adoption strategy that better fits the organization needs, the notion of model coverage is introduced, which allows to measure the degree of concordance among every strategy with the model of the organization by comparing the respective models. The approach is illustrated with an example of application in a big telecommunications company