Robust Watermarking using Hidden Markov Models

Software piracy is the unauthorized copying or distribution of software. It is a growing problem that results in annual losses in the billions of dollars. Prevention is a difficult problem since digital documents are easy to copy and distribute. Watermarking is a possible defense against software piracy. A software watermark consists of information embedded in the software, which allows it to be identified. A watermark can act as a deterrent to unauthorized copying, since it can be used to provide evidence for legal action against those responsible for piracy.In this project, we present a novel software watermarking scheme that is inspired by the success of previous research focused on detecting metamorphic viruses. We use a trained hidden Markov model (HMM) to detect a specific copy of software. We give experimental results that show our scheme is robust. That is, we can identify the original software even after it has been extensively modified, as might occur as part of an attack on the watermarking scheme

A Taxonomy for a Constructive Approach to Software Evolution

In many software design and evaluation techniques, either the software evolution problem is not systematically elaborated, or only the impact of evolution is considered. Thus, most of the time software is changed by editing the components of the software system, i.e. breaking down the software system. The software engineering discipline provides many mechanisms that allow evolution without breaking down the system; however, the contexts where these mechanisms are applicable are not taken into account. Furthermore, the software design and evaluation techniques do not support identifying these contexts. In this paper, we provide a taxonomy of software evolution that can be used to identify the context of the evolution problem. The identified contexts are used to retrieve, from the software engineering discipline, the mechanisms, which can evolve the software software without breaking it down. To build such a taxonomy, we build a model for software evolution and use this model to identify the factors that effect the selection of software evolution\ud mechanisms. Our approach is based on solution sets, however; the contents of these sets may vary at different stages of the software life-cycle. To address this problem, we introduce perspectives; that are filters to select relevant elements from a solution set. We apply our taxonomy to a parser tool to show how it coped with problematic evolution problems

A literature review of expert problem solving using analogy

We consider software project cost estimation from a problem solving perspective. Taking a cognitive psychological approach, we argue that the algorithmic basis for CBR tools is not representative of human problem solving and this mismatch could account for inconsistent results. We describe the fundamentals of problem solving, focusing on experts solving ill-defined problems. This is supplemented by a systematic literature review of empirical studies of expert problem solving of non-trivial problems. We identified twelve studies. These studies suggest that analogical reasoning plays an important role in problem solving, but that CBR tools do not model this in a biologically plausible way. For example, the ability to induce structure and therefore find deeper analogies is widely seen as the hallmark of an expert. However, CBR tools fail to provide support for this type of reasoning for prediction. We conclude this mismatch between experts’ cognitive processes and software tools contributes to the erratic performance of analogy-based prediction

Designing Software Architectures as Knowledge Specializations

Object-oriented methods aim at providing natural ways for decomposing (or composing) a system into (from) objects that correspond to concepts in the customer's problem domain. The identified objects are the basic building blocks of the object-oriented system to be constructed. In order not to disregard relevant objects, most methods advise software engineers to take dedicated steps such as reading books about the problem domain, interviewing customers, etc. We consider two important concerns in understanding the problem domain. First, it is very important to identify all the objects that are required for defining a consistent system, at least in its minimum configuration. Second, identified objects must serve as composable building blocks to construct robust, adaptable and reusable architecture

Preventing Incomplete/Hidden Requirements: Reflections on Survey Data from Austria and Brazil

Many software projects fail due to problems in requirements engineering (RE). The goal of this paper is analyzing a specific and relevant RE problem in detail: incomplete/hidden requirements. We replicated a global family of RE surveys with representatives of software organizations in Austria and Brazil. We used the data to (a) characterize the criticality of the selected RE problem, and to (b) analyze the reported main causes and mitigation actions. Based on the analysis, we discuss how to prevent the problem. The survey includes 14 different organizations in Austria and 74 in Brazil, including small, medium and large sized companies, conducting both, plan-driven and agile development processes. Respondents from both countries cited the incomplete/hidden requirements problem as one of the most critical RE problems. We identified and graphically represented the main causes and documented solution options to address these causes. Further, we compiled a list of reported mitigation actions. From a practical point of view, this paper provides further insights into common causes of incomplete/hidden requirements and on how to prevent this problem.Comment: in Proceedings of the Software Quality Days, 201

A Relational Database Model for Managing Accelerator Control System Software At Jefferson Lab

The operations software group at the Thomas Jefferson National Accelerator Facility faces a number of challenges common to facilities managing a large body of software developed in-house. Developers include members of the software group, operators, hardware engineers and accelerator physicists. One management problem has been ensuring that all software has an identified maintainer who is still working at the lab. In some cases, locating source code for 'orphaned' software has also proven to be difficult. Other challenges include enforcing minimal standards for versioning and documentation, segregating test software from operational software, encouraging better code reuse, consolidating input/output file storage and management, and tracking software dependencies. This paper will describe a relational database model for tracking the information necessary to solve the problems above. The instantiation of that database model provides the foundation for various productivity- and consistency- enhancing tools for automated (or at least assisted) building, versioning, documenting and installation of software.Comment: ICALEPCS, 2001 PSN#WEAP07

An Exploratory Study of Forces and Frictions affecting Large-Scale Model-Driven Development

In this paper, we investigate model-driven engineering, reporting on an exploratory case-study conducted at a large automotive company. The study consisted of interviews with 20 engineers and managers working in different roles. We found that, in the context of a large organization, contextual forces dominate the cognitive issues of using model-driven technology. The four forces we identified that are likely independent of the particular abstractions chosen as the basis of software development are the need for diffing in software product lines, the needs for problem-specific languages and types, the need for live modeling in exploratory activities, and the need for point-to-point traceability between artifacts. We also identified triggers of accidental complexity, which we refer to as points of friction introduced by languages and tools. Examples of the friction points identified are insufficient support for model diffing, point-to-point traceability, and model changes at runtime.Comment: To appear in proceedings of MODELS 2012, LNCS Springe

Dependency Mapping Software for Jira, Project Management Tool

Efficiently managing a software development project is extremely important in industry and is often overlooked by the software developers on a project. Pieces of development work are identified by developers and are then handed off to project managers, who are left to organize this information. Project managers must organize this to set expectations for the client, and ensure the project stays on track and on budget. The main block in this process are dependency chains between tasks. Dependency chains can cause a project to take much longer than anticipated or result in the under utilization of developers on a project. While project managers do have access to project management tools, few have capabilities to effectively visualize dependencies. The goal of this research was to interact with a project management tool\u27s API, pull down dependency information for a project, and build out possible timelines for a set of tasks. We visualize this problem with a directed graph, where each node is a task and edges in the graph indicate dependencies. The relationships between this problem and more well-known problems in graph theory are used to inform the development of the algorithms. Two algorithms are explored to handle the problem and are then run under different conditions. Analysis of the results provide insight to what structures of dependency chains can be handled by the algorithms. The resulting software could be used to save companies both time and money when planning software development projects