A product line organization using an open development method

Opening access to the source code for a product is a business strategy that is increasingly used as the basis for innovative collaborations with stakeholders. The strategy has been successful at producing a large quantity of high-quality software. A tactic in this strategy is to effectively use the efforts of many widely dispersed professionals. The processes, software tools and the communication mechanisms used to facilitate concurrent development by a large number of people are of as much interest as the software being created. In this position paper we present our view of how a software product line organization might operate if it used an open development method (ODM) but is not necessarily producing open source software. We will describe a hypothetical product line (HPL), which is part speculation, part our experience, and partly the experience of others

Measures for Software Product Lines

This technical note characterizes the status of measurement associated with the operation of a software product line, suggests a small set of measures to support its management, and provides guidance for those establishing measurement activities within a software product line. It is intended to help managers of software product lines develop a set of base measures for tracking those categories of needs most relevant to their organization's products, projects, and processes. The measures suggested here range from relatively mature to those whose general utility have yet to be validated. Therefore, an organization using this paper needs to assess its ability to generate the measures and the value they are likely to return to the organization. In most cases, an organization may wish to start with a subset of the measures described

Toward Measures for Software Architectures

This technical note describes the results of a preliminary investigation into measures for software architecture. It focuses on measures that directly indicate the health of or detect a problem with the software architecture of an up-and-running software system. Defining these architectural measures is very difficult. The software architecture deeply affects the subsequent development and project management decisions, such as the breakdown of the coding tasks and the definition of the development increments. Most existing measures for up-and-running software systems capture the cumulative results of architectural, developmental, and managerial decisions and do not directly address the health of the software architecture. The investigation into measures requires the joint participation of the software architecture and measurement communities. Since the software architecture community has made such rapid progress over the past ten years, this report first describes what the measurement community needs to know about software architecture to understand the difficulty of defining architectural measures. The current relevant literature is then described in terms of its potential contribution to this research. Finally, the report identifies areas for future research into the application of measurement technology to software architectures. The ultimate goal of this body of work is to provide measurement guidance and quantitative decision support to software practitioners, including software architects and project managers

Product Line Analysis for Practitioners

Planning for the development of products early in the lifetime of a software product line is critical to the success of that product line. Requirements for that development both affect and are affected by the product requirements. This technical report describes the addition of development requirements to product line analysis. It further describes the refinement of product and development responsibilities, and the relationships among them, by use of examples specifically targeted at the practitioner of product line analysis

An Ada Binding to the SAFENET Lightweight Application Services

This document describes an ADA binding to the Survivable ADAptable Fiber Optic Embedded Network (SAFENET) lightweight application services. The major goal in the design of the binding was schedulability. The document contains the ADA package specifications for the binding as well as a rationale for the design