VTT TECHNICAL RESEARCH CENTRE OF FINLAND - VTT Virtual project

1

VTT TECHNICAL RESEARCH CENTRE OF FINLAND

SPLC 2005 in Rennes, France, 26 Sept. 2005 © Eila Niemelä 1

Quality Driven Family Quality Driven Family Architecture DevelopmentArchitecture Development

Prof. Prof. EilaEila NiemeläNiemeläVTT Technical Research Centre of FinlandVTT Technical Research Centre of Finland

E-mail: [email protected]

QADA®

QADA®: http://www.vtt.fi/qada/



MOTIVATIONMOTIVATION

• Product family engineering is increasingly applied to software intensive systems development.

• BUT• How can it be sure if product family engineering is

suitable for a specific software development context?

• What are the benefits, preconditions and constraints entailed in family architecture development?

• How can quality issues be considered in family architecture development?

• How can the maturity of a PFA be evaluated?

2



TUTORIAL OUTLINETUTORIAL OUTLINE

• INTRODUCTION• MAIN CONCEPTS OF PRODUCT FAMILY

ENGINEERING• OVERVIEW OF QADA®

• FAMILY ARCHITECTURE SELECTION• FAS method

• QUALITY REQUIREMENTS OF A SOFTWARE FAMILY• QRF method

• FAMILY ARCHITECTURE EVALUATION• FAE method

• CONCLUSIONS



INTRODUCTIONINTRODUCTION

• PRODUCT FAMILY ENGINEERING

• QUALITY ATTRIBUTES

• PRODUCT FAMILY ARCHITECTURE

• SOFTWARE ARCHITECTURE AND QUALITY

3



PRODUCT FAMILY ENGINEERINGPRODUCT FAMILY ENGINEERING



QUALITY ATTRIBUTES IN STANDARD(S) QUALITY ATTRIBUTES IN STANDARD(S) INTERNATIONAL STANDARD ISO/IEC 9126INTERNATIONAL STANDARD ISO/IEC 9126--11, , Quality modelQuality model

4



QUALITIES

performance

scalability

reusabilitymeasurability

transferability

user-friendliness safetysimplicity

wrappabilitydiversityinteroperability

integrabilityflexibility

- maintainability- flexibility- modifiability- extensibility- portability- reusability- integrability- testability

- performance- security- availability- usability- scalability- reliability- interoperability- adaptability

EXECUTION EVOLUTION

QUALITY ATTRIBUTES IN LITERATUREQUALITY ATTRIBUTES IN LITERATURE



SOME DEFITIONS OF QUALITY ATTRIBUTESSOME DEFITIONS OF QUALITY ATTRIBUTES

Quality attribute

Description

Availablity Availability measures the proportion of time the system/service is up and running.

Reliablity The ability of the system or component to keep operating over the time or to perform its required functions under stated conditions for a specified period of time.

Modifiability The ability to make changes quickly and cost-effectively.

Maintainability The ease with which a software system or component can be modified to correct faults, improve performance, or other attributes, or adapt to a changed environment.

Flexibility The ease with which a system or component can be modified for use in applications or environments other than those for which it was specifically designed.

Scalability The ease with which a system or component can be modified to fit the problem area.

5



ARCHITECTUREARCHITECTURE--CENTRIC FAMILY CENTRIC FAMILY ENGINEERINGENGINEERING

share

share Product Family

Architecture

Managed Set of Features

Componet Component Component

are built

Product Product

Product

Group of products

Component Component



ORTHOGONAL PROPERTIES OF SOFTWARE ORTHOGONAL PROPERTIES OF SOFTWARE ARCHITECTUREARCHITECTURE

Conceptual

Realizational

Hierarchy

Abstraction

DynamicStatic

Viewpoint

6



SOFTWARE ARCHITECTURE & QUALITYSOFTWARE ARCHITECTURE & QUALITY

complement each other

ARCHITECTURE DESCRIPTION

Taxonomy of orthogonal propertiesMultiple views

Abstractionlevel

Dynamism Aggregationlevel

Physical Development

• commonalties• variabilities

• maintainability• modifiability• reusability• portability

• performance• reliability• security

• availability• capacity• bandwidth

managingadministrativecontrol

Decomposition offunctionality-conceptual-

Realization ofthe conceptual

abstraction

LogicalConcurrency



QADA viewpointsQADA viewpoints

7



INITIATION AND EVOLUTION OF PRODUCT INITIATION AND EVOLUTION OF PRODUCT FAMILY ARCHITECTUREFAMILY ARCHITECTURE



QADA®

• Development started in 2000

• Industrial applications:

• Middleware services• Distribution platforms• Wireless services• Wireless terminals• Control systems• Measurement systems• Product families of

embedded systems and software systems

8



FAS FAS ––

FAMILY ARCHITECTURE FAMILY ARCHITECTURE SELECTIONSELECTION



CONTENTCONTENT

METHOD AND MATERIAL

STRATEGY EVALUATION FRAMEWORKPFA mapPFE strategy selection method

