**********************************************************************
セッションS2-d チュートリアル
テーマ：Transforming Legacy Systems into Software Product Lines
講師：Danilo Beuche (Pure-system)
日時：20011/8/31 9:00〜10:20
参加人数：約20名（終了時）
**********************************************************************

■発表概要
* Software Product Lines
	* Software product line is a concept which is supposes to help you to improve your business significantly.

* 1st picture
	* This is an essence of software product line engineer in Japanese form.
		* looks beautiful and simpler
		* On the other hand, it takes very longtime to us to make
		→do not be afraid of a product lines in industry 
　		  He gave us some ideas probably can do this at a fist step

* Self-introduction
	* He works at pure-systems (http://www.pure-systems.com/)
		* pure-systems is the leading provider of software product line and variant management engineering tools and solutions
	* consulting
		* to explain the idea
			* what is the tool
			* concept of the tool
			→ and then, make software line

* structure
	1. discuss about what is essence of product lines
		* what we want to achieve and want to go
	2. how to find out the basic direction
		* how we can do this
		* what happen during the journey
		* how to use pure::variants
	3. what kind of option we have to start the organization
		* example (software => software product line)

* what is your goal, what is the problem
	* example : The Version Hell
		* 1st customer : all components => version 1.0
		* 2nd customer : changes(more function: new components and change components) 
		* 3rd customer : some changes 
		* 4th customer : combination of other versions
				 →Much work
					* Reuse 
					* Combine
					→ want to avoid this
	* example : Separation of Variants and Versions
		* 4 variants product
			* New product
				* Still care existing old product 
					* Have to develop this to use same functions (for combinations)
					→ a lot of satisfaction and a lots of work
					* Idea 
						* Separate changes overtime 
						* Definition of product and ability to combine
							* Functionality
							* Non-functionality
	* What is the different between developing software and developing software product lines
		* Explicit variant management
			* Understand all of the variant
			* Not only say we have a lot of variation and switches
			* But also say we able to sat who use what and which product
		* Variation point == first class
			* Have to understand what’s the different 
			* We have to Able to talk this to customer
		* Separation of Concern
			* Change overtime in function and behave => too complex
			*  Have to separate to avoid
		* What is the variation point
			* Example: Shape of the car; 3 choice	
				* There are more than one change between the choices
				* Have to check all patterns
					* Choice reduce the combination
			* You can fin variation everywhere (source, document, models,,,etc )
		* Separation of Concern
			 -------------------------Domaim Engineering------------------------
			|  -----------------------                ------------------------  |
			| | Feautuers & Relations |     ←→	 |	FamilyAssets      |-  
			 -|                       |--------------|                        |  
			 Problem     ↑		  |              |	     ↑       Solution
			   Space     ↓           |              |           ↓          Space
			 -|                       |--------------|                        |-
			| |    Variant Feautuers  |              |     Variant Solutin    | |
			|  -----------------------                ------------------------  |
			 -----------------------Application Engineering---------------------
			* Domain engineering
				* Features & relations
					* Outsides(doors, shape)
					* Example : door
					* Sports car :2 doors
					* Family : 4 doors
				* Family Assets
					* Implemented and can execute Features & relations
				* How much money can you get from this?? Customer pay for this??
					* Almost ZERO
					* customer do not care
			* Application Engineering
				* Can make money from this.
					* To make products
				* Variant Features
					* define product (using features)
					* complex task
				*  Variant solution
					* Require all of the others
					* Everything you need for product comes from Family Assets is not true
					* Depend on how you do this

* Migrating existing software
	* Have to Find out other specifics
	* Want to know basic direction
* Questions Before Starring
	* Development: What is missing?
		* Analysis
		* We looked through software product line
		* What is missing when I look at my organization
		* Example
			* Variation point
			* Solution space
		* Business: What to achieve?
			* ×problem => ○challenges (German)
			* Make more money than others!!
				* Improve quality
				* Cost reduction
				* Time to market
		* People: Main Driver / Sponsor
			* Some one who are behind you
			* Management who say “yes, we want to chase” 
		* Assets - Transition Scenarios
		              --------------
			 　  |Current Assets|
			      --------------
	 　　		　　  ↓　　　　　↓
          ------------------------       -----------------
     　　|Separate Products Merger|     |Reuse improvement|
          ------------------------       -----------------
		　　↓			 　　 ↓
 ---------------------------------       -------------------------------------
| Mostly separate solution domains|  　 |Same or very similar solution domains|
 ---------------------------------       -------------------------------------
			* Separate Products Merger 
				* Basically we can reuse of problem space 
				* Mostly separate solution domains
				* Find similar product, some part of systems(solution space)
				* Have to develop a lots
			* Reuse improvement
				* How much can we reuse
					* Same or very similar solution domains
					* Easier!!  
		* Assets ? Transition Step
			 ( Pre-SPL )
			     ↓
	        [ Analyses Situation & Goals ]
    			     ↓
	        ( Transition Path Identified )
 			     ↓
		   [ Variability Analysis ]
   			↓　　　　↑
		[ Variability Model building ]
			     ↓
		    ( Start SPL Rollout )


* Ready to start journey 
	* There are no clear way to do that
	* The ways are not same
* Variability Analysis
 ----------------Domaim Engineering------------------
| -------------   --------------   ----------------- |
||   Manuals   | | Source  Code | | Varsion Control ||
| -------------   --------------   ----------------- |
| -------------   --------------   ----------------- |
|| Requirements| | Config Files | | Change Requests ||
| -------------   --------------   ----------------- |
|                       ↓                           |
|              ---------------------                 | 
|             | Variability Model(s)|                |
|              ---------------------                 |
 ----------------------------------------------------
* Analysis Direction
 --------------------------------------------- Domaim Engineering--------------------------------------------------
| ----------------  Problem Space --------------------        ---------------- Solution Space -------------------  |
|| -------------   --------------   ----------------- |      | -------------   --------------   ----------------- ||
|||   Manuals   | | Source  Code | | Varsion Control ||      ||   Manuals   | | Source  Code | | Varsion Control ||| 
|| -------------   --------------   ----------------- |      | -------------   --------------   ----------------- || 
|| -------------   --------------   ----------------- | →→ | -------------   --------------   ----------------- ||   
||| Requirements| | Config Files | | Change Requests ||      || Requirements| | Config Files | | Change Requests |||  
|| -------------   --------------   ----------------- |      | -------------   --------------   ----------------- ||  
||                       ↓                           |      |                       ↓                           ||  
||              ---------------------                 | ←← |              ---------------------                 ||   
||             | Variability Model(s)|                |      |             | Variability Model(s)|                ||  
||              ---------------------                 |      |              ---------------------                 ||  
| ----------------------------------------------------        ---------------------------------------------------- | 
 ------------------------------------------------------------------------------------------------------------------
	* Normally: problem space → solution space
* CaVE ? Approach (German research)
	* variability analysis
	* we have list of certain patterns and check document
	  → what pattern will work good with or not
	* Domain Expert(important person)
		* Who knows everything
		* He will do organization
	* using documentation patterns
		* descriptions
* Problem Space modeling
	* Connect isolated variation points
		* feature
		* related
	* picture model(most popular)
* demo with pure::variants
	* example : picture model
		* options
			* necessary feature(air presser / wind speed / temperature)
			* language(English / German)
			* variability
			　→cross dependences
	* Separation of Concern
	* example : family model
		* temperature(condition of element)
			* have some option
	* example with pure::variants
		* based on eclipse
		* family model
			* pure::variants tell what function is not possible on the condition
				* example: without fog light(option) → × not possible to ship Denmark
				* from requirements
					* you can write the rules 
				* easy to chose make a combinations
					* can pick up minimum requirements
		* Simulink conversion
			* in the Simulink, there are blue boxes
			* Variation points are in the blue boxes and can change function
			* Same model  but you can change variations
		* Testing features
			* easy to pick up minimum testing pattern
			* example: 1526 products →  only 15 products test

* Organization Mapping 
 -------------------------Domaim Engineering------------------------
|  -----------------------                ------------------------  |
| |     Domain Expart     |     ←→	 |   PLArchitects/Devel.  |-  
 -|                       |--------------|                        |  
 Problem     ↑		  |              |	     ↑       Solution
   Space     ↓           |              |           ↓          Space
 -|                       |--------------|                        |-
| |  Application Analyst  |              |  Application Engineer  | |
|  -----------------------                ------------------------  |
 -----------------------Application Engineering---------------------
* How do we start product line(Approaches)
	* Platform-Centric
		* Basic but not good
	* Incremental Platform-Centric
		* Less risky
	* Project-Centric
		* +project team collaboration

* Get all running
	* Run in one direction
	* not only everyone is excited
*  Check and revise your way often
	* No one know
* Bear trap 
	* Not good shape
* 4 pictures
	* (Sometimes) Not for profit
	* We sometimes have failure
	* Try to make it simpler
	* Small budget is not good idea

* Example: electrical motor control
	* electrical motor control
		* Power range: 0.18kW-1.2MW
		* 4 Business Domains
		* OME &Custom Products
	* 5 location
		* 100 developers
		* 500.00LOC
		* 20+Products
	* The company’s example
		* SPLE Project(2005 -2006)
		* Bottom-up approach
		* SPL in Products(2006-)
		* 80/20% on 13 products
		* Danfoss Drivers Platform Feature Model
		* Code unification
		* Database unification 

■ Summary
	* Try to avoid variability
		* Have to see them
	* Start Small
	* Improve Stepwise
	* Look for Quick ROI(important)
	* Involve SPL Experience
	* Ask someone have experience
	* First Product Line is not good
		* After you can get nicer!!

□ 質問
	* SPLから得られるリターンが一番起きいのは、重複するコード・作業などの削減などによてえられるか？（実際の現場の感覚として）何をすることによって、もっとも見返りが得られるか？
		* I do not know
		* Depends on problem
		* Example: Reduction of developing time
		* Combination of benefit