1. DAIMIHenrik Bærbak Christensen1 Product Lines Architectural Reuse

2. DAIMIHenrik Bærbak Christensen2 A Simplified Development Process ?

3. DAIMIHenrik Bærbak Christensen3 Architectural Reuse “A software architecture represents a significant investment of time and effort. So it is natural to want to maximize the return on this investment by re-using an architecture across multiple systems.” –Architectures are valuable intellectual property –reusing asset is cheaper than reinventing it…

4. DAIMIHenrik Bærbak Christensen4 Definition Software product line –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 and that are developed from a common set of core assets in a prescribed way. Assets –base architecture –architectural (tailorable) elements –designs, documentation, test plans, project management artifacts…

5. DAIMIHenrik Bærbak Christensen5 War stories Nokia –25-30 models per year (up from 4 models per year) Motorola –400% productivity improvement for one-way pagers HP –time to market reduced by factor 7 –productivity increase by factor 6 –family of printer systems Cummins Inc –reduce production time 1 year → 1 week –diesel engine software

6. DAIMIHenrik Bærbak Christensen6 Nuts and Bolts Success: Commonalities shared by products can be exploited through reuse of assets. –Requirements: most are common  no req. analysis –Arch. design: is stable –Elements: code and design reused –Modeling / analysis: real-time analysis reused –Testing: already in place –Project planning: budget, work-break-down, known with high confidence

7. DAIMIHenrik Bærbak Christensen7 Nuts and Bolts –Processes, methods, tools: SCM, tool environments, coding standards, can be transferred –People: transferable between projects –Exemplar systems: Deployed systems serves as high-quality prototypes –Defect elimination: Previous generations’ defects have been eliminated.

8. DAIMIHenrik Bærbak Christensen8 Why not reuse libraries? Appealing idea –“library of snippets from previous projects; everybody must check here before coding himself” Does not work because: –library too sparse: nothing found –library too rich: difficult to search –elements too small: easier to rewrite than understand –elements too large: not right for problem at hand –GIGO: garbage in  garbage out Architectural models differs !!!

9. DAIMIHenrik Bærbak Christensen9 Why product lines works! Product lines works because –very strict architectural context for elements –architecture is defined –functionality / domain is fixed at overall level –quality attributes are defined and known –strategic / planned reused, not opportunistic

10. DAIMIHenrik Bærbak Christensen10 Product line architectures Product line –Commonality: The core architecture defines flow of control defines element types defines variability points Variability points –Framework techniques in OO –Static techniques (often using CM tools) conditional compilation [ #ifdef in C ] conditional linkage [library V1 or V2] –Dynamic techniques shared libraries / DLL parameterization [windows registry/ini files, etc]

11. DAIMIHenrik Bærbak Christensen11 Evaluation Basically the same architectural evaluation techniques can be applied –QAW, ATAM, … Special focus on variability points

12. DAIMIHenrik Bærbak Christensen12 Adoption strategies Top-down –business drivers and goals point towards PLA Bottom-up –developers detect needless duplication Growth –Proactive up-front design “revolution” –Reactive evolution But – lot of domain knowledge critical in any case: “You will build it three times before you know the points of variability”

13. DAIMIHenrik Bærbak Christensen13 Maintenance / Evolution Adding features –spin-off in separate product (line?) back to multiple maintenance of similar systems redundency –include in product line upgrading old products? –keeping products in sync is expensive… sufficient commonality between products?

14. DAIMIHenrik Bærbak Christensen14 Organizational structure Suggestions by Bosch –Development department = single unit –Business units = separate teams those needing function X add it to product line, supports it –Domain engineering unit = parts department one unit responsible for core assets other units derive products from product line –Hierarchical domain engineering unit very large product lines may need hierarchical decomp. Tracz: Only parts department will work! –projects will have their own agenda that does not match that of the product line… why should project X help project Y when we are pressed for time already???