A Framework for Software Product Line Practice, Version 5.0
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.
Finally, training materials and plans make first-class core assets themselves.
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).
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.
Examples of organizations creating educational and training materials specifically for software product lines include
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.
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.
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 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 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.
1 CelsiusTech found traditional classroom performance to be an unreliable predictor of post-training performance on real projects [Brownsword 1996a, p. 62].