1 / 29

SPL In Practice Lessons from Real Projects

This article discusses the state of the practice in product line engineering, based on work group meetings over two and a half years and experiences from five organizations with different contexts. It explores key practices, organizational factors, and challenges faced in product line development.

kennedyl
Download Presentation

SPL In Practice Lessons from Real Projects

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SPL In PracticeLessons from Real Projects Jorge Mascena | jorge.mascena@cesar.org.br

  2. Product Line Engineering: The State of the Practice • Work group meetings over two and a half years • Five organizations with different organizational contexts • Four key practices for SPL • Organization and support practices • Practices that balance between platform versus client interests • Requirements engineering practices • Architectural practices

  3. Product Line Engineering: The State of the Practice • Factors for characterizing product line development organizations • Organizational context • Number of employees • Number of development sites • Market orientation • Hardware embedding • Core platform development

  4. Product Line Engineering: The State of the Practice • Product line charateristics • Number of products • Performance requirements • Stability • Architecture • Different contexts and more than two years time period • Opportunity to assess effectiveness of applied practices • Different challenges according to organizational and product line characteristics

  5. Product Line Engineering: The State of the Practice • Organization and support practices • Product line development impacts the entire organization • Must be planned and managed carefully • SPL development can be organized in two ways • Within product teams • In a separate SPL team • Both have associated advantages and risks

  6. Product Line Engineering: The State of the Practice • SPL within product teams • Risks spoiling the SPL core • SPL in a separate team • Reusable assets might not address products’ needs • Few organizations adopt a separate SPL team • Risks of fundamental restructuring • Proven work structures and organizational culture

  7. Product Line Engineering: The State of the Practice • Ensure optimal fit of the SPL core with product development needs • Requires a sophisticated balance of SPL autonomy and consideration of product concerns • Avoid aligning too closely with individual product needs • Ensure timely implementation of relevant product features

  8. Product Line Engineering: The State of the Practice • Support SPL development from an organizational viewpoint • Demonstrate a convincing business case • Identify an appropriate organizational structure • Justify the platform team • Cost-benefit • Custumer demand

  9. Product Line Engineering: The State of the Practice • Balancing platform versus client interests • Integrating requirements into the platform • Establish a priorization process tha everybody adheres to: single manager or architectural board • Job rotation • Discussion forums • Frequent meetings • Tool support

  10. Product Line Engineering: The State of the Practice • Find good priorization criteria • Measurements • Number of products in which the functionality appears • Efforts for realization and integration • Risk-versus-benefit estimates

  11. Product Line Engineering: The State of the Practice • Priorization process • Product requirement priorization • Platform requirement priorization • Product development planning and organization

  12. Product Line Engineering: The State of the Practice • Strong pilot client influence • Perform domain analisys before or during pilot-client-driven platform development • Walk through the features and explicitly document expected deviations • Develop a sound vision of the PL and communicate it throughout the organization • Components must be generic. Avoid rich interfces (extend them as needed)

  13. Product Line Engineering: The State of the Practice • Realization of platform requirements in products • Minimize application engineering -> integration of platform components • Perform systematic PL scoping to clarify which requirements will be implemented in the platform • Job rotation between product and platform development • Install an architecture review board • Enforce the development of architectural models

  14. Product Line Engineering: The State of the Practice • Requirements engineering practices • Very important in SPL: various domains simultaneously • Important practices • Domain identification and modeling • Separate specification and verification for platform and product requirements • Management of integrating requirements into the platform and products • Identification, modeling and management of requirements dependencies

  15. Product Line Engineering: The State of the Practice • Domain analisys and domain description • A well-understood domain is a prerequisite for defining a suitable scope for the product line • The impact of architectural decisions on requirements negotiation • Focusing SPL evolution too much on architectural issues will lead to shallow or even incorrect specifications • Architecture roundtable meetings with requirement engineers, lead architects and marketing and sales personnel

  16. Product Line Engineering: The State of the Practice • Effective tool support • Existing tools don’t satisfactorily support aspects such as variability management, version management for requirements collections etc. • Two approaches: design custom solutions or organizational measures

  17. Product Line Engineering: The State of the Practice • Architectural practices • Explicitly define and document the architecture • Dissemination is key • Enforce us of available architecture • Architectural roles • Product architect • Product line architect • Domain architect • Component architect

  18. Product Line Engineering: The State of the Practice • Architects are responsible for traceability between (product) requirements and architecture solutions

  19. Software Product Families in Europe Esaps and Café Projects

  20. Software Product Families in Europe • ITEA (Information Technology for European Advancement) projects • ESAPS (Engineering Software Architectures, Processes, and Platforms for System Families • Café (Concepts to Application in System-Family Engineering)

  21. Software Product Families in Europe • Family development concerns • Business: the way resulting products make a profit • Architecture: the technology needed to build the system • Process: responsabilities and dependencies during software development • Organization: the organization in which the software is developed

  22. Software Product Families in Europe • Main goals of the projects • Improve development paradigms • Improve reuse level • Architectural improvements • Developments in computing platforms • Distribution and communication • Development environments • Software development paradigms

  23. Software Product Families in Europe • Business • Scoping is key. Project objectives and domain focus must be appropriately scoped and aligned with needs of the market • Scoping must be performed over the family’s lifetime • Three kinds of scoping • Product family scoping: product portfolio • Domain scoping: boundaries to relevant domains • Asset scoping: reusable elements

  24. Software Product Families in Europe • Architecture • Variability should be modeled through variation points • Designing system families requires finding a way of architecting both commonality and variability to exploit them during the tailoring process • Product family architecture defines the components, relationships, constraints and guidelines • Variability in the large and variability in the long term: related to the type of equipment and to the market

  25. Software Product Families in Europe • Architecture • Most important reusable assets: requirements, domain model, architectures, patterns, design decision model, software components, interfaces between components, test casesa and product documentation • Aspect analisys (Philips): developers considered 3 design dimensions independently - structure, aspects and behavior – and then assigned each piece of functionality a place in each dimension

  26. Software Product Families in Europe • Architecture • Requirements must be traced to family assets • Pre and pos traceability: related to assets in earlier or later stages • Horizontal and vertical traceability: related to the abstraction level of the assets

  27. Software Product Families in Europe • Process • Introduce a software development process incorporating all of a family’s products • Take into account asset reuse • Traceability is connected to configuration and version management • Important to know which versions of which assets are used in which systems

  28. Software Product Families in Europe • Process • Change management lets us predict the properties and new family assets before building them • Changes in one asset of a family might affect many products in several ways: guidelines and automated support are essential • Depending on functional and quality requirements, the architect selects the product variants to be delivered • Meta-model to improve asset classification and methods for effectively selecting components • No tool effectively addresses all aspects needed

  29. Software Product Families in Europe • Organization • Separate development groups should work on family engineering and product engineering

More Related