Chapter 22 Product Line Engineering

1. Chapter 22Product Line Engineering Week 1 CIS 673

2. Product Line Engineering • What is Software Engineering? • What is Software Reuse? • Why Reuse Software? • Why Not Reuse Software? • What is Product Line Engineering?

3. Software Engineering • Engineering Discipline of Software specification, development, evolution, maintenance, operation. • Evolved from the mid fifties. • Constant state of crisis. • SW products: increasingly large, increasingly complex, increasingly critical.

4. Phases Feasibility Analysis Req Specs Design Product Design Detailed design Programming Testing Operation and maintenance Sequential, chronological. Reinventing the wheel, over and over Traditional SE Lifecycle

5. What is Software Reuse Set of systematic, organization-wide measures that are taken to streamline the production and usage of reusable software components in application development.

6. Why Reuse Software Reuse: an Intrinsic part of any engineering discipline. • Lower Costs. • Better quality. • Shorter Time to Market. • Less process risk.

7. Why Not Reuse Software • SW components too information rich. • Little chance of a match. • Great variability in user needs. • Not Invented Here syndrome. • Architectural mismatches: there is more to a component than function. ….. Failure of Reuse as a Broadly Applicable mechanism. Huge reuse libraries went idle…

8. Why Not Reuse Software, II SW products have no standard architecture. Analogy with automobiles: standard architectures Cottage industry of parts manufacturers New cars made up, in large parts (98%), of reusable parts In SW:

9. Product Line Engineering A Streamlined Form of Software Reuse • Domain specific • Centered on an Architecture • Captures Domain Knowledge, Assumptions, wisdom, etc

10. Two Phases • Domain Engineering: Domain Analysis, domain scoping, domain architecture, analysis of commonality and variability, design for reuse, etc. • Application Engineering: Developing applications from DE deliverables.

11. Team Organization

12. 1.2.5 The Experience Factory Environment Characteristics Goals, Processes, Tools, Products, Resource Models, Defect Models, Data, Lessons Learned Project Analysis • Definition Characterize Set Goals Choose Process Project Support Package Execute Plan Experience Base Generalize Tailor Formalize Execute Process Analyze PROJECT ORGANIZATION EXPERIENCE FACTORY

13. Experience Factory: A Special Form of Team Producer • Reusable Assets • Among the forms of assets, we mention: equations between process or product parameters; histograms or pie charts of project data; ranges of normal project data; lessons learned from past development projects

14. Experience Factory: A Special Form of Team Producer • Packaging • product packages, which are abstractions of lifecycle products (programs, designs, architectures, specifications, test data) • process packages,which are abstractions of lifecycle processes (process models, methods, test data generation method) • relationship packages, which abstract relations between various product parameters and process parameters (cost models, defect models, reliability models) • tool packages, which assist the generation or analysis of software products and processes (code generators, planning and cost estimation tools, static analyzers, regression testers).

15. Experience Factory: A Special Form of Team Producer • Separation of Producer and Consumer Functions • Unlike all other organizations we have discussed so far, the experience factory organization has no cognizance of the multitude of project teams. Also, the project organization is not expected to make any direct contribution to the corporate experience base.

16. Product Line Engineering (PLE) • Product-line engineering is a specialized form of • reuse that promises Productivity, Quality and • shorter time to market in developing similar • products in the same domain. • PLE is a streamlined integration of several aspects of softwarereuse. • PLE embodies domain & application engineering • phases that are scoped by family of products.

17. Product Line Engineering (PLE) - contd. • The basic technical means to create a product line include: • Domain Analysis • Software Architecture • Development Process

18. PLE Lifecycle: Domain models Domain Architecture Reusable assets Domain analysis Architecture Development Reus. Asset Development Product Specs Product Design Product Architec- ture Product Product Development Product Analysis

19. PLE Lifecycle (contd.) Attributes of a lifecycle: • Architecture Based • Economically Driven • Reuse-driven • Domain-Specific • Process-Driven (Lifecycle is guided by Development process)

20. Success Factors in PLE • Domain- specific expertise. • Architectures. • Configuration management. • Business models. • Scoping the domain. • Avoid the “Least Common Denominator” concept. • Managing requirements . • Separate domain engineering unit. • Commonalities and variabilities. • AE Manual.

21. Product-Line Practice • -PLP initiative by SEI (Software Engineering • Institute) helps in facilitating and accelerating • the transition to sound software engineering • using a product-line approach. • The objective of the PLP initiative is to provide • organizations with an integrated business • and technical approach to multi-use of software • assets. • Strongly encouraged to acquaint your team with it and follow its prescriptions.

22. Essential Activities Core Asset Development-Acquisition: It is a Domain Engineering Process. Core asset activities produce or acquire the following objects: Product space: This is a description of the initial products constituting the product line.The description specifies the commonalties and the variations among the products that will Constitute the product line.

23. Product Line Practice Areas Software Engineering Practice Areas: • Domain Analysis: domain identification, selection, scoping, modeling. • Mining Existing Assets/ Applications. • Developing and Evolving a Reference Architecture.

24. Essential Activities(contd.) Core Assets: They include an architecture that will shared by the products in the product line and reusable software components. Development and acquisition of core assets take the following inputs: Product Constraints, which deals with the kind of commonalties and variabilities that exist among the products in the family. Production Constraints, which deal with production process. Product Development Acquisition: It is an Application Engineering Process.

25. Product Line Practice Areas Software Engineering Practice Areas: • Domain Analysis: domain identification, selection, scoping, modeling. • Mining Existing Assets/ Applications. • Developing and Evolving a Reference Architecture.

26. Product Line Practice Areas Technical Management Practice Area • Metrics collection and Tracking. • Product Line Scoping. Organizational Management Practice Area • Organizational Structure

27. Product Line Methodologies Support/ Guide in the development and Evolution of the Product Line • Synthesis • FAST • FODA • JODA • DADP • DSSA • ODM