A Framework for Software Product Line Practice

NEWS AT SEI

Authors

Paul C. Clements

Linda M. Northrop

This library item is related to the following area(s) of work:

Software Product Lines

This article was originally published in News at SEI on: September 1, 1999

This article is excerpted from the first two chapters of A Framework for Software Product Line Practice, Version 2.0. The framework is intended to be a living document that will aid the software development and acquisition communities. Each version represents an incremental attempt to capture information about successful product line practices. This information has been gleaned from studies of organizations that have built product lines, from direct collaborations on software product lines with customer organizations, and from leading practitioners in software product lines. In the full document, available on the Web at http://www.sei.cmu.edu/plp/framework.html, Chapter 3 provides a detailed description of how product line practices could be applied to software engineering, technical management, and organizational management practice areas. “Not all of the practice areas have been defined, but our goal is to release the framework in increments to get the information out sooner and to get feedback and contributions,” writes co-author Linda Northrop, director of the Product Line Systems Program at the SEI. “Future versions will build upon the current foundation by completing still other practice area descriptions, and by describing a small number of product line scenarios involving the development, acquisition, and/or evolution of a software product line.” Northrop requests that readers provide feedback and make contributions to the framework by contacting her at lmn@sei.cmu.edu.

Introduction

Software product lines are emerging as a new and important software development paradigm. Companies are finding that the practice of building sets of related systems from common assets can yield remarkable quantitative improvements in productivity, time to market, product quality, and customer satisfaction. Organizations that acquire, as opposed to build, software systems are finding that commissioning a set of related systems as a commonly developed product line yields economies in delivery time, cost, simplified training, and streamlined acquisition. But along with the gains come risks. Although the technical issues in product lines are formidable, they are but one part of the entire picture. Organizational and management issues constitute obstacles that are at least as critical to overcome, and may in fact add more risk because they are less obvious.

Building a software product line and bringing it to market requires a blend of skillful engineering as well as both technical and organizational management. Acquiring a software product line also requires this same blend of skills to position the user organizations to effectively exploit the commonality of the incoming products, as well as to lend sound technical oversight and monitoring to the development effort. These skills are necessary to overcome the pitfalls that may bring disaster to an unsophisticated organization.

Organizations that have succeeded with product lines vary widely in

  • the nature of their products
  • their market or mission
  • their organizational structure
  • their culture and policies
  • their software process maturity
  • the maturity and extent of their legacy artifacts

Nevertheless, there are universal essential activities and practices that emerge, having to do with the ability to construct new products from a set of core assets while working under the constraints of various organizational contexts and starting points.

Every organization is different and comes to the product line approach with different goals, missions, assets, and requirements. Practices for a product line developer will be different from those for a product line acquirer, and different still for a component vendor. Appropriate practices will vary according to

  • the type of system being built
  • the depth of domain experience
  • the legacy assets on hand
  • the organizational goals
  • the maturity of artifacts and processes
  • the skill level of the personnel available
  • many other factors

There is no one correct set of practices for every organization, but this document contains practices that we have seen work successfully in practice.

What is a Software Product Line?

A software product line is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission.

Substantial economies can be achieved when the systems in a software product line are developed from a common set of core assets, in contrast to being developed one at a time in separate efforts. Using common assets, a new product is formed by taking applicable components from the asset base, tailoring them as necessary through pre-planned variation mechanisms such as parameterization, adding any new components that may be necessary, and assembling the collection under the umbrella of a common, product line-wide architecture. Building a new product (or system) becomes more a matter of generation than creation; the predominant activity is integration rather than programming.

Organizations routinely produce new releases and versions of products. Each of these new versions and releases is typically constructed using the architecture, components, test plans, etc. from the prior releases. Why are product lines different? Two elements of product lines capture the essence of the answer: the production of a related set of products and their production from a core asset base. The production itself is specified in a production plan.