SUMMARY

9



RESEARCH METHODRESEARCH METHOD

• Semi-structural interviews• Reviews of architecture documentation of two industrial companies

• Collecting published papers about industrial case studies• Reorganizing input material• Comparison analysis• Generalization of the findings

• Strategy map• Approaches applied

• Step-wise approach:• 1. phase

• 3 SMEs interviewed• FAE method created

• 2. phase• 12 case studies from literature• The same comparison framework

• 3. phase• 2 large enterprises interviewed

• 4. phase• Definition of FAS



CASE STUDIESCASE STUDIES

• Types of cases:• 2 of 17 cases included more than one product family• 5 interviewed companies with 6 PFs of embedded

software/systems• 11/13 PFs from literature developed embedded systems

and devices• 5 companies with 6 PFs provided pure software PFs

• However, 3 of them were related to embedded systems

• 8 PFs in SMEs, 11 PFs in 6 large enterprises in different application fields/domains.

• Type of products:• From distributed information systems to CC systems, • From HW related & DSP software to UI software,• From large integrated products (mechanics, electronics,

software) to business supporting tools

10



PFA MAPPFA MAP



FINDINGS FINDINGS --PFE ORGANISATIONPFE ORGANISATION

• Differences:• Separated domain engineering and product development

(group/department/unit)• Reasons may be the types and size of product families, geographical

locations, cultural differences, developers’ expertise in sites,etc.• Similarities:

• PF developers and product developers were separated on the role level (but could be done also on the organisation level)

• PF developers were grouped to one site, unit or department• If PF developers were divided into different organisation units, their

roles and responsibilities were well defined.

• Supported cooperation between PF and product development• Allocation of personnel• Migration of product specific features/components to family assets

• PFA as a management tool:• Scoping, goals, responsibilities and relationships, managerial

commitment• Evolutionary vs. revolutionary approach (i.e. risk avoidance)

11



FINDINGS FINDINGS ––PFE ROLES & RESPONSIBILITIESPFE ROLES & RESPONSIBILITIES

Management of product development and deployment.Project/product manager

Product derivation; feature/component leverage from a product to the product family.Product architect

Quality controlPermanent members or members are changing according to running products.Project managers, the PFA architect, lead designers), product architects.

Architecture board (AB)

Professionals who provide their expertise for the use of other persons that play other roles in PFE (e.g. design patterns).

Teams; domain analysts, technical experts and core assets developers (system and code levels).Single (large) platform team and multiple small and high-skilled product teams.An application specialist working as a member of the AB and product testing.Market analysts

Support teams/persons

Quality of the domain architecture and its components.Domain/component owner

Specific functional part (feature or medium size component) of the PFA, participating in AB.Lead designer

Domain architecture, definitions of the architectural concepts and principles, integration architecture (exported interfaces), common mechanisms, communication of PFA concepts and principles, participation in the architecture board (AB).

PF architect

Initiation of PFE, motivation of the staff, relationships to funding managers and marketing staff.PF leader

ResponsibilitiesRole



FINDINGS FINDINGS ––POTENTIAL OF PFEPOTENTIAL OF PFE

Focus on customers’needs; easy to install, learn and maintain.

PC as a generic platform; add-ons for main products, differentiating price, improved customers’ satisfaction.

Packaged services as a means of management, communication and abstraction

The same as in the internal platform but more focused on management.

Vertical application domain knowledge; focus from technology towards business and organisation.APIs, MOTS for other PFs

Product platform as a means of management and communication

Focus on execution qualities, e.g. performance and reliability. Flexibility through managed variation points.

Generic communication mechanisms, generic IT technologies; technology-driven approach.Frameworks for sub-domains

Internal platform as a means of communication and management

Customised products by tailoring or by software keys, easy maintenance, extensions by strictly defined configuration rules.

Explicit component architecture, specific mechanisms for variation points, configuration DB, rules and tools, differentiating price; application driven but highly technology dependent.Extra effort for configuration, quick derivation and deployment.

Configurable features or/and components baseas a means of managing technology know-how

Product variations are maintainable and a product family is extensible.

A domain architecture with variation points, architectural styles and patterns, and component types; application-driven.Long-term investment, standards are less important than knowledge about domains and architecture styles and patterns.

Product family architecture as a means of abstraction, communication and management

Potential Requires/provides/constraintsPFA approach

12



PFE STRATEGY SELECTION METHODPFE STRATEGY SELECTION METHOD

Phases:1. Assumptions evaluation2. Target PFA decision3. PFE strategy selection



PHASE 1: PHASE 1: ASSUMPTIONS EVALUATIONASSUMPTIONS EVALUATION

Goal: • To identify assumptions for successful PFE adoption

• Future customer needs are known or can be predicted

• Short delivery times provide competitive advantage, for example,by extending market share or entering new emerging markets.

• Product costs have remarkable dependence on software development and maintenance.

• Products can be used in various ways, e.g. they are used as such and/or with other products.

• High quality of products is essential in achieving customer satisfaction.

