DTIC ADA499051: Crosstalk: The Journal of Defense Software Engineering. Volume 22, Number 1, January 2009

2.4 MB·English

by  Defense Technical Information Center

Report Documentation Page Form Approved
OMB No. 0704-0188
Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and
maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,
including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington
VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it

does not display a currently valid OMB control number.
1. REPORT DATE 3. DATES COVERED
JAN 2009 2. REPORT TYPE 00-00-2009 to 00-00-2009
4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER
Crosstalk, The Journal of Defense Software Engineering. Volume 22,
5b. GRANT NUMBER
Number 1, January 2009
5c. PROGRAM ELEMENT NUMBER
6. AUTHOR(S) 5d. PROJECT NUMBER
5e. TASK NUMBER
5f. WORK UNIT NUMBER
7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION
517 SMXS/MXDEA,6022 Fir Avenue,Hill AFB,UT,84056-5820 REPORT NUMBER
9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)
11. SPONSOR/MONITOR’S REPORT
NUMBER(S)
12. DISTRIBUTION/AVAILABILITY STATEMENT
Approved for public release; distribution unlimited
13. SUPPLEMENTARY NOTES
14. ABSTRACT

15. SUBJECT TERMS
16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF 18. NUMBER 19a. NAME OF
ABSTRACT OF PAGES RESPONSIBLE PERSON
a. REPORT b. ABSTRACT c. THIS PAGE Same as 32
unclassified unclassified unclassified Report (SAR)
Standard Form 298 (Rev. 8-98)
Prescribed by ANSI Std Z39-18
PPoolliicciieess,,NNeewwss,,aanndd UUppddaatteess CrossTalk
4Announcing CrossTalk’sCo-Sponsor Team for 2009
OSD (AT&L) Kristen Baldwin
Meet CrossTalk’s 2009 co-sponsors.
NAVAIR Joan Johnson
5The 2009 Editorial Board
CrossTalk
309 SMXG Karl Rogers
CrossTalkpresents our valued board of article reviewers for 2009.
DHS Joe Jarzombek
EEnnggiinneeeerriinngg ffoorr PPrroodduuccttiioonn
MANAGINGDIRECTOR Brent Baxter
6Production Planning for a Software Product Line PUBLISHER Kasey Thompson
MANAGINGEDITOR Drew Brown
Learn how to formulate a production strategy,devise a method,and
compose a plan for a successful SPL approach. ASSOCIATEEDITOR Chelene Fortier-Lozancich
by Dr. Gary J. Chastek, Linda M. Northrop, and Dr. John D. McGregor PUBLISHINGCOORDINATOR Nicole Kentta
PHONE [phone]
11Experiences With Software Product Line Development E-MAIL stsc.customerservice@
hill.af.mil
This article explores one companies’move to an SPL,its SPL architecture,
CROSSTALKONLINE www.stsc.hill.af.mil/
and the lessons learned during the transition.
crosstalk
by Dr. Paul Jensen
15Software Product Management CrossTalk,The Journal of Defense Software
Engineering is co-sponsored by the Office of the
This article clarifies the role of a product manager and delineates the best Secretary of Defense (OSD) Acquisition,Technology
practices that have been successful in software product management. and Logistics (AT&L);U.S.Navy (USN);U.S.Air Force
by Dr. Christof Ebert (USAF); and the U.S. Department of Homeland
Security (DHS). OSD(AT&L) co-sponsor: Software
Engineering and System Assurance.USNco-sponsor:
SSooffttwwaarree EEnnggiinneeeerriinnggTTeecchhnnoollooggyy Naval Air Systems Command. USAF co-sponsor:
Ogden-ALC 309 SMXG.DHS co-sponsor:National
Cyber Security Division in the National Protection
20“Spending” Efficiency to Go Faster and Programs Directorate.
Every part of an organization needs to work efficiently,and this article
The USAF Software Technology Support
explores improving total system performance to avoid bottlenecks. Center (STSC) is the publisher of CrossTalk,
by Dr. Alistair Cockburn providing both editorial oversight and technical review
of the journal.CrossTalk’s mission is to encourage
24SoftwareProcess Improvement Implementation:Avoiding the engineering development of software to improve
the reliability,sustainability,and responsiveness of our
Critical Barriers
warfighting capability.
This article identifies seven critical barriers to successful software process
improvement implementation and provides guidelines to avoid each barrier.
by Dr.Mahmood Niazi
OOppeenn FFoorruumm Subscriptions: Send correspondence concerning
subscriptions and changes of address to the following
address.You may e-mail us or use the form on p.19.
28Three Encouraging Developments in Software Management
517 SMXS/MXDEA
While some software managers are falling back on forced ranking and 6022 Fir AVE
BLDG 1238
incentives to improve productivity,Derby examines the processes and
Hill AFB,UT 84056-5820
benefits of three long-term solutions.
by Esther Derby Article Submissions:We welcome articles of interest
to the defense softwarecommunity.Articles must be
approved by the CROSSTALKeditorial boardprior to
publication.Please follow the Author Guidelines,avail-
able at <www.stsc.hill.af.mil/crosstalk/xtlkguid.pdf>.
CROSSTALKdoes not pay for submissions.Published
articles remain the property of the authors and may be
submitted to other publications.Security agency releas-
es,clearances,and public affairs office approvals arethe
sole responsibility of the author and their organizations.
DDeeppaarrttmmeennttss
Reprints:Permission to reprint or post articles must
be requested from the author or the copyright hold-
3 From the Sponsor er and coordinated with CROSSTALK.
Trademarks and Endorsements:This Department of
10 Web Sites Defense (DoD) journal is an authorized publication
for members of the DoD.Contents of CROSSTALK
are not necessarily the official views of,or endorsed
14 Coming Events by,the U.S.government,the DoD,the co-sponsors,or
the STSC.All product names referenced in this issue
are trademarks of their companies.
ONTHE COVER 30 Letters to the Editor CrossTalk Online Services:See <www.stsc.hill.af.mil/
Cover Design by SSTC 2009 crosstalk>,call [phone] or e-mail <stsc.web
[email protected]>.
Kent Bingham
31
BackTalk Back Issues Available:Please phone or e-mail us to
Additional art services
see if back issues areavailable free of charge.
provided by Janna Jensen
2
CROSSTALKThe Journal ofDefense Software Engineering January 2009
From the Sponsor
Engineering for Production
oftware architecture is gaining traction within the DoD acquisition community as a
S
viable and necessary part of the acquisition and development process. Software
product lines (SPLs), when integrated through a systematic approach, are the penulti-
mate expression of sound software architectural technique.The ability to satisfy a wide
array of needs with a single,configurable product is extremely powerful.
SPLs can save taxpayer money,quickly adopt next-generation technology,and turn
a software support activity into its own program management entity. SPLs also have
the ability to cross service and national borders,eliminate vendor-proprietary,stove-piped soft-
ware solutions,and quickly adapt to new technology.
While some practitioners,developers,and managers see multiple benefits in this overarching
approach, others may feel threatened. The basic question of how to retain technical and fiscal
control of all aspects of their systems,while protecting the bottom line,is important.And can
aproject manager truly rely on this approach without threatening core capability or leaving their
technology behind?
These concerns present us practitioners with many challenges.We must build trust with pro-
gram managers,proving over and over that their needs take a back seat to no one,and their dol-
lars are well and properly spent.We must demonstrate that their trust buys them more capabil-
ities and higher quality than their original dollars could ever have afforded. We must develop
incentive/reward approaches that encourage development and use of SPLs by developers,
acquirers, and vendors. We must enable vendors to explore advanced development of imple-
mentations that propose and meet future needs,and empower them to participate in the matu-
ration and expansion of the SPL’s architecture and market.
The real issue is that every challenge must be met,and met concurrently.This means chang-
ing the acquisition cultureso that SPLs and other software production efficiencies are the expec-
tation,not the exception. In turn,the public gets the most for their hard-earned taxes, and the
warfighter gets the highest quality,best of breed software capability possible.
No single one of these challenges is insurmountable. There are examples of SPLs having
some success within the DoD, such as with the Tactical Control System, the Portable Flight
Planning System,and the Joint Mission Planning System.
The articles in this issue of CrossTalkaddress an innovative look at a wide spectrum of
possibilities to consider when focusing on SPLs.In Production Planning for a SoftwareProduct Line,
Dr. Gary J. Chastek, Linda M. Northrop, and Dr. John D. McGregor present a three-step
approach to taking an organization from their SPL goals to a comprehensive production plan.
Tobetter understand whatproject managersmight face when transitioning to an SPL approach,
read Dr. Paul Jensen’s article, Experiences With Software Product Line Development, on the experi-
ences at Overwatch Systems during their move to an SPL.Dr.Christof Ebert’s article,Software
Product Management,outlines the role of a software product manager and provides software prod-
uct management best practices thatwill help in attaining market success.
There are also examinations of other ways to improve software production and overall effec-
tiveness. In “Spending” Efficiency to Go Faster, Dr. Alistair Cockburn shows how software devel-
opment projects can improve total system results by reducing the impact of “bottlenecks.”
Through interviews with practitioners, Dr. Mahmood Niazi identifies the critical barriers that
impede Software Process Improvement programs and provides guidelines to help avoid those
barriers in his article, Software Process Improvement Implementation:Avoiding Critical Barriers. And if
your software organization needs to change course, you’ll want to read Esther Derby’s article,
Three Encouraging Developments in Software Management, which examines the benefits of evidence-
based management,Lean principles,and Agile methods.
I know you will enjoy the valuable insights that this issue of CrossTalk brings to the
challenges and possibilities of transitioning to SPLs,as well as to other software practices.
David Curry
NAVAIR Co-Sponsor
January 2009 www.stsc.hill.af.mil3
Policies,News,and Updates
Announcing ’s Co-Sponsor Team for 2009
CrossTalk
Kasey Thompson
CrossTalk
First of all, I would like to once again express sincere thanks to the 2008 CrossTalk co-sponsors. Simply put,
CrossTalk would not exist without them and their generous financial support. As Publisher, I receive countless kudos—
via e-mail and the phone—expressing appreciation for an article or issue focus that contributed to individual or organizational
success. These compliments really belong to the co-sponsors, who spark countless themes and help bring us the best authors in
defense software engineering. Likewise, it is my pleasure to introduce CrossTalk’s 2009 co-sponsor team and offer pro-
found gratitude for their continued support and commitment to this journal. I know firsthand of their vision, caring, and dedi-
cation to their industry and it is manifested through support of CrossTalk. Each co-sponsor and their organization will
assist our staff by lending us their inexhaustible experience in engineering, systems, security, acquisition, tools, processes, models,
infrastructure, people, and of course, software. Co-sponsor team members are identified in this section with a description of their
organization. Please look for their contributions each month in our From the Sponsor column, found on page 3. Their organi-
zations will also be highlighted on the back cover of each issue of CrossTalk.
Kristen Baldwin,Office of the Secretary of Joe Jarzombek,Department of Homeland
Defense – Acquisition,Technology and Logistics Security – Director of Software Assurance
Software Engineering and Systems Assurance is The DHS National Cyber Security Division
the staff agent responsible for all matters relat- serves as a focal point for software assurance
ing to DoD software engineering,systems assur- (SwA), facilitating national public-private efforts
ance, and system of systems (SoS) engineering. to promulgate best practices and methodologies
Organizational focus areas include policy, guid- that promote integrity, security, and reliability in
ance, human capital, acquisition program support, software software development and acquisition. Collaborative efforts of
acquisition management and engineering, software and systems the SwA community have produced several publicly available
engineering integration, SoS enablers and best practices, engi- online resources.For more information,see the Build Security In
neering for system assurance, and government-industry collabo- Web site <https://buildsecurityin.us-cert.gov> and the SwA
ration.See <www.acq.osd.mil/sse/ssa> for more information. Community Resources and Information Clearinghouse <https://
buildsecurityin.us-cert.gov/swa> to provide coverage of topics
relevant to the broader stakeholder community.
Joan Johnson,NAVAIR,Systems Engineering
Department – Director,Software Engineering
Want to Become a Co-Sponsor?
The Naval Air Systems Command (NAVAIR) has
three Strategic Priorities through which it pro-
duces tangible, external results for the Sailor and CCrroossssTTaallkk co-sponsors enjoy many benefits such as
the Marine. First are its People that we develop inclusion of a page-long co-sponsor’s note,placement of their
and provide the tools,infrastructure,and process- organization’s logo on the back cover for 12 issues, placement
es needed to do their work effectively. Next is Current Readiness of the Director’s name and organization on each issues’ mast-
that delivers NAVAL aviation units ready for tasking with the right head,special sponsorship references in various issues,the abil-
capability, at the right time, and the right cost. Finally is Future ity to provide authors from within their community in regard to
Capability in the delivery of new aircraft,weapons,and systems on their sponsored issue, and online placement on the CCrroossss--
time and within budget that meets Fleet needs and provides a TTaallkkWeb site.
technological edge over our adversaries. See <www.navair.navy. CCrroossssTTaallkk co-sponsors are also invited each year to
mil> for moreinformation. provide direction for future CCrroossssTTaallkk themes and feed-
back from the software defense community at large. Co-spon-
sors are also invited to participate in an annual meeting held
Karl Rogers,309 SMXG Acting Director
during the Systems and Software Technology Conference to
The 309th Software Maintenance Group at the discuss emerging needs, trends, difficulties, and opportunities
Ogden-Air Logistics Center is a recognized which CCrroossssTTaallkk may address in an effort to best serve
world leader in cradle-to-grave systems support, its readers.
encompassing hardware engineering, software CCrroossssTTaallkkwelcomes queries regarding potential spon-
engineering, systems engineering, data manage-
sorship throughout the year. For more information about
ment, consulting, and much more. The division
becoming a CCrroossssTTaallkk co-sponsor, please contact Kasey
is a Software Engineering Institute Software Capability Maturity
Thompson at [phone] or <[email protected]>.
Model® (CMM®) Integration Level 5 organization with Team
Software ProcessSM engineers. Their accreditations also include
AS 9100 and ISO 9000. See <www.mas.hill.af.mil> for more ® Capability Maturity Model and CMM are registered in the U.S.Patent and Trademark
Office by Carnegie Mellon University.
information.
SM Team SoftwareProcess areservice marks ofCarnegie Mellon University.
4
CROSSTALKThe Journal ofDefense Software Engineering January 2009
The 2009 Editorial Board
CrossTalk
Kasey Thompson
CrossTalk
CrossTalk proudly presents the 2009 CrossTalk Editorial Board. Each article submitted to CrossTalk is re-
viewed by two technical reviewers from the list below. Their insights improve the readability and usefulness of the articles that are
published in CrossTalk. Most reviewers listed have graciously offered their own time to support CrossTalk’s technical
review process. We give a very special thanks to all those participating in our 2009 CrossTalkEditorial Board.
Wayne Abba Abba Consulting
COL Ken Alford,Ph.D. Brigham Young University
Bruce Allgood Electronic Systems Center Engineering Directorate
Brent Baxter Software Technology Support Center
Jim Belford OO-ALC Engineering Directorate
Gene Bingue U.S.Navy
Lt.Col.Christopher A.Bohn,Ph.D. HQAir Force Special Operations Command
Mark Cain 309th Software Maintenance Group
Dr.Alistair Cockburn Humans and Technology
Richard Conn Retired (formerly with Microsoft)
Dr.David A.Cook The AEgis Technologies Group,Inc.
Rushby Craig 309th Software Maintenance Group
Les Dupaix Software Technology Support Center
Monika Fast 309th Software Maintenance Group
Robert W.Ferguson Software Engineering Institute
Dr.John A.“Drew”Hamilton Jr. Auburn University
Gary Hebert 538th Aircraft Sustainment Group
Tony Henderson Software Technology Support Center
Lt.Col.Brian Hermann,Ph.D. Defense Information Systems Agency
Lt.Col.Marcus W.Hervey Air Force Institute of Technology
Thayne Hill Software Technology Support Center
George Jackelen,PMP Software Consultants,Inc.
Deb Jacobs Priority Technologies,Inc.
Dr.Randall Jensen Software Technology Support Center
Alan C.Jost Raytheon – Network Centric Systems
Daniel Keth Software Technology Support Center
Paul Kimmerly U.S.Marine Corps
Theron Leishman Northrop Grumman
Glen L.Luke 309th Software Maintenance Group
Gabriel Mata Software Technology Support Center
Jim McCurley Software Engineering Institute
Paul McMahon PEM Systems
Dr.Max H.Miller Raytheon Integrated Defense Systems
Mark Nielson Software Technology Support Center
Mike Olsem Science Applications International Corporation
Glenn Palmer L-3 Communications,Inc.
Doug J.Parsons Army PEO Simulation,Training and Instrumentation
Tim Perkins 500 CBSS/GBLA (Atmospheric Early Warning System)
Gary A.Petersen Arrowpoint Solutions,Inc.
Vern Phipps SabiOso
David Putman 309th Software Maintenance Group
Kevin Richins Arrowpoint Solutions,Inc.
Gordon Sleve Robbins Gioia LLC
Larry Smith Software Technology Support Center
Elizabeth Starrett Software Technology Support Center
Tracy Stauder 309th Software Maintenance Group
COL John “Buck”Surdu,Ph.D. Army Research,Development,and Engineering Control
Dr.Will Tracz Lockheed Martin Integrated Systems and Solutions
Jim Van Buren Charles Stark Draper Laboratory
David R.Webb 309th Software Maintenance Group
Mark Woolsey Software Technology Support Center
David Zubrow Software Engineering Institute
January 2009 www.stsc.hill.af.mil5
Engineering for Production
Production Planning for a Software Product Line
Dr.Gary J.Chastek and Linda M.Northrop Dr.John D.McGregor
Software Engineering Institute Clemson University
The goal of using a software product line (SPL) approach is to predictably develop multiple software-intensive systems (products)
in an efficient, timely, and cost-effective manner that takes economic advantage of the features common to the products. Achieving
this goal requires more than reusable (core) assets. It requires production planning that formulates a production strategy, devises
a production method, and composes a production plan that is followed for each product. We present a three-step approach to pro-
duction planning that guides an organization from the goals for the SPL to a comprehensive production plan.
he benefits of an effective production reused across products. Other core assets do because of how the core assets are
T
system are well understood. For include requirements, architecture, de- designed. Production planning provides
example, in manufacturing, the Toyota signs, documentation, budgets and sched- the opportunity for technical planning on
Production System (TPS) produces high- ules, tools, process definitions, perfor- how the core assets should be designed to
quality, low-cost automobiles and is wide- mance models,testing artifacts,and much facilitate efficient product variation and
ly credited with providing Toyota with a more. integration [4]. The production plan ulti-
significant competitive advantage. The The organizations that we have stud- mately describes how to use the core
TPS is based on a set of development ied1 have achieved remarkable benefits that assets to build products.
rules [1], two of which are of particular are aligned with commonly held business These described TPS rules illustrate
relevance to SPLs: goals,including: some of the implications of the SPL def-
• Rule 1 – How People Work. Tasks • Large-scale productivity gains. inition for product production.In a prod-
are rigorously specified yet the overall • Decreased time-to-market. uct line production system,the prescribed
processes are highly flexible. • Increased product quality. way is intended to rigorously specify the
• Rule 2 – How People Connect.Cus- • Decreased product risk. roles in the organization. This specifica-
tomers and suppliers are connected di- • Increased market agility. tion is actually broken into pieces that cor-
rectly and unambiguously,with defects • Increased customer satisfaction. respond to the individual core assets used
and schedules handled rapidly. • More efficient use of human re- to build the products.Each asset is accom-
Just as producing automobiles is sources. panied by a description of how to use the
Toyota’s focus, producing software-inten- • The ability to effect mass customiza- asset in product building. This attached
sive products is the main business of an tion. process is used to populate portions of
SPL organization.An SPL is a set of soft- • The ability to maintain market pres- the production process.As different prod-
ware-intensive systems sharing a common, ence. ucts are defined and different assets are
managed set of features that satisfy the • The ability to sustain unprecedented selected for inclusion in the products,dif-
specific needs of a particular market seg- growth. ferent attached processes are included in
ment or mission and that are developed These benefits give organizations a the production plan and how people work is
from a common set of core assets in a competitive advantage and are derived changed.
prescribed way [2]. This definition is con- from the reuse of the core assets in a In an SPL organization, the core asset
sistent with the one traditionally given for strategic and prescribed way. and product developers are connected by
any product line.But it adds more,putting Implied by the definition of an SPL a delivery process in which core assets are
constraints on the way in which the sys- are two coordinated roles in product pro- made available to the product developers.
tems in an SPL are developed. Why? duction. The core asset developer creates This is developed from a common set of
Because substantial production economies reusable artifacts that will be used to build core assets from the SPL definition. An
can be achieved when the systems in an multiple products. The product developer explicit feedback mechanism allows the
SPL are developed from a common set of assembles products from these core product developers to inform the core
assets in a prescribed way, in contrast to assets—not arbitrarily, but in a prescribed asset developers about any defects or to
being developed separately, from scratch, way.In [3],the authors surveyed a number request desired enhancements. This is a
or in an arbitrary fashion. It is exactly of organizations and found that these two realization of Rule 2 of the TPS.
these production economies that make the roles are often embodied in separate In the following sections, we provide
SPL approach succeed in ways that earlier teams that are not co-located. The arti- an overview of our approach to produc-
forms of software reuse failed. facts produced during production plan- tion planning, list several documented
Building a new product (system) ning are intended to coordinate the inter- production planning experiences in both
becomes more a matter of assembly or actions of these two roles. industry and the DoD,and describe a pro-
generation than one of creation; the pre- The core assets are designed to be duction planning workshop we have used
dominant activity is integration rather reused, and reused in particular ways that with industrial and DoD customers. Due
than programming.For each SPL,there is accommodate the variation that is inher- to the size of the artifacts, readers should
a production plan that specifies the exact ent in separate products. Although the examine the production planning artifacts
product-building approach. And software product developers construct the prod- of the Software Engineering Institute’s
components are not the only thing being ucts,they are constrained in what they can (SEI’s) Pedagogical Product Line [5].This
6
CROSSTALKThe Journal ofDefense Software Engineering January 2009
Production Planning for a Software Product Line
example SPL provides an extensive set of
Source of Stimulus Who or what is initiating product production.
product line artifacts in addition to the
production plan. Stimulus The event or action that initiates product development.
Approach Environment The state of the production environment of the product line at
Our production planning technique the time of this scenario (e.g., all core assets are completed
involves three activities:context, prerequi- and available for use).
sites for planning, and planning activities
Artifact The production system artifact can be a product or a core
[6]. Each activity produces an artifact that
asset.
plays a specific role in the production sys-
tem. We will describe the context in which Response How the production system responds to the request to
the activities are conducted,the prerequisite produce a specific product. For example, how long will it take
actions that must occur prior to production to produce this product?
planning, and then detail each of the three
planning activities. Response Measure The measure may be calendar days from purchase contract
to deployment, cost in dollars or days of effort, etc.
Context
Production planning occurs within the con-
text of the SPL,the product line organiza- Table 1:Production Scenario
tion, and the narrower context defined by statement of how the organization expects duction strategy.
the product and production constraints. to achieve the goals of the product line. The boxPPesoo rtteeepnnrettsiiaaenll t the market forces
These constraints are identified during early The breadth and longevity of a product and the arEEronnwttrrsaa nnrettpssresent threats and
product line analysis activities. line requires a goal-driven approach to power. For example, potential entrants
Activities such as scoping and market keep the organization focused. The tech- into a market represent a threat while buy-