Within a product line, an organization has multiple products, each of which is going through its own cycles of release and version simultaneously. Thus, the evolution of a single product must be considered within a broader context, i.e. the evolution of the product line as a whole.

The second essential aspect of the definition is the production of instances from a core asset base. Thus, we are concerned in this document with the means of production and the structure of the producing organization. How a customer might view a collection of products and interact with the producers is only of ancillary interest. It is difficult to discern from an examination of the behavior of a system (or a collection of systems) whether they were constructed from a core asset base. In fact, most customers care only about price, schedule, function, and quality. Our focus is on what it means for a producer to be producing, or for an acquirer to be acquiring, multiple products from the same asset base simultaneously.

Benefits and Costs of a Product Line

A product line epitomizes strategic reuse. Core assets extend far beyond mere code reuse. Each product in the product line can be turned out by taking advantage of analysis, design, code, testing, planning, training, and a host of other activities that have already been performed for previous products in the product line. For each reuse benefit, however, there is usually an associated cost and a caveat to achieving the benefit. The items that affect both the product line and new products as well as their benefits and costs are shown in the following table:

Asset

Benefit

Costs

Architecture, architecture specification, architecture evaluation: The architecture for the product line is the blueprint for how each product is assembled from the components in the asset base. The right architecture provides for all of the quality attributes of the products; the wrong architecture precludes achieving desired quality.

Architecture represents a significant design investment by the organization's most talented engineers. Leveraging this investment across all products in the product line means that for subsequent products, the most important design step is completed.

The architecture must support the variation inherent in the product line, which imposes an additional constraint on it.

Software components: The software components that populate the asset base form the building blocks for each product in the product line.

The design decisions, data structures, algorithms, documentation, reviews, code, and debugging effort can all be leveraged across all products in the product line.

The components must be designed to be robust and applicable across a wide range of product contexts, possibly complicating their design. Often, components must be designed to be more general without loss of performance. Variation points must be built in.

Performance modeling and analysis: For products that must meet real-time constraints, analysis must be performed to show that the system's performance will be adequate.

A new product can be fielded with high confidence that real-time and distributed-systems problems have already been worked out because the analysis and modeling can be reused from product to product. Process scheduling, network traffic loads, deadlock elimination, data consistency problems, and the like will all have been modeled and analyzed.

Reusing the analysis may impose constraints on moving processes among processors, on the creation of new processes, or on synchronization among existing processes.

Tools and processes for software development, and process for making changes: The infrastructure for turning out a software product requires a substantial investment.

Configuration control boards, configuration management tools and procedures, management processes, and the overall software development process are in place and have been used before. Tools and environments purchased for one product can be amortized across the entire product line.

The boards, tools, and procedures must be more robust to account for the differences between managing a product line and managing a single product.

People, skills, training: In a product line organization, the development staff works on the entire product line, not just a single product (although some people will work on a single product at a time).

Because of the commonality of the applications, personnel can be transferred among projects as required. Their expertise is applicable across the entire product line. Their productivity, when measured by the number of products to which their work applies, rises dramatically.

Personnel must be trained beyond general software engineering and corporate procedures to ensure that they understand and can use the assets and procedures associated with the product line. New personnel must be much more specifically trained for the product line. Training materials must be created that address the product line. As product lines mature, the skills required in an organization tend to change, away from programming and systems engineering and toward relevant domain expertise and technology forecasting. This transition must be managed.

Table 1: Costs and Benefits of Product Lines

For each of these assets, the investment cost is usually much less than the benefit. Also, most of the costs are one-time costs but the benefits accrue with each new product release. However, an organization that attempts to institute a product line without being aware of the costs is likely to abandon the product line concept before seeing it through.