13



PHASE1PHASE1-- EVALUATION CRITERIAEVALUATION CRITERIA

Customer satisfaction

Quality

VariabilityCustomisation

Profitability Cost structure(software/products)

Cutting edgeShortening delivery times

PredictabilityCustomer needs

CriterionIssue



PHASE 2PHASE 2-- STEP1:STEP1:TARGET PFA DECISIONTARGET PFA DECISION

Goal: • To find out the strengths and weaknesses of

a company in the context of PFE

• Evaluation of the status quo of the architecture of existing products

• Products; criteria are depending on domains, used technologies and customers’ needs

• Personnel know-how; criteria are depending on product qualities

• The FAE method can be applied

14



PHASE 2 PHASE 2 -- STEP2:STEP2:IDENTIFY SUCCESS FACTORS AND THEIR IDENTIFY SUCCESS FACTORS AND THEIR

IMPORTANCE IMPORTANCE

PFAConfigurable features/components base

Cost effectivenessEvolutionmanagement

PFACost effectivenessEffective workorganisation

Platform product Packaged services

Cutting edgeNew opportunities

Internal platform, Configurablefeatures/components base

Cutting edgeKey competence

Configurable features/components baseConfigurable product family base

CustomersatisfactionTime-to-market

Managingcustomer needs

PFA alternativeCriteriaSuccess factor



PHASE 2 PHASE 2 -- STEP3STEP3::ESTIMATE ROIESTIMATE ROI

• Return on investment is estimated for the different ways of implementing PFA

• Criteria: investment and potential

• Economic models needed

• Example is an intuitive estimation based on the collected data.

In v e s tm e n t

P o ten tia l

C o n g iru g a b leP ro d u c t F a m ily

B a seP F A

C o n fig u rab leF e a tu re s /C o m p o n e n ts

B a se

In te rn a lP la tfo rm

P la tfo rmP ro d u c t

P ac k ag e dS e rv ice s

15



PHASE3:PHASE3:PFE STRATEGY SELECTIONPFE STRATEGY SELECTION

separation of commonalities and variabilities, the amount of customization, quality of products

internal platform + configurable features /components base

4. Balancing cost and customer satisfaction

familiarity with end-user needs

packaged services

3. Maximizingend-usersatisfaction

high technological competence, openness, market share, organization model

platform product

2. Extending market share

identified commonalities, high technological competence, the size of product family

internal platform

1. Minimizing risks

CriteriaMeansStrategy



PHASE3:PHASE3:PFE STRATEGY SELECTIONPFE STRATEGY SELECTION

complexity, variability, cost effectiveness,delivery times, customer satisfaction,market share, emerging new markets

PFA +Configurablefeatures/components base + Platform product + Packaged services

8. Maximizing potential

complexity, variability, delivery times, market share, emerging new markets

PFA +Configurablefeatures/compoentsbase

7. Balancingcost, customer satisfaction And potential

complexity and variability, market share, new markets

PFA6. Balancingcost and potential

quality of products,short delivery times

Configurableproduct familybase

5. Maximizing customer satisfaction

CriteriaMeansStrategy

16



SUMMARY OF FASSUMMARY OF FAS

• Six ways of applying PFA and eight PFE strategies to implement PFE have been identified

• Selecting the most appropriate PFE approach is an important issue for a company

• Decision making has to be based on data collected from measurements, analysis reports, business visions and strategies complemented by interviewing the best experts of a company.

• The FAS method is based on the knowledge gained from industrial case studies and experiences but the method as such has not been applied to industrial cases yet.



QRFQRF--QQUALITY UALITY RREQUIREMENTS OF A EQUIREMENTS OF A

SOFTWARE SOFTWARE FFAMILYAMILY

17



INTRODUCTIONINTRODUCTION

• QRF captures and maps the requirements of a system family to the family architecture by

• analyzing the needs of business and technology development stakeholders, and

• analyzing the impact of these needs on the family architecture.

• QRF describes in detail how the quality requirements have to be defined, represented and transformed to architectural models

• this enables quality evaluation at an early phase with minimal time investment.

• QRF is aimed especially for product families but it is also suitable for single systems



METHOD OVERVIEWMETHOD OVERVIEW

The QRF consists of five steps:

1. Impact analysis2. Quality analysis3. Variability analysis4. Hierarchical domain analysis5. Quality representations

18



QRF & QADAQRF & QADA

5. Quality representations

1. Impact analysis

2. Quality analysis 3. Variability analysis

4. Hierarchical domain analysis



1. IMPACT ANALYSIS1. IMPACT ANALYSIS

Goal: To define the interested stakeholders and their

targets concerning the product family

• The concerns of different stakeholders are negotiated to achieve all relevant functional and quality requirements of a product family

• I*framework is used for requirements definition and negotiation

• I*framework enables to describe dependencies and conflicts between stakeholders’ concerns

example

19



2. QUALITY ANALYSIS2. QUALITY ANALYSIS

Goal:To express quality requirements (QR) in a way that they can later be

