'Software as a product line' offers the right benefits to long life-cycle military programs
StoryOctober 15, 2008
Chris A. Ciufo
General Micro Systems, Inc.
It's only been in the past five years that Eclipse and Linux evolved from novelties and "Ridiculous!" by opponents, into de facto products in defense system development and deployment. They started out as grassroots movements to fulfill a need: In the case of Eclipse, it was to create a standard framework for development tools; in the case of Linux, it was to break the control of proprietary operating system companies.
Today, you can't buy a mainstream COTS toolset that doesn't offer Eclipse plug-ins. And you'd be hard pressed not to find some Linux floating around in every military program - either during the IRAD stage or actually deployed in-system. The same will happen with "software as a product line," a methodology that governs conception, creation, testing, deployment, and code sustainment.
At September's Software Product Line Conference (SPLC ) in Ireland, a panel session chaired by BigLever Software was held, addressing the emerging trend of Software Product Line Engineering (SPLE). Simply stated, SPLE is a methodology for creating software - requirements, code, test procedures, maintenance, and all related attributes. It's easiest to understand what software as a product line is not: It's not a one-off, shrink-wrapped implementation of software intended for single use or one product. According to John Carrillo, senior director of corporate and product strategy at Telelogic (an IBM company), it "takes into account how to manage the pieces and variability over the entire life cycle". More specifically, product line implies several members of a family, including future versions, variants, and as-yet-unimagined features.
This long view of software and the entire ecosystem that goes into creating it sounds like something written in a DoD operations manual or a MIL-SPEC SCD. In fact, the SPLE definition was born in the civilian software marketplace but is so military-sounding that it reads like our magazine's tagline: "COTS and technology for the entire military life cycle." Major defense prime contractors have already noticed this in a big way. Boeing is on record as endorsing this kind of methodology.
So too has Lockheed Martin's Maritime Systems and Sensors (MS2) division. The benefit of SPLE to MS2, according to James Cezo, principal member engineering staff, is "Reuse. This allows us a way to reuse existing assets and customize them for new customers and markets". To be sure, this is how Lockheed Martin (like most prime contractors) has always done business. A good portion of its defense systems are actually features located in software that's run on program-specific hardware. Software was effectively cloned, then dropped into a new program, hardware, and sensor. From there, it was modified to meet the program's ORD.
But software as a product line emphasizes a way to write the code for intentional reuse from the very start, maximizing reuse while reducing cost and providing an orderly way to manage variations from A, to B, to C. Effectively, says Bola Rotibi, principal analyst with Macehiter Ward-Dutton, the software can be written for the "whole world" using the SPLE methodology. Her IT-focused market analysis company thinks this is early days for this way of writing software, but it's likely growing into such a groundswell of best practices that it will become commonplace and second nature within only a few years. Her firm is conducting extensive research on the trends, publishing analyst reports, and planning to advise its clients on the best ways to recoup software reuse.
Ironically, there are no formal standards adopted yet for SPLE, though Telelogic and BigLever Software are collaborating to write some. The Software Engineering Institute is also working in this area, but BigLever and Telelogic are approaching the task like IBM did with Eclipse: first developing collaborative tools that solve real problems that people can use - instead of just a set of ideological specs. According to Charlie Krueger, founder of BigLever, the next steps are 1) standards; 2) best practices; and 3) an interoperable framework.
For sure, software as a product line is still at the innovator stage; however, I'm confident that the military community will find this so compelling that they'll provide some much-needed momentum to the effort. After all, writing software for the long haul is 100 percent in-phase with our way of military life-cycle thinking.
It says so, right on the cover of this magazine.
Chris A. Ciufo Group Editorial Director, cciufo@opensystemsmedia.com
For more information from BigLever on these concepts, check out the articles in the Military Embedded Systems archive at: www.mil-embedded.com/articles/search/index.php?op=cn&max=10&q=biglever .