In workshops on product line practice conducted by the Software Engineering Institute, workshop participants shared some of the specific quantified benefits of product line practice. These included the following:

  • being able to use one person to handle the integration and testing of a 1.5M SLOC Ada real-time safety-critical shipboard command and control system
  • increasing productivity (as measured by feature density per shipped product per engineer per unit time) six-fold over a period of three years
  • building a software system capable of running a new diesel engine over a weekend, as opposed to the full year that it used to take
  • being able to join a military simulation exercise 12 months ahead of the schedule predicted without asset reuse

These workshops have also revealed examples of the costs:

  • canceling three large projects to devote resources to building the base of core assets
  • reassigning staff who could not adjust to the product line way of doing business
  • suspending product output for a year while the new practices were put into place

Companies who bore these costs and made the successful transition to product line practice all agree that the payoff more than compensated for the effort, but these costs underscore the point that product line practice is often uncharted territory. A framework such as this one can provide the necessary insights and guidance.

Starting Versus Running a Product Line

Many of the practice areas in this framework are written from the point of view of describing an in-place product line capability. Of course, we recognize that the framework will be used to help an organization put that capability in place, and ramping up to a product line is in many ways different from running one on a day-to-day basis.

We felt it was important to describe the end or “steady state” so that readers could understand the goals. However, to address the issues of starting (rather than running) a product line shop, the reader is referred to the “Launching and Institutionalizing a Product Line” practice area in the full document.

Product Line Essential Activities

At its essence, fielding a product line involves core asset development or acquisition, and product development or acquisition using core assets. These two activities can occur in either order (new products are built from core assets, or core assets are extracted from existing products). Often, products and core assets are built in concert with each other. Core asset development has been traditionally called domain engineering. Product development from core assets is often called application engineering. The entire effort is staffed, orchestrated, tracked, and coordinated by management. The following figure illustrates this triad of essential activities. The iteration symbol at the center represents the decision processes that coordinate the activities.

Figure 1: Essential Product Line Activities

Figure 1: Essential Product Line Activities

The bi-directional arrows indicate not only that core assets are used to develop products, but that revisions to or even new core assets might, and most often do, evolve out of product development. The diagram is neutral about which part of the effort is launched first. In some contexts, already-existing products are mined for generic assets¾a requirements specification, an architecture, software components, etc.¾that are then migrated into the product line's asset base. In other cases, the core assets may be developed or procured first to produce a set of products that is merely envisioned and does not yet exist.

There is a strong feedback loop between the core assets and products. Core assets are refreshed as new products are developed. In addition, the value of the core assets is realized through the products that are developed from them. As a result, the core assets are made more generic by considering potential new products on the horizon. There is a constant need for strong, visionary management to invest resources into the development of the core assets. Management must also precipitate the cultural change to view new products in the context of the available assets. New products must either align with the existing assets, or the assets must be updated to reflect the new products that are being marketed. Both the core asset development and acquisition and the product development or acquisition are themselves iterative in nature as illustrated in the following figure. Iteration is inherent in product line activities, in turning out core assets, in turning out products, and in the coordination of the two.

Figure 2:  Iteration in Product Line Activities

Figure 2: Iteration in Product Line Activities

Core Asset Development and/or Acquisition

The goal of the core asset activity is to produce or to acquire a product production capability, which requires the following three things:

  1. <![endif]> Product space. A product space is a description of the initial products that constitute the product line. This description is typically cast in terms of the things that the products all have in common, and the ways in which they vary from one another (as opposed to an enumerated list of product names). This output is a description of the space of products that the product line is capable of including. It expresses the product line's scope, which is discussed below. Of course, the product space evolves as market conditions change, as the organization's plans change, or as new opportunities arise. Evolving the product space is the starting point for evolving the product line to keep it current.
  2. <![endif]> Core assets. Core assets are the basis for production of products in the product line. These assets almost certainly include an architecture that the products in the product line will share, as well as software components that are designed (or reengineered from existing systems) for systematic reuse across the product line. Software components also bring with them test plans, test cases, integration plans, and all manner of design documentation. Other assets, as mentioned previously, also populate this set. Commercial off-the-shelf (COTS) components, if adopted, also constitute core assets. Although every core asset will not necessarily be used in every product in the product line, all are used in enough of the products to make their coordinated development, maintenance, and evolution pay off.
  3. <![endif]> Production plan. A production plan describes how the products are produced from the core assets.