traced and measured • QAs must be prioritized

• Requirements on the highest priority level have always to be met in architecture (to be considered in trade-off analysis)

• Evaluation criteria are derived from the QRs and classified to evaluation levels, e.g.:

• Family specific QRs of• high priority• medium priority• low priority

• System/domain specific QRs of• high priority• medium priority• low priority

example



3. VARIABILITY ANALYSIS3. VARIABILITY ANALYSIS

Goal: To define the QRs that vary on the business domain or

stakeholders

• Types of variability:• Variability among quality attributes

• For example, for one family member the reliability is important, but for other family members there are no reliability requirements.

• Different priority levels in quality attributes• For example, for one family member the extensibility requirements are

extremely high, whereas for others those requirements are at the lower level.

• Indirect variation• Functional variability can indirectly cause variation in the quality

requirements and vice versa.

Example

20



4. HIERARCHICAL DOMAIN ANALYSIS4. HIERARCHICAL DOMAIN ANALYSIS

Goal:To map common and variable QAs to hierarchical service

categories

• The QRs common to all family members must be mapped to the common functionality of the family

• The architect has to decide which services are responsible for each quality requirement (scoping)

• One requirement may be mapped to several functional services (dependency mgmt)

• The quality requirements themselves may result in certain functionality (i.e. execution QAs)

• The requirements mapping is a specific work of the software architects and requires an extensive knowledge of the product family and its members

Example



5. QUALITY REPRESENTATION5. QUALITY REPRESENTATION

Goal: To describe architecture in a way that the QRs can be

evaluated from the architectural models

There are two main means to achieve quality requirements in architecture:

1. The use of architectural styles and patterns• Styles and patterns employ qualitative reasoning

to motivate when and under what conditions they should be used

2. The use of qualitative constrains, e.g. specific quality profiles

• Profiles can be defined to extend the architectural models to support certain quality aspects

21



QUALITY REPRESENTATIONS: QUALITY REPRESENTATIONS: styles and patternsstyles and patterns

• Candidate architectural styles must be identified. For each style, it is examined how it meets the quality requirements

• Possible conflicts between QRs are identified and the trade-off analysis is carried out

• NFR (Non-Functional Requirements) framework or Stylebase can be utilized in style selection and in conflicts solving

• The architectural style that meets the QRs best is then selected



QUALITY REPRESENTATIONS: QUALITY REPRESENTATIONS: quality profilesquality profiles

• UML 2.0 enables the description of all the viewpoints of QADA

• UML notation can be extended to support certain quality attributes using UML’s own extension mechanism, profiles

• A profile consists of stereotypes, tagged definitions and constraints

• By creating a new stereotype, defining tags for it, and denoting the stereotype to extend the desired meta-class, the certain elements in architecture can be extended with a new profile

• Profiles enable the attachment of quality properties to the architectural models

Example

22



APPLYING QRFAPPLYING QRF

• The steps of the method are the same considering all quality attributes

• The QRF method has been applied for evaluating• execution qualities (e.g. reliability and

availability) and • evolution qualities (e.g. integrability and

extensibility)

Go To Next



Case example: A Distributed Services Platform Case example: A Distributed Services Platform ((DiSePDiSeP))

• DiSeP system family provides a distribution platform for a family of software systems.

• Includes three family members: middleware systems for game, health care and emergency intervention applications.

23



Example Example –– 1. Impact analysis1. Impact analysis

Emergencyinterventionapplication

MiddlewareEnd user(doctor,police)

Systemfamily

architect

Emergencyapplicationdeveloper

System 3architect

Service availabilityis very high

Response timeis short

Fault occurrence isprevented

Middleware servicecapability to recover

Data replication

Data consistencyis verified

Messages arenot lost and integrity

is ensured

Very fastservice recovery

Service executionback-up

back



Example Example –– 2. Quality analysis2. Quality analysis-- QR identification & prioritizationQR identification & prioritization

highEnd user of application

The probability of failure is not over 0,01

R1-S3

mediumEnd user of application

Recovery time of the middleware services is 3 seconds

R2.2-S3

lowSystem family architect

Data consistency is verified in every 5 seconds

R5

highSystem family architect

Middleware services are able to recover

R2.1

Importance Stakeholder Requirement description Req ID

24



Example Example -- 2. Quality analysis2. Quality analysis-- Mapping R&A requirements to functionalityMapping R&A requirements to functionality

Data distribution, Location serviceR6

Data distributionR7

Data distributionR5

All the involved basic, system and communication services

R2.1

Corresponding serviceR&A requirement

• Mapping family-specific R&A requirements to functionality



Example Example –– 2. Quality analysis2. Quality analysis-- Order of evaluationOrder of evaluation

Low level system-specific requirements

Medium level system-specific requirements

High level system-specific requirements

System family-specific requirements

Evaluation criteria

R2.2-S3, A3-S3, A4-S3

Level 3

-Level 4

A1-S3, A2-S3, R1-S3, R3-S3, R4-S3, R8-S3, R9-S3