analysis identify production constraints. nique for defining the production strategy ers use their bargaining power to obtain
The structure of the organization can also begins with the business goals of the prod- discounts or improveTTdhh prreeroaadttusscts. Here we
impose constraints. The relatioSnosuhrcipe sof Suticmt ulilnuse orgWahnoiz oart wiohna.t is initiating product productpiorno. v ide a brief description of each force:
among the customers,program officSetism,aunluds The STEhIe eWvehnatt o rt ao ctBiouni ltdhatp inaitttiaetrens p[r2o]duct• devPelootpemnetniat. l Entrants.How can we raise
contractors constrain production. These focuses on defining which products are the cost to others of entering the mar-
constraints include required divisEionnvsir oinnmenpta rt of thTeh ep srtoadteu ocft thlien per,oditusc tsiocno epnev,iraonnmdent of thkee tp rboyd utchIIt nnelin ddemuu aessta ttnrrsyy we use to produce
process responsibilities brought on by the developingth ea tibmues oinSSf ethuusisspp sppccaellsiineeea rrrtssioh a(et .gj.u, satlil fcieosre assetst haere p croCComdoopulmmecttesppd?ee Ittniitt ooanrrss SPL context, this BBuuyyeerrss
geographic distribution of personnel and the investmanedn at vainila bthlee f opr ruosde)u. ct lineBB. aaTrrhggeaaiinniinnggu sually results in a strategBBicaa arrcggtiaaoiinnn iitnnogg
legal divisions between the programA rotiffaficcte business caTshee ipsr opdruecdtiiocna tseyds teomn athrtiefa octr gcaaPPnn ioob-eww aee prrrodauuctto omr aa tceo raes much as possibPPle,ooawwmeeorrr-
and the contractor. zation’s buassisneets. s goals and identifies the tizing automation costs over the set of
Required properties of the products factors that are critical to the success of products. This in turn increases the
impose constraints. For example, thRee snpeoendse the producHt olwin teh.e production system responds to the creoqsute sotf to entry fTTorhh rrpeeoaatettnsstial competi-
produce a specific product. For example, how long will it take
for DO-178B certification imposes the We use Porter’s Five Forces Model [7], tors.A flexible production method can
to produce this product?
requirement that the tools and processes illustrated in Figure 1,and the critical fac- also respond to the needs of cus-
used to produce the core assets anRd epsrpoodn-se Mtoerass uoruet puTt hfer ommea aspurpel imcaatyi obne coafletnhdea rW dahyast from putrochmaesres c ofanstrtaecrt than product producers
ucts be approved for this level of quality. to Build patott deernpl,oytmo eindt,e cnotsifty in tdhoell asrstr oart edgaiycs of effowrt,h eotc h. ave not yet entered the market.
SSuubbssttiittuutteess
actions that will be the basis of the pro- • Substitutes.How can we differentiate
Prerequisites for Planning
Figure 1:Porter’s Five Forces Model
Production planning begins early in the
planning for the product line but it can only
PPootteennttiiaall
be completed when certain prerequisites
EEnnttrraannttss
have been met. The requirements for the
Production Plan
production system are captured in a set of
production scenarios. A production sce-
Product Constraints
nario takes the form shown in Table 1. TThhrreeaattss Production Process
Production + + +
Sufficient production scenarios are created Production Constraints
to cover the various ways in which products Method +
will be produced. Production Strategy Project Details
IInndduussttrryy
SSuupppplliieerrss BBuuyyeerrss
Planning Activities CCoommppeettiittoorrss
The planning activities form a logical BBaarrggaaiinniinngg BBaarrggaaiinniinngg
sequence that move planners from deter- PPoowweerr PPoowweerr
mining the goals of the production system
to identifying the specifics of the produc- TThhrreeaattss
tion schedule for each product.
Defining the Production
Strategy
SSuubbssttiittuutteess