These three outputs feed the product development or acquisition activity, which turns out products that serve a particular customer or market niche. The products are built with the core assets using the production plan.

Inputs to the development and acquisition of core assets include the following:

  1. <![endif]> Product constraints: What are the commonalities and variations among the products that will constitute the product line? What are their behavioral and quality requirements? What features do the market and technology forecasts say will be beneficial in the future?
  2. <![endif]> Production constraints: What commercial, military, or company-specific standards apply to the products in the product line? Is there an underlying infrastructure that these products must be built on top of? What are the time-to-market or time-to-initial-operating-capability requirements for each? What off-the-shelf components should be used? Which legacy components could/should be reused?
  3. <![endif]> Styles, patterns, and frameworks: What are the relevant architectural building blocks that can be applied toward meeting the product and production constraints?
  4. <![endif]> Production strategy: Will the product line be built from the top down (starting with a set of core assets and spinning off products from those) or bottom up (starting with a set of products and generalizing their components to produce the product line assets)? What will the transfer pricing strategy be (i.e., how will the cost of producing the generic components be divided among the cost centers for the products)? Will generic components be produced internally or purchased on the open market? Will products be automatically generated from the assets or will they be assembled?
  5. <![endif]> Inventory of pre-existing assets: What are the software and organizational assets available at the outset of the product line effort? Are there libraries, frameworks, algorithms, tools, and components that should be utilized?

The following figure illustrates the process of developing or acquiring the core asset base and product line production capability. This activity is iterative, as suggested by the iteration symbol in the center. Again, the arrows are double-headed to suggest that there is no one-way causal relationship from inputs to outputs; rather, the inputs and outputs of this activity affect each other. For example, slightly expanding the product space may admit whole new classes of systems to examine as possible sources of legacy assets. Similarly, a production constraint (such as mandating the use of CORBA) may lead to restrictions on the architectural styles and patterns that will be considered for the product line as a whole (such as the message-passing distributed object style). This restriction, in turn, will determine which pre-existing assets are candidates for reuse or mining.

Defining the Product Space

Defining the product space is a matter of determining the scope of, or scoping the product line. The scope of the product line determines how many products the product line comprises. The scope defines the commonality that every member shares and the ways in which they vary from each other. For a product line to be successful, its scope must be carefully defined. If product members vary too widely, then the core assets will be strained beyond their ability to accommodate the variability, economies of production will be lost, and the product line will collapse into the old-style one-at-a-time product development effort. If the scope is too small, then the core assets might not be built in a generic enough fashion to accommodate future growth, and the product line will stagnate.

Further, the scope of the product line must target the right products, as determined by prevailing or predicted market factors, the nature of competing efforts, or the organization's business goals for embarking on a product line approach (such as merging a set of similar but currently independent product development projects).

Figure 3:  Core Asset Development/Acquisition

Figure 3: Core Asset Development/Acquisition

Membership in the product line can serve more than one purpose. Perhaps an organization is building or acquiring several systems that are similar to each other but do not take advantage of that similarity. They wish to merge the efforts to gain economies of scope, in which case membership is defined by an enumerated list of products. Perhaps the organization is aiming to capture or penetrate a market segment; they wish to establish a flexible, quick-response capability for launching new products in that market. In this case, membership is a function of marketing projections and is defined to include not only an initial set of products but also an abstract set of products that have not yet been built or completely defined, but the possibility is being considered or planned. In most cases, the scoping must continue after the initial scope has been defined; new market opportunities may arise, or new opportunities for strategic reuse and merging of projects may make themselves known.