Level 2

R2.1, R5, R6, R7Level 1

Corresponding requirement

Evaluation level

25



Example Example –– 2. Quality analysis2. Quality analysis-- Selecting an architectural style and doing the Selecting an architectural style and doing the

tradetrade--off analysisoff analysis

• NFR framework for detecting conflicts

Layeredarchitecture

SimplexABAS

Implicitinvocation

Blackboard

Reliability Performance

Recovery+++

Data replication+++ Space

performance+

Timeperformance

+++

Backwardrecovery

++

Forwardrecovery

+++Local

+Remote unit

+++



ExampleExample –– 2. 2. QualityQuality analysisanalysis-- Defining criteria for R&A evaluationDefining criteria for R&A evaluation

Low level system-specific requirements

Medium level system-specific requirements

High level system-specific requirements

System family-specific requirements

Evaluation criteria

R2.2-S3, A3-S3, A4-S3 Level 3

-Level 4

A1-S3, A2-S3, R1-S3, R3-S3, R4-S3, R8-S3, R9-S3

Level 2

R2.1, R5, R6, R7Level 1

Corresponding requirementEvaluation level

low

medium

medium

medium

Importance

R6

R7

R5

R2.1

Req.ID

Data distributionData loss prevented in error situations

Data storage, data distribution, location service

Data replication

Data distributionData consistency verification

All basic, system and communication services

Service capability to recover

Impacted architectural elementsEvaluation criteria

Criteria for evaluation of the DiSepsystem family

Back

26



Example Example –– 3. Variability analysis3. Variability analysis

HighFull functionalityS3:A middleware for emergency intervention application

MediumRestricted functionality

S2: A middleware for health care application

LowLight functionalityS1: A middleware for game application

R&A importanceFunctionalitySystem



Example Example –– 3. Variability analysis3. Variability analysis--Describing variability in R&A qualitiesDescribing variability in R&A qualities

Gameapplication

Health careapplication

Emergencyinterventionapplication

Middleware

Middleware

Middleware

End user(gamepalyer)

End user(medicalworker)

End user(doctor,police)

Gameapplicationdeveloper

Systemfamily

architect

Health careapplicationdeveloper

Emergencyapplicationdeveloper

System 1architect

System 2architect

System 3architect

No breaks incommunication

Reliability is atlow level

Service recoveryin medium time

Data is alwayscorrect

Reliability is athigh level

Recovery timeis fast

Service availabilityis very high

Response timeis short

Fault occurrence isprevented

Service recoveryat medium rate

User notification offailures/shutdowns

Middleware servicecapability to recover

Message loss ismedium low

Data replication

Data consistencyis verified

Messages arenot lost

Service recoveryat medium rate

Data correctnessis ensured

Messages arenot lost and integrity

is ensured

Very fastservice recovery

Service executionback-up

Back

27



EXAMPLE EXAMPLE –– 4. Hierarchical domain analysis4. Hierarchical domain analysis

Routes messages from network to listeners and forward asynchronous messages. Routes outgoing messages to the network.

Informs the active system service provider the availability of the user services of the own node.

Sends after the given time period a notification signal about the existence of the node in the network. Maintains the location map of the network. Sends a signal to the user services of the own node to start registration when first time connected to the network. Announce the availability of the system services

Contributes to the operation of distributed data storage. Creates, maintains and tracks connections to other units in order to share data. Allows data to be stored in local resources. Negotiates about the copying, transferring or deleting data if necessary.

Responsibility

R2.1

R2.1

R2.1, R6

R2.1, R5, R6

Family-specific R&A requirement

R1-S3, R2.2-S3Advertiser

R1-S3, R2.2-S3, R4-S3Observer

R1-S3, A1-S3, R2.2-S3, A3-S3, R8-S3

Location service

R7R1-S3, R2.2-S3, R4-S3, R8-S3

Data distribution

System-specific R&A requirements for S3

Service

back



EXAMPLE EXAMPLE –– 5. Quality representations5. Quality representations

R2.1

R2.1

R2.1, R6

R2.1, R5, R6

Family-specific requirement

R1-S3, R2.2-S3Advertiser

R1-S3, R2.2-S3, R4-S3

Observer

R1-S3, A1-S3, R2.2-S3, A3-S3, R8-S3

Location service

R7R1-S3, R2.2-S3, R4-S3, R8-S3

Data distribution

System-specific requirements

Service

back

28



SUMMARY OF QRFSUMMARY OF QRF

The QRF method • aims to enable quality evaluation at an early

phase of system development• includes steps and techniques for eliciting quality

requirements, and transforming and modeling them in product family architecture

• is suitable especially for product families, allowing to manage variable requirements

• helps in architecture evaluation• has been applied to two experiments (laboratory

and industrial)



FAMILY ARCHITECTURE EVALUATION (FAE)FAMILY ARCHITECTURE EVALUATION (FAE)

• WHY IS EVALUATION NEEDED?

• To find out what is the maturity of PFA

• To analyse if PFA takes (changed) business drivers into account

