Patrick Donohoe

Feature-oriented product line engineering

The feature-oriented reuse method analyzes and models a product lines commonalities and differences in terms of product features and uses the analysis results to develop architectures and components. The article illustrates, with a home integration system example, how FORM brings efficiency into product line development.

Using a Marketing and Product Plan as a Key Driver for Product Line Asset Development

The product line engineering paradigm has emerged recently to address the need to minimize the development cost and the time to market in this highly competitive global market. Product line development consists of product line asset development and product development using the assets. Product line requirements are essential inputs to product line asset development. These inputs, although critical, are not sufficient to develop product line assets. A marketing and product plan, which includes plans on what features are to be packaged in products, how these features will be delivered to customers (e.g., feature binding time), and how the products will evolve in the future, also drives product line asset development; thus this paper explores design issues from the marketing perspective and presents key design drivers that are tightly coupled with the marketing strategy. An elevator control software example is used to illustrate how product line asset development is related to marketing and product plans.

Performance Evaluation of NoSQL Databases: A Case Study

The choice of a particular NoSQL database imposes a specific distributed software architecture and data model, and is a major determinant of the overall system throughput. NoSQL database performance is in turn strongly influenced by how well the data model and query capabilities fit the application use cases, and so system-specific testing and characterization is required. This paper presents a method and the results of a study that selected among three NoSQL databases for a large, distributed healthcare organization. While the method and study considered consistency, availability, and partition tolerance (CAP) tradeoffs, and other quality attributes that influence the selection decision, this paper reports on the performance evaluation method and results. In our testing, a typical workload and configuration produced throughput that varied from 225 to 3200 operations per second between database products, while read operation latency varied by a factor of 5 and write latency by a factor of 4 (with the highest throughput product delivering the highest latency). We also found that achieving strong consistency reduced throughput by 10-25% compared to eventual consistency.

A Production System for Software Product Lines

Companies such as Toyota have achieved significant competitive advantage by treating product production as a system that can be planned and optimized. Software product line organizations can achieve similar advantage when they explicitly coordinate the actions of core asset and product developers. We describe a technique for planning the production system for a software product line organization. The technique encompasses a production strategy, which relates the production goals of the product line to the method of core asset and product development; and a production method, which coordinates the development of core assets with the production of products. The results of the technique are documented in a production plan, which guides the product developers through the steps of production. Data gathered from representatives of SPLC Product Line Hall of Fame members and our experience working with product line organizations are used to illustrate problems and specify solutions.

Requirements engineering in software product line engineering

AbstractMany attempts have been made to increase the productivity and quality of software products based on software reuse. Software product line practice is one such approach, one that focuses on developing a family of products which have a majority of features in common. Hence, there are numerous requirements that are common across the family, but others are unique to individual products. Traditional requirements engineering methods were conceived to deal with single product requirements and are usually not flexible enough to address the needs arising from reusing requirements for a family of products. There is also the additional burden of correctly identifying and engineering both product-line-wide requirements and product-specific requirements as well as evolving them. Therefore, in this special issue, we want to highlight the importance and the role of requirements engineering for product line development as well as to provide insights into the state of the art in the field.

Creating Software Modernization Roadmaps: The Architecture Options Workshop

Architecture modernization requires a clear roadmap to transition to a new state. However, creating that roadmap is often difficult, particularly in complex settings. This paper investigates how one might systematically derive such roadmaps. We introduce the Architecture Options Workshop (AOWS), a systematic treatment to address the problems of moving from identi ed system risk themes to potential design options, and a roadmap for implementation. Many techniques present a range of options and leave it to stakeholders to select, or are tailored for detailed design processes. The Architecture Options Workshop, by contrast, is intended to resolve the question of what options to choose at a high level of abstraction. Applying a technical action research approach, we applied the AOWS to three di erent real-world systems. We describe the advantages -- reasonably efficient, systematic architecture modernization -- and some remaining questions for future research.

Benchmarking for deadline-driven computing

Hartstone is a series of timing requirements for testing a systems ability to handle hard real-time applications. It is specified as a set of processes with well-defined workloads and timing constraints. The name Hartstone derives from HArd Real Time and the fact that the workloads are based on the well-known Whetstone benchmark. This paper describes the results obtained by running Version 1.0 of the Hartstone benchmark, an Ada implementation of one of the requirements, on a number of compiler/target processor combinations. The characteristics and expected behavior of the benchmark are described, actual results are presented and analyzed, and the lessons learned about the compilers and processors, and the benchmark itself, are discussed. Nothing in this paper should be taken as an endorsement of, or an indictment of, a particular product. Users of Ada technology are encouraged to experiment with the Hartstone benchmark relative to their own particular application requirements.

Commonality and variability analysis for resource constrained organizations

This position paper describes our current work in adapting a software product line technique to the constraints of a development organization. We report on applying a commonality and variability analysis with an organization adopting a software product line approach while facing sever resource constraints because of current product development commitments. The immediate focus of the paper is on blending commonality and variability analysis into the organizations existing requirements development process. The longer-term goal of this work is to facilitate the transition to product lines in a minimally intrusive way. The paper describes how the approach was introduced and implemented, and summarizes the benefits achieved and the issues arising from the work to date.

Application-Specific Evaluation of No SQL Databases

The selection of a particular NoSQL database for use in a big data system imposes a specific distributed software architecture and data model, making the technology selection difficult to defer and expensive to change. This paper reports on the selection of a NoSQL database for use in an Electronic Healthcare Record system being developed by a large healthcare provider. We performed application-specific prototyping and measurement to identify NoSQL products that fit data model and query use cases, and meet performance requirements. We found that database throughput varied by a factor of 10, read operation latency varied by a factor of 5, and write latency by a factor of 4 (with the highest throughput product delivering the highest latency). We also found that the throughput for workloads using strong consistency was 10-25% lower than workloads using eventual consistency. We conclude by reflecting on some of the fundamental difficulties of performing detailed technical evaluations of NoSQL databases specifically, and big data systems in general, that have become apparent during our study.

First international workshop on requirements engineering practices on software product line engineering (REPOS 2012)

The objective of this workshop is to attract professionals from academia and industry to discuss the role of requirements engineering in product line developments, including new techniques, methods and tools that will help practitioners to improve their current requirements engineering practices. The workshop will address experiences from practitioners, empirical evidence about current practices, successful deployment of novel approaches, and current obstacles and proposed solutions. Nevertheless, REPOS also aims to become a discussion forum about the state of the art and practice for practitioners and researchers on Requirements Engineering for Software Product Lines.