Scoping the product line must account for any existing product constraints, such as a set of computing platforms on which the products must run or the set of features that the products must provide. Knowledge of similar products or systems is essential. Marketing and technology forecasts are used to determine what features the product set should make available both now and in the future.

Practice areas relevant to determining the product space include the following:

  • product line scoping
  • domain analysis
  • market analysis
  • requirements, elicitation, analysis, and management
  • technology forecasting

Producing the Core Assets

Core assets for a software product line include the system and software architectures[1] that all of the products will share, and more tangible assets such as software components and their supporting artifacts.

Architecture is a critical output of the core asset activity. The architect's responsibility includes choosing (or crafting) the architecture that will satisfy the needs of the product line in general and the individual products in particular. Equally important, the architect must communicate the architecture to those who will be building core assets (software components, supporting documentation, etc.) and those who will be building products. The architecture defines those software components that are candidates to become core assets. Conformance rules must be put in place for ensuring that the products in the product line conform to the architecture; that is, that no product begins to go its own way and depart from the overall architectural scheme. The architect is also responsible for ensuring that the architecture remains viable over the life of the product line; this responsibility may require technology forecasting.

The architect must account for the intended scope of the product line before the architect can produce an architecture to satisfy it. The commonality defined by the scope will tend to become embedded in the architecture; the variability in the scope will tend to become embedded in the tailorable or replaceable components.

To produce an architecture for a product line requires three main elements:

  1. <![endif]> Product space. This is the product space that defines the product line scope (although, in fact, the architecture may influence the product space).
  2. <![endif]> Relevant styles, patterns and frameworks. Architectures these days are seldom built from scratch; rather, they evolve from previously-applied solutions to similar problems. Architectural styles represent a current approach to re-using architectural design solutions. Architectural style catalogs exist that explain the properties of a particular style, including how well-suited each is for achieving specific quality attributes such as security or high performance [Bass 98a]. Patterns occupy the same role at a finer granularity of design. Whereas architectures prescribe how large-grained components (subsystems) interact with each other, patterns usually suggest ways to implement individual (or groups of finer-grained) components.
  3. Knowledge of legacy systems. Components may be mined from legacy systems. Such components become prime candidates for components in the core asset base.

Of course, an architecture is but one of the core assets that constitute the reusable portion of a product line. These assets include (but are not limited to) those artifacts associated with reusable software components: requirements specifications, design/interface specifications, code, test plans/cases/procedures, performance engineering models, review forms and procedures, and so forth.

Component production or acquisition requires the architecture, which defines the components that will comprise each product. The architecture will also determine which components are common across all products (or at least across subsets of the product line) and define the necessary variations among instances of those components. Also required is an inventory of pre-existing assets, including commercial off-the-shelf software, to help determine whether components are to be reengineered, purchased, or built afresh.

Finally, part of creating the core asset base is defining how that core asset base will be updated as the product line evolves, as more resources become available, as fielded products are maintained, and as technological changes or market transitions affect the product scope.

Practice areas that are relevant to producing the product line architecture, core components, and other core assets include the following:

  • architecture exploration and definition
  • architecture evaluation
  • requirements elicitation, analysis, and management
  • COTS utilization
  • make/buy/mine/outsource analysis
  • mining existing assets
  • process modeling and implementation
  • software systems integration
  • technical risk management
  • component development
  • testing
  • tool support
  • developing and implementing an acquisition strategy

Developing the Production Plan

Successful product line practice depends on a well-understood, effective set of practices and procedures for building products, as well as for building and evolving the architecture, the other core assets, and the individual products. The overall integrity of the product line construction and maintenance steps is critical. Some organizations maintain a common set of development tools or environments. The production plan takes these and other considerations into account. The production plan has to determine whether the product line will be built from the top down (starting with a set of core assets and spinning off products from those) or bottom up (starting with a set of products and generalizing their components to produce the product line assets). Moreover, each of the core assets will likely have an attached process that prescribes its tailorability and use in product development. The production plan is the overarching scheme that links these individual processes.

