LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 7/1/2009 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
Is the mystery Borland suitor Serena?
Borland software is considering an offer from another company after a preliminary deal with MicroFocus. Is Serena the new company?
06/30/2009 01:55 PM EST

Windows 7 - An eBayer's dream product?
Windows 7 pre-orders can make people money on eBay.
06/29/2009 03:48 PM EST

Know thine cloud provider
Cloud computing require companies to understand compliance and regulation. Third parties will play a big role in regulated industries.
06/29/2009 02:58 PM EST

 

Microsoft Worldwide Partner Conf.
7/13/2009 to 7/16/2009
New Orleans
Microsoft

OSCON (Open Source Convention)
7/20/2009 to 7/24/2009
San Jose
O'Reilly Media

XBRL Technology Workshop & Summit
7/28/2009 to 7/30/2009
Santa Clara
XBRL US

ACM SIGGRAPH
8/3/2009 to 8/7/2009
New Orleans
ACM SIGGRAPH

OpenSource World (formerly LinuxWorld)
8/12/2009 to 8/13/2009
San Francisco
IDG World Expo


 
print Printable version 
Most Read Latest News Blog Resources
Kapow automates website data retrieval
Kapow Technology's Web Data Server 7.0 can be used to create modules that navigate through...

Oracle's Fusion 11g lays groundwork for ERP platform
Fusion's components are standards-based and integrated, but some abilities are lost if non...

COBOL’s future lies in the clouds
After 50 years of use in businesses, COBOL is still lingering around mainframes. But the s...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

Moving FAST Forward


By David Rubinstein
August 15, 2005 — 
Creating software is hard enough. Tweaking it to create a software product line—multiple versions of the same product for different platforms, different feature sets, different pricing and different customer branding—can quickly get out of control. Imagine if every time Toyota wanted to release one Camry with automatic transmission and another with a five-speed manual stick, or one red and another silver, the company’s engineers had to redesign the car, and draw up a new set of specifications, and that all the components, such as side-view mirror motors and the interior speakers, would have to be re-tested. I’m sure that before you could say “You’ve got it, Toyota,” the company would stop offering options.

Software product line development is no different. It grew out of research done in the 1990s to define a methodology for reusing software assets effectively and efficiently. Visionaries such as David Weiss, then of Bell Laboratories, believed that reuse in software product line development should require that a software artifact only be created when the reuse of the asset can be assured across the product line. (Most other asset reuse plans simply call for placing all software components in a repository in the hopes that someone else in the organization can find a project to reuse the asset in someday.)

The idea back then was to look at this kind of development as creating different members of a family, taking advantage of work done in previous iterations to eliminate rework, rather than creating a whole new project each time requirements change. This family-oriented approach to development, where the abstractions between versions are described, specified and then translated into deliverable software, came to be known as the FAST process.

Fast-forward to today, and the reality is that the process of developing product-line software is anything but fast. Data extrapolated from Software Engineering Institute case studies indicates that as much as 50 percent of development time is eaten up dealing with issues surrounding multiplicity. A software company called BigLever wants to change that by assigning first-class problem status to variations in a software product line.

“Developers think it’s part of the air they breathe,” said BigLever CEO Charles Krueger. “Organizations say, ‘Nah, it’s not a problem for us.’ It’s not in the forefront of most developers’ minds.”

The academic work is fine, but it’s largely theoretical in nature, with no real understanding of the pragmatic problems organizations face when doing this type of development, Krueger said. So BigLever has developed a tool—Gears—that enables organizations to automate the process of creating multiple versions of software.

Integral to Gears is the ability to produce a model that can show the points in a product line that cause variations to occur. It could be an optional feature, or a price point. At the code level, Gears introduces the notion of a variation point. Choices of code or methods are encapsulated with a set of rules at those points where a feature or function needs to vary, Krueger said.

The decisions about which features are required in each product line iteration are made at the model level, and then Gears takes those decisions, visits the variation points in the code base and instantiates the decisions to create a single product flavor.

Yet, Krueger acknowledged, this method of creating software hasn’t caught on at the developer level. “We get traction at the lead architect or vp of development [level],” he said, “someone with an overview of the different release schedules and a broad view of software development and delivery” within an organization.

While folks such as Weiss and Krueger are beating the drum for the use of these techniques—Weiss is keynoting at the Sotware Product Line Conference next month in Rennes, France, on the topic of next-generation software product line engineering—they have heard that the tools haven’t kept up with the ideology.

The tool track of the upcoming conference has solicited comments from software engineers doing this kind of work regarding their experiences, the quality and effectiveness of the tools they use and requirements for better products down the line.

By soliciting this type of input from developers, conference organizers are trying to bring the problem of creating multiple flavors of the same product out of the margins and into the spotlight. If business managers clearly understood the costs of multiplicity, they could make decisions as to whether myriad versions of a product are really necessary, or find ways to cut the amount of time spent on creating them. The SPLC tool track is an important step to move the concepts of FAST forward in a pragmatic way.

David Rubinstein is editor of SD Times.


Share this link: http://www.sdtimes.com/link/28784
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading