A Framework for Software Product Line Practice, Version 5.0

Training

Training is a core activity of any software development organization.
The purpose of it is to provide the skills and knowledge needed to perform
software management and technical roles. A training program involves
identifying the training needed by the organization and the entities within it
and then developing or procuring that training. Thus, as in many other practice
areas, there is an initiation or planning phase followed by an execution phase.
Training can be informal through mentoring or other on-the-job mechanisms or
formal through classroom instruction or video sessions. Adequate resources and
funding are needed if the training is to be effective and should be documented
in a training plan.

Aspects Peculiar to Product Lines

Training is an element of both the initial product line adoption and the
longer term product line evolution. This practice area focuses on the training
practices that need to be instituted by management to ensure that the
organizational units responsible for creating, fielding, and evolving the
product line have properly trained personnel.

Management's support of training includes

committing to an appropriate training plan

ensuring that the plan is implemented and that the training is
monitored for effectiveness

ensuring that the product line training is consistent with and
supportive of the overall product line adoption process or any
process-improvement efforts

An organization's approach to training in product lines must focus on
establishing a core competence in the creation and usage of core assets. Thus,
it is not enough, for example, to send people to a course in object-oriented
design or software reuse and then expect them to build product lines. All
training must occur within the context of the organization's adoption plan for
product line practices and address the skills needed by people for the new
roles they will assume within the organization as it moves away from the
single-system, project-centered view to the multi-system, product line view.

Product line training must be viewed as a strategic activity that should
be planned accordingly. A training plan should align with the overall product
line adoption plan and tie training goals to the business goals of the
organization. For example, if a business goal is to reduce the time to market
of products in the product line, any training in software reuse practices must
emphasize the creation of specifically targeted reusable assets rather than an
opportunistic reuse library. In the product line context, reuse is a means to
an end, not an end in itself, and reuse training must focus on designing for
commonality and controlling variability rather than on creating class
libraries.

The appropriate product line training also depends on the current state
and experience base of the organization. For example, an organization already
fairly sophisticated about architecture and architecture-based design will have
less of a need for training in those areas.

Application to Core Asset Development

Training for core asset development is primarily training in the
software engineering practice areas. Any such training should be preceded by an
introductory course that explains product line concepts in general and the
organization's planned product lines in particular. The specific training
associated with each software engineering practice (for example, training in a
specific domain-analysis method or training in architecture definition) must be
tied to the goal of creating a core asset base to support a product line.
Similarly, training on the tools for representing and documenting the outputs
of a domain analysis or a software architecture definition effort should focus
on complementing the analysis and design skills of the core asset creators
rather than their coding skills.

If externally available software (for example, COTS components, Web
services, or open source software) is to be acquired as part of a core asset
strategy, the training should focus primarily on how to choose and integrate
software that makes sense for the product line. Similarly, if legacy software
is to be repackaged as a core asset for the product line, the training should
focus primarily on how to analyze its reusability rather than on how to "wrap"
it for inclusion in a current product.

Application to Product Development

Product development training is the complement of core asset development
training; its primary goal is to ensure that product developers know how to
create products in the product line from the core asset base. It, too, should
be preceded by an introductory course in software product lines with a
particular focus on the organization's product line. The emphasis is on the
effective use and reuse of core assets such as a domain model and architecture
following the dictates of a production plan. The architecture for a single
system, for example, is derived from (if not identical to) the product line
architecture and not built from scratch; the training must emphasize the need
to follow the production plan that was established for the product line. One of
the major "themes" of the product development training should be that core
asset usage is strategic in nature and that core assets that appear to be less
than optimal for a particular product may be an optimal element of the
overall product line strategy.

Another important aspect of product development training is getting
people to follow the process defined for using core assets and correcting
problems. For example, problems with core assets should always be referred to
the core asset creators rather than the product developers. That way local
"fixes" proposed for a particular customer can be assessed against the
long-term needs of the product line (for example, the configuration management
of core assets or control of variations).

Example Practices

Develop a training plan: The most important elements of
product line training are the identification of training needs and the creation
of a strategic training plan to meet those needs. This plan must identify the
current skill gaps and determine the training requirements needed to fill them.
It must also address how those skills will be established and maintained in the
teams that build product lines: in-house courses, external courses, on-the-job
training, mentoring, and so forth. Creating and implementing such a training
plan is a key element of the cultural change needed for product line adoption.

Train people for the transition to a product line
approach: Training to prepare people for the transition to product
lines includes such elements as

an introductory course on product line concepts and terminology