Another part of the production plan is the definition of metrics to measure organizational improvement as a result of the product line (or other process improvement) practices, and plan for collecting the data to feed those metrics.

Finally, a major part of the production plan is the Product Line Concept of Operations, which defines the product line organization and its responsibilities and processes.

For the production plan to be put in place, the following information is necessary: The organization's business goals for moving to a product line approach must be understood. Organizational goals must first be known so that appropriate measures can be determined, taken, and tracked to learn whether the goals are being achieved. Production constraints must be identified. What commercial-, military-, or company-specific standards apply to the products in the product line? What are the time-to-market or time-to-initial-operating-capability requirements for each? What off-the-shelf components should be used? What legacy components could or should be reused? Production constraints catalog the requirements for producing products in the product line. They include the use of enterprise standards, in-house software development environments, and requirements for how expensive it is (in terms of resources used or time it takes) to produce a product in the product line.

Practice areas relevant to producing the production plan include the following:

  • data collection, metrics, and tracking
  • process modeling and implementation
  • planning and tracking
  • configuration management
  • operations
  • technical risk management
  • developing and implementing an acquisition strategy
  • tool support
  • software system integration

Product Development or Acquisition

The activity of turning out products is the ultimate product line goal; core asset development is only one means toward that end. The product development/acquisition activity depends on the three outputs described above—the product space, the core asset list, and the production plan—plus the requirements for individual products. The following figure illustrates these relationships. Once more, the arrows are double-headed to indicate intricate relationships, and the circular arrow chain represents iteration. For example, the existence and availability of a particular product may well affect the requirements for a subsequent product. As another example, building a product that has previously unrecognized commonality with another product already in the product line will create pressure to update the core assets and provide a basis to exploit that commonality for future products.

Figure 4:  Product Developments/Acquisition

Figure 4:  Product Developments/Acquisition

A product line is, fundamentally, a set of related products. Each product is produced by a group we call the product group. There may be one product group for several products or one product group per product. If separate, they may fall under the same organizational structure or be distributed widely across an enterprise. Sometimes a product line is commissioned—that is, one organization pays another organization to develop the core assets and one or more resulting products. The commissioning organization may or may not develop products itself once the core assets are in place. If it does, and the core asset organization also develops products, then the product groups may be distributed across entirely separate enterprises.

The creation of products may have a strong effect on the product space, core assets, production plan, and even the requirements for specific products. The ability to quickly turn out a particular member of the product line, perhaps one that was not originally envisioned by the people responsible for defining the scope, will affect the product space. Each new product may have similarities with other products that can be exploited by creating new core assets. As more products enter the field, efficiencies of production may dictate new system generation procedures, causing the production plan to be updated. And, in one of the most telling effects of a product line on its client base, a customer may change his requirements to bring them in line with the product line scope to take advantage of the quick time-to-market, reliability, and lower cost available with products in the product line.

Inputs for product production include the following:

  • the requirements for any particular product, often expressed as a delta or variation from some generic product description contained in the product space. (Such a generic description is itself a core asset.)
  • the core assets
  • the production plan

Relevant practice areas include the following:

  • requirements elicitation, analysis, and management
  • architecture evaluation
  • developing and implementing an acquisition strategy
  • configuration management
  • data collection, metrics, and tracking
  • software system integration
  • technical risk management
  • testing
  • tool support

Management

Management plays a critical role in the successful fielding of a product line. Activities must be provided with resources, coordinated, and supervised. Organizational management must set in place the right organizational structure that makes sense for the enterprise, and must make sure that the organizational units receive the proper resources (e.g., well-trained personnel) in sufficient amounts. Organizational management is the authority that is responsible for the ultimate success or failure of the product line effort.

Organizational management also contributes to the core asset list, by making available for reuse those management artifacts (especially schedules and budgets) for producing products in the product line.

