Characterization and Classification of Collaborative Tools

Traditionally, collaboration has been a means for organizations to do their work. However, the context in which they do this work is changing, especially in regards to where the work is done, how the work is organized, who does the work, and with this the characteristics of collaboration. Software development is no exception; it is itself a collaborative effort that is likewise affected by these changes. In the context of both open source software development projects and communities and organizations that develop corporate products, more and more developers need to communicate and liaise with colleagues in geographically distant places about the software product they are conceiving, designing, building, testing, debugging, deploying and maintaining. Thus, work teams face sizeable collaborative challenges, for which they have need of tools that they can use to communicate and coordinate their Work efficiently

Pattern Reification as the Basis for Description-Driven Systems

One of the main factors driving object-oriented software development for information systems is the requirement for systems to be tolerant to change. To address this issue in designing systems, this paper proposes a pattern-based, object-oriented, description-driven system (DDS) architecture as an extension to the standard UML four-layer meta-model. A DDS architecture is proposed in which aspects of both static and dynamic systems behavior can be captured via descriptive models and meta-models. The proposed architecture embodies four main elements - firstly, the adoption of a multi-layered meta-modeling architecture and reflective meta-level architecture, secondly the identification of four data modeling relationships that can be made explicit such that they can be modified dynamically, thirdly the identification of five design patterns which have emerged from practice and have proved essential in providing reusable building blocks for data management, and fourthly the encoding of the structural properties of the five design patterns by means of one fundamental pattern, the Graph pattern. A practical example of this philosophy, the CRISTAL project, is used to demonstrate the use of description-driven data objects to handle system evolution.Comment: 20 pages, 10 figure

ERP implementation for an administrative agency as a corporative frontend and an e-commerce smartphone app

This document contains all the descriptions, arguments and demonstrations of the researches, analysis, reasoning, designs and tasks performed to achieve the requirement to technologically evolve an managing agency in a way that, through a solution that requires a reduced investment, makes possible to arrange a business management tool with e-commerce and also a mobile application that allows access and consultation of mentioned tool. The first part of the document describes the scenario in order to contextualize the project and introduces ERP (Enterprise Resources Planning). In the second part, a deep research of ERP market products is carried out, identifying the strengths and weaknesses of each one of the products in order to finish with the choice of the most suitable product for the scenario proposed in the project. A third part of the document describes the installation process of the selected product carried out based on the use of Dockers, as well as the configurations and customizations that they make on the selected ERP. A description of the installation and configuration of additional modules is also made, necessary to achieve the agreed scope of the project. In a fourth part of the thesis, the process of creating an iOS and Android App that connects to the selected ERP database is described. The process begins with the design of the App. Once designed, it is explained the process of study and documentation of technologies to choose the technology stack that allows making an application robust and contemporary without use of licensing. After choosing the technologies to use there are explained the dependencies and needs to install runtime enviornments prior to the start of coding. Later, it describes how the code of the App has been raised and developed. The compilation and verification mechanisms are indicated in continuation. And finally, it is showed the result of the development of the App once distributed. Finally, a chapter for the conclusions analyzes the difficulties encountered during the project and the achievements, analyzing what has been learned during the development of this project

Exploring the Duality between Product and Organizational Architectures: A Test of the Mirroring Hypothesis

A variety of academic studies argue that a relationship exists between the structure of an organization and the design of the products that this organization produces. Specifically, products tend to "mirror" the architectures of the organizations in which they are developed. This dynamic occurs because the organization's governance structures, problem solving routines and communication patterns constrain the space in which it searches for new solutions. Such a relationship is important, given that product architecture has been shown to be an important predictor of product performance, product variety, process flexibility and even the path of industry evolution. We explore this relationship in the software industry. Our research takes advantage of a natural experiment, in that we observe products that fulfill the same function being developed by very different organizational forms. At one extreme are commercial software firms, in which the organizational participants are tightly-coupled, with respect to their goals, structure and behavior. At the other, are open source software communities, in which the participants are much more loosely-coupled by comparison. The mirroring hypothesis predicts that these different organizational forms will produce products with distinctly different architectures. Specifically, loosely-coupled organizations will develop more modular designs than tightly-coupled organizations. We test this hypothesis, using a sample of matched-pair products. We find strong evidence to support the mirroring hypothesis. In all of the pairs we examine, the product developed by the loosely-coupled organization is significantly more modular than the product from the tightly-coupled organization. We measure modularity by capturing the level of coupling between a product's components. The magnitude of the differences is substantial - up to a factor of eight, in terms of the potential for a design change in one component to propagate to others. Our results have significant managerial implications, in highlighting the impact of organizational design decisions on the technical structure of the artifacts that these organizations subsequently develop.Organizational Design, Product Design, Architecture, Modularity, Open-Source Software.

A system for co-ordinating concurrent engineering

Design of large made-to-order products invariably involves design activities which are increasingly being distributed globally in order to reduce costs, gain competitive advantage and utilise external expertise and resources. Designers specialise within their domain producing solutions to design problems using the tools and techniques with which they are familiar. They possess a relatively local perception of where their expertise and actions are consumed within the design process. This is further compounded when design activities are geographically distributed, resulting with the increased disassociation between an individual designer's activities and the overall design process. The tools and techniques used by designers rarely facilitate concurrency, producing solutions within a particular discipline without using or sharing information from other disciplines, and seldom considering stages within the product's life-cycle other than conceptual, embodiment or detail [1, 2]. Conventional management and maintenance of consistency throughout the product model can subsequently become difficult to achieve since there are many factors that need to be simultaneously considered whilst making achange to the product model

Using problem descriptions to represent variabilities for context-aware applications

This paper investigates the potential use of problem descriptions to represent and analyse variability in context-aware software products. By context-aware, we refer to recognition of changes in properties of external domains, which are recognised as affecting the behaviour of products. There are many reasons for changes in the operating environment, from fluctuating resources upon which the product relies, to different operating locations or the presence of objects. There is an increasing expectation for software intensivedevices to be context-aware which, in turn, adds further variability to problem description and analysis. However, we argue in this paper that the capture of contextual variability on current variability representations and analyses has yet to be explored. We illustrate the representation of this type of variability in a pilot study, and conclude with lessons learnt and an agenda for further work

Requirements of a middleware for managing a large, heterogeneous programmable network

Programmable networking is an increasingly popular area of research in both industry and academia. Although most programmable network research projects seem to focus on the router architecture rather than on issues relating to the management of programmable networks, there are numerous research groups that have incorporated management middleware into the programmable network router software. However, none seem to be concerned with the effective management of a large heterogeneous programmable network. The requirements of such a middleware are outlined in this paper. There are a number of fundamental middleware principles that are addressed in this paper; these include management paradigms, configuration delivery, scalability and transactions. Security, fault tolerance and usability are also examined—although these are not essential parts of the middleware, they must be addressed if the programmable network management middleware is to be accepted by industry and adopted by other research projects