• To discover how emerging new products can be merged to PFA

• Benchmarking and assessment of PFA –improvements needed

29



FAMILY ARCHITECTURE EVALUATION FAMILY ARCHITECTURE EVALUATION -- FAEFAE

• Background

• FAE method• Steps• Comparison framework

• Application of the method • Structural interviews• Analysis of existing material• Industrial case studies

• Summary



BACKGROUNDBACKGROUND

• Evaluation criteria framework for PFE adoption • Business drivers, domains and core assets from

the viewpoints of• Organization culture and processes• Product family architecture • Assets management (development and

evolution)• Architectural views

• QADA with 4 views (Structure, Behavior, Deployment, Development) in two abstraction levels: conceptual and concrete

30



MATURITY LEVELS OF PRODUCT FAMILIESMATURITY LEVELS OF PRODUCT FAMILIES

VARIANT PRODUCTS

SOFTWARE PLATFORM

STANDARDIZED INFRASTRUCTURE

INDEPENDENT PRODUCT DEVELOPMENT

SELF-CONFIGURABLEPRODUCTS

Based on: Frank van der Linden et al. Software Product Family Evaluation, SPLC 2004



FAMILY EVALUATION FRAMEWORK (FEF)FAMILY EVALUATION FRAMEWORK (FEF)-- ARCHITECTURE DIMENSIONARCHITECTURE DIMENSION

Aspects Level 1 Level 2 Level 3 Level 4 Level 5 Product family architecture

not established

specified external components

common features captured

fully specified enforced

Product quality

ignored or ad-hoc

through infrastructure, over-engineering

inherited from platform

a key priority implemented as variation points

Reuse level ad-hoc external components

internal platform components

managed automatic generation of family members

Variability management

absent limited variation points in infrastructure

managed in platform level

many variation points and dependencies between them

automatic selection and verification of variants in variation points is optimized

Source: Frank van der Linden et al. Software Product Family Evaluation, SPLC 2004

31



OVERVIEW OF FAEOVERVIEW OF FAE

ANALYSIS DATA COLLECTEDBY STRUCTURAL INTERVIEWS OR FROM

OTHER SOURCESorganized based on the evaluation criteria

framework

REVIEW / INSPECTION OFARCHITECTURAL ARTIFACTS

ANALYZING RESULTS

EVALUATIONbased on FEF-A

- Interviews max 2 hours- Classified questions aboutbusiness, domain and technology- Different stakeholders- Other sources: experience reportsof PFE, measured data, analysisreports on successful products andprojects, business visions &strategies, marketing reports

- Up-to-date PFA documentation- 1-2 weeks for each review

- PFA Comparison framework:44 questions related to PFA andits relations to business,organization and process.

- Mapping results to FEF-Alevels considering 4 aspects and3 characteristics

Method steps Prerequisites and Instructions



PFA COMPARISON FRAMEWORKPFA COMPARISON FRAMEWORK-- Business to PFABusiness to PFA

1. Number of members in a product family2. Different parts; %/features; number of functional sub-

systems/components, %/total software3. Reasons for differentiation4. Assembling is based on existing components,

(re)used/modified and new components5. Variable quality requirements6. Variability management7. Customized 3rd party components

Variability

1. Number of 3rd party components2. Number of subcontractors/component providers

Openness

1. Driving force: technology, application, both2. Main functional properties3. Quality requirements4. Change frequency in a domain5. Life-cycle or customer specific features6. Trend in customer needs

DomainBusiness toPFA

ItemAspectDimension

32



PFA COMPARISON FRAMEWORK PFA COMPARISON FRAMEWORK -- PFAPFA

1.What are they?2.Architectural styles and patterns3.Design patterns4.Component model5.Appropriateness of the component model6.Separation of hardware-related variability

Core assets

1.Common properties2.Binding time

Variability

1.Common architecture for family members2.Platforms3.Shared components

Domainknowledge

1. Identified domains2.Reasons for their importance3.Visibility of domains in PFA

ContextPFA

ItemAspectDimension



PFA COMPARISON FRAMEWORK PFA COMPARISON FRAMEWORK -- PFA to PFA to processprocess and and organizationorganization

• PFA to process• Methods in architecting• Modeling languages• Validation practices• Selection of 3rd party components• Stakeholders of PFA• Guidelines (in practice)

• PFA to organization• Number of domain engineers• Applied standards and other constraints• PFE familiarity• MDA familiarity• Effort used for sharing domain/design knowledge• Importance of documentation in knowledge sharing

33



I I –– INTERVIEWSINTERVIEWSIDENTIFY IMPROVEMENTSIDENTIFY IMPROVEMENTS

• A separation of technology-driven and application-driven software into two different product families

• Two platforms for the relatively rarely changing components including the necessary mechanisms for managing quality attributes, variation points and variability dependencies

• Removing frequently changing software totally from the product families

• Regeneration of the product family (new software technologies, mechanisms for qualities, variations and dependencies)

• Quality and variability management for automatic testing