If the product line is being commissioned, then the acquiring organization must also have an organizational management function that holds the responsibility for the success or failure of the product line acquisition effort. This management function must bear the responsibility for meeting or failing to meet the enterprise goals of the product line itself. The responsibility of organizational management in an acquiring organization is to oversee the contractor (the developing organization), and to ensure that the delivered assets and products are suitable and of high quality. If the acquiring organization actually takes over the core assets from the developing organization, and/or it produces products from those assets, then the acquiring organization also must have an architecture, core assets, and product groups.

Another kind of management that is required for product lines is the management of the organization's external interfaces. Product lines tend to engender different relationships with an organization's customers and suppliers, and these new relationships must be introduced, nurtured, and strengthened.

One of the most important things that management must do is create an adoption plan that describes the desired state of the organization (i.e., routinely producing products in the product lines), and a strategy for achieving that state. The adoption plan should lay out phase-in activities for various organizational units, prescribe training and skill development that will be necessary, launch a measurement program to gauge progress and success, and describe the eventual organizational structure that will be adopted.

Finally, management must either act as or find and empower a product line champion. This person is a strong, visionary leader who keeps the organization squarely pointed toward the product line goals, especially when the going gets rough in the transition stages. Every successful product line we have observed has an identifiable champion; most (but not all) failed product lines that we have seen lacked one.

In the area of management, relevant practice areas include the following:

  • planning and tracking
  • achieving the right organizational structure
  • funding
  • building and communicating a business case
  • training
  • organizational risk management
  • operations
  • developing and implementing an acquisition strategy
  • customer and supplier interface management
  • launching and institutionalizing a product line
  • technology forecasting

    References

    [Bass 98a]      Bass, L.; Clements, P.; Kazman, R.; Software Architecture in Practice. Reading, Massachusetts.: Addison-Wesley Longman, Inc., 1998.

    About the Authors

    Paul Clements is a senior member of the technical staff at the Software Engineering Institute. A graduate of the University of North Carolina and the University of Texas, he is a project leader in the SEI's Product Line Systems Program. His work includes collaborating with organizations that are launching product line efforts. He is a co-creator of the Software Architecture Analysis Method (SAAM), which allows organizations to evaluate architectures for fitness of purpose. He and others are working on an extension to SAAM, which will allow analysis of quality attribute trade-offs at the architectural level. He is co-author of Software Architecture in Practice (Addison-Wesley-Longman, 1998) and more than three dozen papers and articles about software engineering.

    Linda Northrop has more than 25 years experience in the software development field as practitioner, manager, consultant, and educator. Her primary interests and contributions in the last decade have been in product line engineering, software architecture, object technology, and software engineering education. She has been with the SEI for the past five years. Prior to assuming the management of the Product Line Systems Program, she was lead for the Software Architecture Project, manager of the Education Process Project, and Chair of the SEI Education and Training Review Board. Linda is co-developer of the SEI Improvement Planning Workshop, and has taught software engineering at Carnegie Mellon University.

    Before joining the SEI, she was associated with both the United States Air Force Academy and the State University of New York as professor of computer science, and with both the Eastman Kodak Company and IBM as software engineer. As a private consultant, Linda also worked for an assortment of companies on software development projects, assessed and recommended software process. She has developed and delivered a wide variety of software engineering and object-oriented training programs and seminars.

  • Find Us Here

    Find us on Youtube  Find us on LinkedIn  Find us on twitter  Find us on Facebook

    Share This Page

    Share on Facebook  Send to your Twitter page  Save to del.ico.us  Save to LinkedIn  Digg this  Stumble this page.  Add to Technorati favorites  Save this page on your Google Home Page 

    For more information

    Contact Us

    info@sei.cmu.edu

    412-268-5800

    Help us improve

    Visitor feedback helps us continually improve our site.

    Please tell us what you
    think with this short
    (< 5 minute) survey.