Our Mission: Enable businesses to customize their products and services for far more clients, more accurately, and at lower cost.

     
Quick Links
Guided Tour
Online Demo
Technology
Product Line Studio
Software Product Lines
Process Scalability
Terminology
Reference Material
Search
Contact
  PHILOSOPHY AND PRIORITIES  
 

IDI publishes the road-map of the Product Line Studio suite right along with our current offerings.  IDI's philosophy is that our current and future customers need to understand how we see Product Line Studio evolving in the future. We believe that an open and clear process of communication builds loyalty. Consequently, we clearly lay out what our priorities are and why.

Below are the fundamental philosophical underpinnings that sit behind our approach to Software Product Line methodologies, and to Product Line Studio in particular:

  • Variability Management is for Everybody

In a successful and mature Software Product Line, variability management is not the domain of specialists; it is part of everybody's work. Management of variability must be integrated into the mainstream of work, not an adjunct managed by "someone else", a specialist.

An implication of this philosophy is that we are committed to making PLS the most user-friendly tool in the industry for managing variability. It must use terminology most comfortable for practitioners, not researchers.

At the same time we will NOT turn PLS into predominantly a "variability management" solution.  If variability management takes center stage in the tool, the primary work of the normal developer (developing requirements, implementing software, and communicating via documentation) will never be naturally and comfortably connected to variability.

Instead, PLS will focus on enabling the mainstream of work (developing requirements, implemeintg software, and communicating via documentation), where managing variability is a seamless part of that work.

Although we will support the most sophisticated capabilities, such as a broad and extensible handling of constraints in variability models, we are committed to making it easy to do the most common types of tasks. For example, it must be easy for a non-technical person describing a new feature of typical complexity to be able to define the configuration space associated with that feature -- without being a specialist in variability management, and without contortions in their workflow.

  • Release Schedules driven by Current Customers

We set our development priorities and release schedules based on the needs of our current customer base. For each module in our product plan we assign a status designation:

FUTURE Module is in the product plan but is not currently under development.
DEV Module is currently under development.
PREVIEW Module can be seen upon request by customers considering early adoption.
BETA Module can be used by customers, but is not yet in final form.
PROD Module is available for general use.

An implication is that we do not provide firm and final dates for the release of Modules designated as FUTURE. Such modules are firmly in the product plan but are not yet being requested as a high priority by our customer base.

At the same time, we will not compromise the architectural integrity of the PLS suite for short-term interests. In other words, if a module is in the plan and designated as FUTURE, we are committed to an optimized implementation when the time is right.

  • Holistic, Long-Term View

We are committed to a holistic view of Software Product Lines ensuring well-integrated coverage from requirements, to software, to document generation.

We believe that mainstream adoption of Software Product Line methodology will not happen until it is well-supported as an integrated part of readily available tools. Vendors of tools that are in the mainstream today, however, are not eager to embrace Software Product Line methodology because to do it well would be intrusive into the design of their tried-and-tested tools. That is, integrating variability management into the mainstream of work changes the way one thinks about the mainstream of work. This causes a chicken-and-egg problem: tool venders are waiting to see if the industry embraces Software Product Lines, and practioners are reluctant to embrace Software Product Lines until variability management is a built-in and automatic part of normal work, not the domain of specialists.

A similar development has occurred over the last 10 years in the area of requirements management.  Tools for requirements traceability were originally developed for requirements analysis specialists, not for everyday users. We believe this is why, even today, many organizations still set requirements traceability aside as a dispensible, non-critical, role.

Given this understanding, we redouble our commitment to the holistic view, our commitment to seeing our customers experience dramatic successes, and our belief that in the long run the market will reward the patient.