II II –– LITERATURE ANALYSISLITERATURE ANALYSISUNDERSTAND RATIONALE BEHIND PFEUNDERSTAND RATIONALE BEHIND PFE

• The FAE comparison framework was applied to analysing the collected material of existing case studies (19 product families)

• The method helped to organize, compare and distil meaningful similarities and differences

• Due to missing information all comparison items could not be handled

• Family architecture strategy selection method is defined based on the analysis results

• => Comparison framework is usefull for selecting a PFA approach and comparing PFAs of different organizations

34



III III -- APPLYING FAE TO INDUSTRIAL CASESAPPLYING FAE TO INDUSTRIAL CASESHOW & WHENHOW & WHEN

• FAE method was applied to 3 industrial cases• Input was collected in different ways:

• Interviews (several stakeholders)• Existing architecture descriptions• Technical meetings • Workshops

• Results were presented in a workshop• Discussion – not presentation - oriented• WHEN

• Initiation of a PFA• Modernization of a PFA• During establishing/modernizing PFA



SUMMARY OF FAESUMMARY OF FAE

• Comparison framework is a useful tool for evaluation• works in many situations

• inside a company/PF• between companies/PFs

• easy to adapt to different kinds of uses• integrator, system provider, software provider• integrated products, software products,

multitechnological products• usable for different purposes

• improvements identification• comparative analysis• minimizing risks by early evaluation• in repeatable use =>

• PF life cycle management

• The same approach is suitable for evaluating PFA relations to other FEF dimensions

35



CONCLUSIONSCONCLUSIONS

FAS • To be applied to an industrial case study• Metrics for collecting the needed information

(automatically)QRF

• Applied in industry• Tool support needed, especially for large software

systemsFAE

• Easy and adaptable• May be extended and used for collecting

measurements for FASIn the future, the methods will be adapted and applied to Open Source and Inner Source software development



REFERENCES REFERENCES –– Product Family ArchitecturesProduct Family Architectures

• Niemelä, E. Strategies of Product Family Architecture Development. To appear in SPLC 2005, 12 p

• Niemelä, E., Matinlassi, M., Taulavuori, A. Practical Evaluation of Software Product Family Architectures, The 3rd International Conference on Software Product Lines, SPLC3, August- September 2004, 130-145.

• Matinlassi, Mari. Comparison of software product line architecture design methods: COPA, FAST, FORM, KobrA and QADA. - Proceedings of the 26th International Conference on Software Engineering (ICSE 2004), Edinburgh, UK, 23 - 28 May 2004. (2004), 127 - 136.

• Dobrica, L., Niemelä, E. 2004. UML Notation Extensions for Product Line Architectures Modeling, The 5th Australasian Workshop on Software System Architectures (AWSA 2004), Melbourne, Australia, April 13-14, 2004, 44-51.

• Lago, P, Niemelä, E., van Vliet, H. Tool Support for Traceable Product Evolution, European Conference on Software Maintenance and Reengineering, CSMR, Tampere, Finland, March 24-26, 2004, 261-269

• Niemelä, E., Ihme, T. 2001. Product Line Software Engineering of Embedded Systems. Proceedings of SSR'01, Symposium on Software Reusability, Toronto, Ontario, Canada, May 18-20, 2001, pp. 118-125.

36



REFERENCES REFERENCES –– Quality Driven Architecture DesignQuality Driven Architecture Design

• Niemelä, E., Kalaoja, J., Lago, P. Toward an architectural knowledge base for wireless service engineering. IEEE Trans. on Software Engineering,Vol. 31, No 5, May 2005, pp. 361-379

• Purhonen, A., Niemelä, E., Matinlassi, M. Viewpoints of DSP Software and Service Architectures. In the Journal of Systems & Software. 2004. Vol. 69, No. 1-2, 57-73.

• Merilinna, Janne; Matinlassi; Mari. Evaluation of UML tools for model-driven architecture. 11th Nordic Workshop on Programming and Software Development Tool and Techniques NWPER'2004. Turku, 17 - 19 Aug. 2004. TUCS General Publications (2004)

• Niemelä, E., Matinlassi, M., Lago, P. Architecture-centric approach to wireless service engineering. The Annual Review of Communications. International Engineering Consortium. Vol. 56. October 2003, 875-889. ISBN: 0-931695-22-9.

• Matinlassi, M., Niemelä, E, Dobrica, L. Quality-driven architecture design and quality analysis method. A revolutionary initiation approach to a product line architecture. Espoo, VTT Electronics, VTT Publications 456, 2002, 128 p. + 10 p. ISBN 951-38-5967-3; 951-38-5968-1.

• Merilinna, J. 2005. A Tool for Quality-Driven Architecture Model Transformation. Espoo, VTT Electronics. 106 p. + app. 7 p. VTT Publications; 561ISBN 951-38-6439-1; 951-38-6440-5http://www.vtt.fi/inf/pdf/publications/2005/P561.pdf