The production strategy is a high-level

January 2009 www.stsc.hill.af.mil 7

Production Plan
Product Constraints
Production Process
Production + + +
Production Constraints
Method +
Production Strategy Project Details
Engineering for Production
our product from the substitutes build the product line,but it must encom- include processes for specifying products
through the means of production? pass the goals of the customer and pro- and for product deployment. In some
The economies of scale of the prod- gram office. product line organizations,the production
uct line support a strategic action to method may also include management
Engineering the Production
lower prices while the economies of activities related to estimating and sched-
scope support an increase in features Method uling production.
to resolve the threat of substitutes. The production method [9] bridges the gap Development of the production
• Buyers. How can we better respond between the production strategy and pro- method usually begins either with the sin-
to buyers’ requests through attributes duction plan to provide a comprehensive gle system development method that is in
of the production process? One strat- view of the entire SPL development.While use as the product line organization is
egy action is to adopt short iterations the production method is intended to formed or with a standard software devel-
that provide enhanced functionality describe how to produce a product, it also opment method. Method engineering
quickly. Another is to provide buyers defines constraints on how the core asset techniques [10] are used to elaborate that
with access to the status of defect fixes developers can design their assets. The method into the full production method
so they can track those that are impor- method becomes the vehicle for coordina- that addresses the scale and variability of
Sourcet aonf St ttiom uthluesm . Who or what is initiating product ptiroondu cbteiotnw. e en the core asset and product the product line.
• Suppliers. How can we lower the development teams.
Stimulus The event or action that initiates product development. Developing the Production Plan
prices we pay suppliers by the produc-
Environtimoenn tt echniqueTsh ew seta teu soef ?th eT phroed uucsteio no efnviron“meTnth ofe th ep prroodudctu lincet aito n method The production plan (shown in Figure 2) is
open source stoheft twimaer eo f itsh iso sncee nsatrriaot (eeg.gic., all core assets are completed the product builder’s guide. It prescribes
action.Anothearn dis a tvoa itlaabklee faodr vuasne)t.a ge of how products are produced from the core
bridges the gap between
the economies of scale of the product assets.It includes a process to be used for
Artifact The production system artifact can be a product or a core
line to negotiaatses elot.w er license fees for the production strategy building products (the production process)
specific components. and lays out the project details to enable
Res•ponIsned ustry ComHopwe tthiteo prrso.duHctoiown scyasnte mw erespondsa ton thde rpeqrueosdt tou ction plan to execution and management of the process.
produce a specific product. For example, how long will it take
gain advantage over the competition The production plan is structured around
to produce this product?
by different choices of production provide a comprehensive the product building process defined in the
Respontesceh Mneiqasuuerse? OThnee msetarsautreeg mica ya bcet icoanle nidsar days from purchase contract production method. Just like a product
building multiptol ed evpelorsyimoennst , ocfospt irno ddoullcatrss or days of epffolrat, entc . of the entire specification,the production plan includes
simultaneously. By establishing collab- variation points;these include the variation
orativ e production arrangements with SPL development.” points in the product specification as well
suppliers where we obtain early copies as points related to the potential variations
of future versions of their compo- PPootteennttiiaall in the production system.
nents, our products can be released EEnnttTrraahnnett mssethod encompasses the process- The production plan gives a step-by-step
much sooner after the release of the es,tools,and models needed to complete- description of how to build a product.The
new components. ly describe a development effort. For initial description is high-level,but it is par-
The strategy that results from this example, the production method, in ticularized as choices are made at variation
activity links the business goals of the responsTTe hhtorree taahettss production strategy,might points and core assets are selected to imple-
product line to a first,high-level statement adopt an Agile process model for pro- ment those choices. Each core asset is
about how products will be produced.The ductbuilding teams. The method would accompanied by an attached process. The
strategy provides an essential input into describe the roles and tasks for customers attached process for an asset is the user’s
IInndduussttrryy
the developmSSuuenpptpp olliifeerrtsshe production meth- or customer surrogates and deveBBlouupyymeeerrnsst guide for that asset. The attached process
CCoommppeettiittoorrss
od. A detailed description of production team members.The method would define solves the common software reuse problem
BBaarrggaaiinniinngg BBaarrggaaiinniinngg
strategy development can be found in [8]. work products such as user stories, unit of the learning curve for a new asset. The
PPoowweerr PPoowweerr
The DoD context adds a layer to the tests, and a software architecture, and attached process for a core asset gives a
usual customer/supplier relationship. The assigns responsibility for their creation to step-by-step process for using the asset and
TThhrreeaattss
customer and program office each have specific roles. should provide sufficiently detailed infor-
goals for the product line and some of The scope of the method varies from mation to combat any difficulties in under-
these goals can be achieved through the one organization to another. The method standing how the asset works.The attached
appropriate production techniques. The incorporates the processes and associated process for a selected asset is added into the
production strategy is ultimately the SStuuobbosslstt iittauuntteed ssmodels for building products, p roduct’s production process when that
responsibility of the contractor who will but the method may be expanded to asset is selected to be used to build the prod-
uct. By making core asset selections in the
Figure 2:Production Plan prescribed order and adding the attached
process for each asset as it is selected,a fully
instantiated plan is developed just in time to
Production Plan
guide the product developer [11,12].
Product Constraints
Production Process
Production + + + Production Planning Experiences
Production Constraints
Method + Our experience has shown the value of
Production Strategy Project Details production planning:
• A survey was conducted of SPL Hall
of Fame members to capture their
experiences with production planning.
8
CROSSTALKThe Journal ofDefense Software Engineering January 2009
Production Planning for a Software Product Line
The full results of that survey are This sequence of successive refinements sity.Technical Report to appear 2009.
available in [3]. The most important ensures that the production plan contains 10.Henderson-Sellers, Brian. “Method
result (for the purposes of this article) sufficient detail for core asset and product Engineering for OO Systems Devel-
is that production planning was found builders to accomplish their tasks pre- opment.” Communications of the
to have a positive effect on the success dictably and efficiently. The traceability ACM 46 (Oct. 2003): 73-78. <http://
of the product line.Organizations that provided by this approach ensures that portal.acm.org/citation.cfm?coll=GU
did not sufficiently focus on produc- changes to product line goals or the dis- IDE&dl=GUIDE&id=944242>.
tion planning wished they had. covery of additional production con- 11.Chastek,Gary,and John D.McGregor.
Cummins, Inc. included more robust straints can be propagated through the “Guidelines for Developing a Product
architecture and production planning artifacts promptly.
Line Production Plan.” SEI, Carnegie
practices in its second generation A production system does not come
Mellon University. Technical Report
product line [13]. free with reusable components, services,
CMU/SEI-2002-TR-006. June 2002
• Paul Jensen describes Overwatch’s or even a product line architecture.A pro-
<www.sei.cmu.edu/pub/documents/
experience with production planning in duction plan is necessary.Developing and
02.reports/pdf/02tr006.pdf>.
a DoD context [14]. This experience maintaining an effective and efficient pro-
12.Chastek, Gary, Paul Donohoe, and
illustrated the need to plan for produc- duction system is critical to the success of
u John D. McGregor. “Product Line
tion as early as possible.An attempt to a product line.
Production Planning for the Home
change tools in the midst of core asset
References Integration System Example.” SEI,
development was difficult and resulted
Carnegie Mellon University. Technical
in inadequate tool support. 1. TPS. “Toyota Production System
Note CMU/ SEI-2002-TN-029. Sept.
• In [15],the authors describe a user guide Terms.” Toyota Motor Manufacturing
2002 <www.sei.cmu.edu/pub/docu
that is essentially a production plan at Kentucky, Inc. 2008 <www.toyota
ments/02.reports/pdf/02tn029.pdf>.
Rolls Royce. The user’s guide, for the georgetown.com/terms.asp>.
core asset base, describes how to use 2. Clements, Paul, and Linda Northrop. 13.Dager, Jim. Nomination presentation
the core assets to build products. It Software Product Lines: Practices and at Product Line Hall of Fame Session.
was built as a core asset and delivered Patterns. Boston: Addison-Wesley 12th Annual Software Product Line
with the core asset base. Publishers,2002. Conference. Limerick, Ireland, Sept.
• In [16], the authors provide a produc- 3. Chastek, Gary, Patrick Donohoe, and 2008.
tion planning technique that relies on John D.McGregor.“A Study of Prod- 14.Jensen, Paul. Experiences With
the feature model. Production plan- uct Production in Software Product Product Line Development of Multi-
ning was decomposed into planning Lines.” SEI, Carnegie Mellon Univer- Discipline Analysis Software at Over-
about how to include each feature in a sity. Technical Note CMU/SEI-2004- watch Textron Systems. Proc. of the
product.By maintaining this traceabili- TN-012. Mar. 2004 <www.sei.cmu. 11th Annual Software Product Line
ty, the product line production plan is edu/pub/documents/04.reports/ Conference.Kyoto,Japan,2007.
more easily transformed into the prod- pdf/04tn012.pdf>. 15.Habli, Ibrahim, Tim Kelly, and Ian
uct-specific production plan. As fea- 4. Northrop, Linda, and Paul Clements. Hopkins.Challenges of Establishing a
tures are selected during product defin- “A Framework for Software Product Software Product Line for an Aero-
ition,the production plan is composed. Line Practice, Ver. 5.0.” SEI, Carnegie space Engine Monitoring System.
The SEI developed a Production Mellon University. 2007 <www.sei. Proc. of the 11th Annual Software
Planning Workshop [17] in response to cmu.edu/productlines/framework. Product Line Conference. Kyoto,
requests for assistance on initiating a pro- html>.
Japan,2007.
duction planning capability. The work- 5. SEI. “Arcade Game Maker – Pedago-
16.Lee, Jaejoon, K.C. Kang, and Sajoong
shop is an intensive planning session that gical Product Line.” SEI, Carnegie
Kim. A Feature-Based Approach to
is intended to expedite an organization’s Mellon University. 2008 <www.sei.
Product Line Production Planning.
planning, providing a two-day introduc- cmu.edu/productlines/ppl/>.
Proc. of the Third Software Product
tion to the production planning process. 6. Chastek, Gary, Patrick Donohoe, and
Line Conference.Boston,2004:183-196.
Our experience with the introductory John D. McGregor. A Production
17.SEI. Software Product Lines. “Pro-
workshop has shown us that these two System for Software Product Lines.
duction Plans for Software Production
days are very useful in accelerating the Proc. of the 11th Annual Software
Lines.” 2008 <www.sei.cmu.edu/prod
production planning exercise. Product Line Conference. Kyoto,
uctlines/production_plan.html>.
Japan,2007:117-128.
Summary
7. Porter, Michael E. “Competitive Ad- Note
A robust production planning tech- vantage: Creating and Sustaining Su-
1. The SEI has published several detailed
nique—such as the one we have de- perior Performance.”Free Press,1998.
case studies of successful product line
scribed—produces a production plan that 8. Chastek,Gary,and John D.McGregor.
is actionable and evolvable.The organiza- “Formulation of a Production Strate- organizations and the benefits they
tion extracts production goals from the gy for a Software Product Line.” SEI, have enjoyed. You can find these case
overall product line goals, creates a pro- Carnegie Mellon University. Technical studies in [2] and on the Web at
duction strategy that resolves the compet- Report CMU/SEI-2008-TN-023. <www.sei.cmu.edu/productlines/spl_
itive forces through the means of produc- 9. Chastek, Gary, Patrick Donohoe, and case_studies.html>. You can also find
tion, elaborates the strategy into a set of John D. McGregor. “Applying Goal- references to product line efforts at
mutually consistent processes, tools, and Driven Method Engineering to Pro- <www.sei.cmu.edu/productlines/
models, and finally operationalizes the duct Production in a Software Product plp_hof.html> and <www.sei.cmu.
method in a detailed production plan. Line.” SEI, Carnegie Mellon Univer- edu/productlines/plp_catalog.html>.
January 2009 www.stsc.hill.af.mil 9