an overview of the organization's current and planned product lines

an overview of the proposed development process, including changes in
existing processes, organizational structure, and roles

a presentation of the concept of operations (CONOPS) for the product
line to explain the goal state of the organization and the role of training in
achieving that state

training in specific product line practices or concepts. Here,
software architecture deserves a special mention as a concept whose role and
use should be emphasized, especially among the product builders. A
familiarization course on the particular architecture being used as the
foundation of the product line (including the ways it supports variability) is
often most useful.

training in the production techniques that automate the production of
products from core assets, as described in the production plan

training in supporting technologies (such as tools for representing
and documenting the core assets)

Note that the first four items above are really about education rather
than training and that even experienced practitioners may need to be reeducated
about how their skills and roles apply in the product line context.

the Software Engineering Institute (SEI), which offers a software
product line curriculum with courses covering introductory topics, product line
adoption, product line development, and diagnosing an organization's readiness
to adopt or ability to succeed with a product line approach
(www.sei.cmu.edu/productlines/spl_curriculum.html)

the Fraunhofer Institute for Experimental Software Engineering
(IESE), which offers a set of services, based on the IESE Product Line Software
Engineering (PuLSE) method, for setting up and running a product line
organization (www.iese.fraunhofer.de/PuLSE/)

Training needs to be tailored to the specific processes and skills of
the organization and to the product line adoption plan. Establishing a core
competence in core asset creation and usage means understanding and applying
new concepts, not getting high marks in a training class.1 Any training in, for example, domain analysis,
software architecture, object-oriented technology, model-driven development,
design patterns and frameworks, specific programming languages, or specific
development environments must be planned and implemented as part of the product
line strategy and not as ends in themselves.

Implement the training plan: Implementing the training
plan includes making decisions about the most effective way to deliver the
training: classroom training, hands-on training, tutorials, workshops, pilot
projects, mentoring, and so forth. An important decision in this regard is the
scope of any planned in-house training and mentoring capability and the extent
to which external courses and instructors will be used. In general,
implementing the product line training plan involves some or all of the
following choices:

augmenting current training activities to support product lines

replacing existing training activities

adding new training activities

To ensure that the training meets the goals established for it in the
training plan, it must be monitored and measured. Any lessons learned about the
timeliness, relevance, level of difficulty, deficiencies, and effectiveness of
the training should be collected from the trainers and trainees and
incorporated into future training.

Practice Risks

An inadequate training program results in a staff that is ill-prepared
to perform their jobs efficiently and effectively in the product line
organization. Component developers, for example, who are not trained to create
truly reusable assets will probably not do so and will consequently undermine
the quality of the core assets.

Inadequate training can result from

a sink-or-swim approach: In this approach, the
organization assigns ill-prepared people to perform product line tasks and has
to scramble later to fill the educational gap.

inappropriate focus: Too much time spent training
people on the tools, programming language, or development environment without
the requisite product technology foundation will only succeed in helping to
automate the wrong operation.

a lack of strategic investment: Sacrificing vital
training in order to meet current customer schedules and deliverables will, in
the long run, result in staff who are ill-equipped to handle the needs of the
product line operation.

a lack of the big picture: If insufficient time is
spent on communicating the product line vision and on building an awareness and
acceptance of the product line, the rest of the product line training will fail
to have a meaningful context.

inadequate training resources: A lack of the
necessary instructors, funding, classroom facilities, hardware, or software can
derail any training plan.

a lack of coordination: If the training plan is not
coordinated with the overall product line adoption plan or process-improvement
plan, the staff will probably become frustrated and overwhelmed.

a lack of training assessment: If the effectiveness
of the training is not monitored or measured, there will be no basis on which
to predict the results or improve the training.

Further Reading

[Brownsword 1996a]
Brownsword and Clements describe how CelsiusTech approached the issue of
skills and knowledge, beginning with the formative years of its ShipSystem 2000
software product line that was launched in early 1986.

[Goldberg 1995a] Goldberg
and Rubin devote two full chapters to training in object-oriented technology.
Chapter 18 describes what a training plan is and discusses it in terms of both
training and educating the entire team. The discussion covers subject areas,
proficiency levels, and training formats (for example, classroom, mentoring,
and self-study). Chapter 19 describes how to set up a training plan and
provides several examples of real training projects.

[Lim 1998a] Lim devotes Chapter
16 to staffing software reuse projects. It includes an identification of the
key roles and responsibilities for implementing reuse and a description of the
elements of a core curriculum in reuse.