• Immonen, A. and Niskanen, A. A tool for reliability and availability prediction. Accepted to the 31th EuromicroConference on Software Engineering and Advanced Applications. 2005, Porto, Portugal. 8 p.

• Merilinna, J. and Niemelä, E. A Stylebase as a Tool of Quality-Driven Software Architecture Modelling. In: Proceedings of the Ninth Symposium on Programming Languages and Software Tools, August 13-14, 2005, Tartu, Estonia. Pp. 97-111. ISBN 9949-11-113-7.



REFERENCES REFERENCES –– Quality EvaluationQuality Evaluation

• Immonen, A., A method for predicting reliability and availability at the architectural level. To appear in Research Issues in Software Product-Lines - Engineering and Management, Käkölä, T. & Dueñas, J.C. (Eds.), 2005, Springer.

• Immonen, A., Niemelä, E., Matinlassi, M. Evaluating the integrability of COTS components - software product family viewpoint. In: Testing Commercial-off-the-Shelf Components and Systems, Beydeda, Sami; Gruhn, Volker (Eds.), Jan. 2005, Springer-Verlag, ISBN: 3-540-21871-8,. 141-168.

• Matinlassi, M. Evaluating the portability and maintainability of software product family architecture: terminal software case study. - Proceedings of the 4th IEEE/IFIP Conference on Software Architecture (WICSA), 12 - 15 June 2004 Oslo, Norway, Magee, J., Szyperski, C., Bosch, J. (Eds). IEEE Computer Society (2004), 295 – 298

• Matinlassi, M., Niemelä, E. The impact of maintainability on component-based software systems. The 29th Euromicroconference, Component-based software engineering track. Antalya, Turkey, 3-5 Sep. 2003, 25-32.

• Dobrica, L., Niemelä, E. A Survey on Software Architecture Analysis Methods. IEEE Transactions on Software Engineering, Vol. 28, No 7, July 2002, 638-653.

• Dobrica, L., Niemelä, E. A strategy for analysing product-line software architectures. VTT Espoo: Technical Research Centre of Finland, VTT Publications 427, 2000, 124 p. ISBN 951-38-5598-8

• Dobrica, L.; Niemelä, E. 2000. Attribute-based product-line architecture development for embedded systems. Proceedings of the 3rd Australasian Workshop on Software and Systems Architectures. Sydney, 19 - 20 Nov 2000. IEEE. US (2000), 76 – 88.

• See QADA also at http://www.vtt.fi/qada/

37



OTHER REFERENCESOTHER REFERENCES

• van der Linden, F., Bosch, J., Kamsties, E., Känsälä, K., Obbink, H. Software Product Family Evaluation. SPCL 2004, Boston, USA,pp. 110-129

• Bosch, J. On the Development of Software Product-Family Components. SPLC 2004, Boston, USA, pp. 146-164.

• Bass, L., Clements, P., Kazman, R.. Software Architecture in Practice. Reading, Massachusetts: Addison-Wesley, 1998.

• Bosch, J. Design and Use of Software Architectures - Adopting and Evolving a Product line Approach, Addison Wesley, 2000. ISBN 0-201-67494-7.

• Hofmeister, C., Nord, R., Soni, D. Applied software architecture. Addison-Wesley, 1999.

• P. B. Krutchen. The 4+1 View Model of Architecture. IEEE Software, November 1995, pp. 42−50.

• Buhne, S., Chastek, G., Käkölä, T., Knauber, P., Northrop, L., Thiel, S.: Exploring the Context of Product Line Adoption. Lecture Notes in Computer Science, Vol. 3013. Springer-Verlag, Berlin Heidelberg New York (2003)

• Schmidt, K., Verlage, M.: The Economic Impact of Product Line Adoption and Evolution. IEEE Software, 19 (4), (2002), 50-57.

• Clements, P., Northrop, L.: Software Product Lines: Practices and Patterns. Boston, MA, USA: Addison-Wesley. (2002)

• van der Linden, F., Bosch, J., Kamsties, E., Känsälä, K., Krzanik, L., Obbink, H.: Software Product Family Evaluation. Lecture Notes in Computer Science, Vol. 3014. Springer-Verlag, Berlin Heidelberg New York (2003), 376-394

• Obbink, H., America, P., van Ommering, R., Muller, J., van der Sterren, W., Wijnstra, J. G.: COPA: A Component-Oriented Platform Architecting Method for Families of Software-Intensive Electronic Products. SPLC1, (2000)

• America, P., Rommes, E., Obbink, H.: Multi-View Variation Modeling for Scenario Analysis. Lecture Notes of Computer Science, Vol. 3013. Springer-Verlag, Berlin Heidelberg New York (2003)

• Wijnstra, J.G.: Evolving a Product Family in a Changing Context. Lecture Notes of Computer Science, Vol. 3013. Springer-Verlag, Berlin Heidelberg New York (2003).

VTT TECHNICAL RESEARCH CENTRE OF FINLAND - VTT Virtual project

Documents

Transcript of VTT TECHNICAL RESEARCH CENTRE OF FINLAND - VTT Virtual project