Quality Driven Family Architecture Development

VTT TECHNICAL RESEARCH CENTRE OF FINLAND

QADA®

Quality Driven Family Architecture Development Prof. Eila Niemelä VTT Technical Research Centre of Finland E-mail: [email protected]

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

SPLC 2005 in Rennes, France, 26 Sept. 2005

© Eila Niemelä

1


MOTIVATION • 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? SPLC 2005 in Rennes, France, 26 Sept. 2005

© Eila Niemelä

2

1


TUTORIAL 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


© Eila Niemelä

3


INTRODUCTION • PRODUCT FAMILY ENGINEERING • QUALITY ATTRIBUTES • PRODUCT FAMILY ARCHITECTURE • SOFTWARE ARCHITECTURE AND QUALITY


© Eila Niemelä

4

2


PRODUCT FAMILY ENGINEERING


© Eila Niemelä

5


QUALITY ATTRIBUTES IN STANDARD(S) INTERNATIONAL STANDARD ISO/IEC 91269126-1, Quality model


© Eila Niemelä

6

3


QUALITY ATTRIBUTES IN LITERATURE diversity me

flex ibil ity

asu rab ility

performance p sim

t lici

scalability

ili sab reu

inte

ty

inte rop er

y

ty bili gra

abi lity

user-friendliness

wra ppa b

ility

ility rab sfe n a r t safety

QUALITIES

EXECUTION - performance - security - availability - usability - scalability - reliability - interoperability SPLC 2005 in Rennes, France, 26 Sept. 2005 - adaptability

EVOLUTION - maintainability

© Eila Niemelä

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

7


SOME DEFITIONS OF QUALITY ATTRIBUTES Quality attribute Availablity Reliablity

Modifiability Maintainability

Flexibility

Scalability

Description Availability measures the proportion of time the system/service is up and running. 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. The ability to make changes quickly and costeffectively. 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. 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. The ease with which a system or component can be modified to fit the problem area.


© Eila Niemelä

8

4


ARCHITECTUREARCHITECTURE-CENTRIC FAMILY ENGINEERING

Group of products share

Product Product Product

share

Managed Set of Features

Product Family Architecture

are built Component Component Componet Component Component


© Eila Niemelä

9


ORTHOGONAL PROPERTIES OF SOFTWARE ARCHITECTURE Conceptual

Abstraction

Realizational Dynamic Static

Viewpoint Hierarchy


© Eila Niemelä

10

5


SOFTWARE ARCHITECTURE & QUALITY ARCHITECTURE DESCRIPTION

complement each other

Multiple views

Taxonomy of orthogonal properties

Abstraction level

Decomposition of functionality -conceptual• •

Realization of the conceptual abstraction

commonalties variabilities

• • • •

Logical Concurrency

maintainability modifiability reusability portability


• • •

Dynamism

Physical

performance reliability security

• • •

Aggregation level

Development

availability capacity bandwidth

© Eila Niemelä

managing administrative control

11


QADA viewpoints


© Eila Niemelä

12

6


INITIATION AND EVOLUTION OF PRODUCT FAMILY ARCHITECTURE


© Eila Niemelä

13

© Eila Niemelä

14


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


7


FAS – FAMILY ARCHITECTURE SELECTION


© Eila Niemelä

15


CONTENT

¾METHOD AND MATERIAL ¾STRATEGY EVALUATION FRAMEWORK ¾PFA map ¾PFE strategy selection method ¾SUMMARY


© Eila Niemelä

16

8


RESEARCH 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


© Eila Niemelä

17


CASE 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


© Eila Niemelä

18

9


PFA MAP


© Eila Niemelä

19


FINDINGS PFE 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)


© Eila Niemelä

20

10


FINDINGS – PFE ROLES & RESPONSIBILITIES Role

Responsibilities

PF leader

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

PF architect

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).

Lead designer

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

Domain/component owner

Quality of the domain architecture and its components.

Support teams/persons

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

Architecture board (AB)

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

Product architect

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

Project/product manager

Management of product development and deployment.


© Eila Niemelä

21


FINDINGS – POTENTIAL OF PFE PFA approach

Requires/provides/constraints

Potential

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

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 variations are maintainable and a product family is extensible.

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

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.

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

Internal platform as a means of communication and management

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

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

Product platform as a means of management and communication

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

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

Packaged services as a means of management, communication and abstraction

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

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


© Eila Niemelä

22

11


PFE STRATEGY SELECTION METHOD

Phases: 1. Assumptions evaluation 2. Target PFA decision 3. PFE strategy selection


© Eila Niemelä

23


PHASE 1: ASSUMPTIONS 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.


© Eila Niemelä

24

12


PHASE1PHASE1- EVALUATION CRITERIA

Issue

Criterion

Customer needs

Predictability

Shortening delivery times

Cutting edge

Cost structure (software/products)

Profitability

Customisation

Variability

Quality

Customer satisfaction


© Eila Niemelä

25


PHASE 22- STEP1: TARGET 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


© Eila Niemelä

26

13


PHASE 2 - STEP2: IDENTIFY SUCCESS FACTORS AND THEIR IMPORTANCE Success factor

Criteria

PFA alternative

Managing customer needs

Customer satisfaction Time-to-market

Configurable features/components base Configurable product family base

Key competence

Cutting edge

Internal platform, Configurable features/components base

New opportunities

Cutting edge

Platform product Packaged services

Effective work organisation

Cost effectiveness

PFA

Evolution management

Cost effectiveness

PFA Configurable features/components base


© Eila Niemelä

27


PHASE 2 - STEP3: STEP3: ESTIMATE ROI In v e s tm e n t

• Return on investment is estimated for the different ways of implementing PFA C o n g iru g a b le P ro d u c t F a m ily B ase

• Criteria: investment and potential • Economic models needed • Example is an intuitive estimation based on the collected data.

PFA

C o n fig u ra b le F e a tu re s /C o m p o n e n ts B ase P la tfo rm P ro d u c t

In te rn a l P la tfo rm

P ackaged S e rv ic e s

P o te n tia l SPLC 2005 in Rennes, France, 26 Sept. 2005

© Eila Niemelä

28

14


PHASE3: PFE STRATEGY SELECTION

Strategy

Means

Criteria

1. Minimizing risks

internal platform

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

2. Extending market share

platform product

high technological competence, openness, market share, organization model

3. Maximizing end-user satisfaction

packaged services

familiarity with end-user needs

4. Balancing cost and customer satisfaction

internal platform + configurable features /components base

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


© Eila Niemelä

29


PHASE3: PFE STRATEGY SELECTION Strategy

Means

Criteria

5. Maximizing customer satisfaction

Configurable product family base

quality of products, short delivery times

6. Balancing cost and potential

PFA

complexity and variability, market share, new markets

7. Balancing cost, customer satisfaction And potential

PFA + Configurable features/compoentsbase

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

8. Maximizing potential

PFA + Configurable features/components base + Platform product + Packaged services

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


© Eila Niemelä

30

15


SUMMARY 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.


© Eila Niemelä

31


QRFQUALITY REQUIREMENTS OF A SOFTWARE FAMILY


© Eila Niemelä

32

16


INTRODUCTION • 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 SPLC 2005 in Rennes, France, 26 Sept. 2005

© Eila Niemelä

33


METHOD OVERVIEW The QRF consists of five steps: 1. 2. 3. 4. 5.

Impact analysis Quality analysis Variability analysis Hierarchical domain analysis Quality representations


© Eila Niemelä

34

17


QRF & QADA

2. Quality analysis

3. Variability analysis

4. Hierarchical domain analysis

1. Impact analysis

5. Quality representations


© Eila Niemelä

35


1. 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 SPLC 2005 in Rennes, France, 26 Sept. 2005

© Eila Niemelä

36

18


2. 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 SPLC 2005 in Rennes, France, 26 Sept. 2005

© Eila Niemelä

37

example


3. 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


© Eila Niemelä

38

19


4. 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


© Eila Niemelä

39


5. 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 SPLC 2005 in Rennes, France, 26 Sept. 2005

© Eila Niemelä

40

20


QUALITY REPRESENTATIONS: styles 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


© Eila Niemelä

41


QUALITY REPRESENTATIONS: quality 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

Example

• 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 SPLC 2005 in Rennes, France, 26 Sept. 2005

© Eila Niemelä

42

21


APPLYING 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 SPLC 2005 in Rennes, France, 26 Sept. 2005

© Eila Niemelä

43


Case example: A Distributed Services Platform (DiSeP) DiSeP) • 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.


© Eila Niemelä

44

22


Example – 1. Impact analysis System family architect

Middleware service capability to recover Data replication Data consistency is verified

Emergency intervention application

System 3 architect

Service availability is very high

End user (doctor, police)

Response time is short

Middleware Emergency application developer

Fault occurrence is prevented

Messages are not lost and integrity is ensured Very fast service recovery Service execution back-up

back SPLC 2005 in Rennes, France, 26 Sept. 2005

© Eila Niemelä

45


Example – 2. Quality analysis - QR identification & prioritization

Req ID

Requirement description

Stakeholder

Importance

R2.1

Middleware services are able to recover

System family architect

high

R5

Data consistency is verified in every 5 seconds


low

R1-S3

The probability of failure is not over 0,01

End user of application

high

R2.2S3

Recovery time of the middleware services is 3 seconds

End user of application

medium


© Eila Niemelä

46

23


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

• Mapping family-specific R&A requirements to functionality R&A requirement

Corresponding service

R2.1

All the involved basic, system and communication services

R5

Data distribution

R6

Data distribution, Location service

R7

Data distribution


© Eila Niemelä

47


Example – 2. Quality analysis - Order of evaluation Evaluation level

Evaluation criteria

Corresponding requirement

Level 1

System family-specific requirements

R2.1, R5, R6, R7

Level 2

High level system-specific requirements

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

Level 3

Medium level system-specific requirements

R2.2-S3, A3-S3, A4S3

Level 4

Low level system-specific requirements

-


© Eila Niemelä

48

24


Example – 2. Quality analysis - Selecting an architectural style and doing the tradetrade-off analysis •

NFR framework for detecting conflicts Reliability

Recovery +++

Performance

Data replication +++

Forward recovery +++

Backward recovery ++

Layered architecture

Space performance +

Time performance +++

Remote unit +++

Local +

Simplex

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

Implicit invocation

Black board

49


Example – 2. Quality analysis - Defining criteria for R&A evaluation

Criteria for evaluation of the DiSep system family

Back

Evaluation level

Evaluation criteria

Corresponding requirement

Level 1

System family-specific requirements

R2.1, R5, R6, R7

Level 2

High level system-specific requirements

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

Level 3

Medium level system-specific requirements

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

Level 4

Low level system-specific requirements

-

Evaluation criteria

Req.ID

Importance

Impacted architectural elements

Service capability to recover

R2.1

medium

All basic, system and communication services

Data consistency verification Data loss prevented in error situations

R5

medium

Data distribution

R7

medium

Data distribution

Data replication

R6

low

Data storage, data distribution, location service


© Eila Niemelä

50

25


Example – 3. Variability analysis

System

Functionality

R&A importance

S1: A middleware for game application

Light functionality

Low

S2: A middleware for health care application

Restricted functionality

Medium

S3:A middleware for emergency intervention application

Full functionality

High


© Eila Niemelä

51


Example – 3. Variability analysis -Describing variability in R&A qualities Game application

Middleware

No breaks in communication

End user (game palyer)

Reliability is at low level

Message loss is medium low Game application developer

Service recovery at medium rate User notification of failures/shutdowns

Service recovery in medium time

System 1 architect

Middleware

Health care application


Middleware service capability to recover Data replication

End user (medical worker)

Data is always correct Reliability is at high level Recovery time is fast

Health care application developer

Back

Data correctness is ensured

Service availability is very high Response time is short

Messages are not lost Service recovery at medium rate

Emergency intervention application

End user (doctor, police)

System 2 architect

Data consistency is verified

System 3 architect

Middleware Emergency application developer

Fault occurrence is prevented SPLC 2005 in Rennes, France, 26 Sept. 2005

© Eila Niemelä

Messages are not lost and integrity is ensured Very fast service recovery

52

Service execution back-up

26


EXAMPLE – 4. Hierarchical domain analysis Service

Responsibility

Family-specific R&A requirement

System-specific R&A requirements for S3

Data distribution

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.

R2.1, R5, R6

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

Location service

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

R2.1, R6

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

Advertiser

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

R2.1

R1-S3, R2.2-S3

Observer

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

R2.1

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


© Eila Niemelä

53


EXAMPLE – 5. Quality representations Service

Familyspecific requirement

System-specific requirements

Data distribution

R2.1, R5, R6

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

Location service

R2.1, R6

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

Advertiser

R2.1

R1-S3, R2.2-S3

Observer

R2.1

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


© Eila Niemelä

54

27


SUMMARY 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)


© Eila Niemelä

55


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


© Eila Niemelä

56

28


FAMILY ARCHITECTURE EVALUATION - FAE • Background • FAE method • Steps • Comparison framework • Application of the method • Structural interviews • Analysis of existing material • Industrial case studies • Summary


© Eila Niemelä

57


BACKGROUND • 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


© Eila Niemelä

58

29


MATURITY LEVELS OF PRODUCT FAMILIES

SELF-CONFIGURABLE PRODUCTS

VARIANT PRODUCTS

SOFTWARE PLATFORM

STANDARDIZED INFRASTRUCTURE

INDEPENDENT PRODUCT DEVELOPMENT

Based on: Frank van der Linden et al. Software Product Family Evaluation, SPLC 2004 SPLC 2005 in Rennes, France, 26 Sept. 2005

© Eila Niemelä

59


FAMILY EVALUATION FRAMEWORK (FEF) - ARCHITECTURE DIMENSION

Aspects Product family architecture

Level 1 not established

Product quality

ignored or ad-hoc

Reuse level

ad-hoc

Variability management

absent

Level 2 specified external components through infrastructure, overengineering external components

Level 3 common features captured inherited from platform

Level 4 fully specified

Level 5 enforced

a key priority

implemented as variation points

internal platform components

managed

limited variation points in infrastructure

managed in platform level

many variation points and dependencies between them

automatic generation of family members automatic selection and verification of variants in variation points is optimized

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


© Eila Niemelä

60

30


OVERVIEW OF FAE Method steps ANALYSIS DATA COLLECTED BY STRUCTURAL INTERVIEWS OR FROM OTHER SOURCES organized based on the evaluation criteria framework

REVIEW / INSPECTION OF ARCHITECTURAL ARTIFACTS

ANALYZING RESULTS

EVALUATION based on FEF-A SPLC 2005 in Rennes, France, 26 Sept. 2005

Prerequisites and Instructions - Interviews max 2 hours - Classified questions about business, domain and technology - Different stakeholders - Other sources: experience reports of PFE, measured data, analysis reports on successful products and projects, business visions & strategies, marketing reports - Up-to-date PFA documentation - 1-2 weeks for each review

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

- Mapping results to FEF-A levels considering 4 aspects and 3 characteristics © Eila Niemelä

61


PFA COMPARISON FRAMEWORK - Business to PFA Dimension

Aspect

Item

Business to PFA

Domain

1. Driving force: technology, application, both 2. Main functional properties 3. Quality requirements 4. Change frequency in a domain 5. Life-cycle or customer specific features 6. Trend in customer needs

Openness

1. Number of 3rd party components 2. Number of subcontractors/component providers

Variability

1. Number of members in a product family 2. Different parts; %/features; number of functional subsystems/components, %/total software 3. Reasons for differentiation 4. Assembling is based on existing components, (re)used/modified and new components 5. Variable quality requirements 6. Variability management 7. Customized 3rd party components


© Eila Niemelä

62

31


PFA COMPARISON FRAMEWORK - PFA Dimension Aspect

Item

PFA

Context

1. Identified domains 2. Reasons for their importance 3. Visibility of domains in PFA

Domain knowledge

1. Common architecture for family members 2. Platforms 3. Shared components

Variability

1. Common properties 2. Binding time

Core assets

1. What are they? 2. Architectural styles and patterns 3. Design patterns 4. Component model 5. Appropriateness of the component model 6. Separation of hardware-related variability


© Eila Niemelä

63


PFA COMPARISON FRAMEWORK - PFA to process and organization •

•

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


© Eila Niemelä

64

32


I – INTERVIEWS IDENTIFY 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 SPLC 2005 in Rennes, France, 26 Sept. 2005

© Eila Niemelä

65


II – LITERATURE ANALYSIS UNDERSTAND 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


© Eila Niemelä

66

33


III - APPLYING FAE TO INDUSTRIAL CASES HOW & 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 SPLC 2005 in Rennes, France, 26 Sept. 2005

© Eila Niemelä

67


SUMMARY 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 SPLC 2005 in Rennes, France, 26 Sept. 2005

© Eila Niemelä

68

34


CONCLUSIONS 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 systems FAE • Easy and adaptable • May be extended and used for collecting measurements for FAS In the future, the methods will be adapted and applied to Open Source and Inner Source software development SPLC 2005 in Rennes, France, 26 Sept. 2005

© Eila Niemelä

69


REFERENCES – Product 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.


© Eila Niemelä

70

35


REFERENCES – Quality 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: 0931695-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; 561 ISBN 951-38-6439-1; 951-38-6440-5 http://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 Euromicro Conference 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.


© Eila Niemelä

71


REFERENCES – Quality 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 Euromicro conference, 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/


© Eila Niemelä

72

36


OTHER 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).


© Eila Niemelä

73

37

Quality Driven Family Architecture Development

Quality Driven Family Architecture Development

Suggest Documents

Quality Driven Family Architecture Development SPLC'05 Tutorial 26 ...

Quality-driven architecture development using ... - Semantic Scholar

Quality-Driven Architecture Design and Quality

Quality Attribute Driven Agile Development

Quality-Driven Software Architecture Composition1 - Department of ...

Architecture Driven Development for Cyber-Physical Systems

Model Driven Architecture and Ontology Development

A multimedia ontology-driven architecture for autonomic quality of ...

Towards Model Driven Architecture in Academic Quality Assurance ...

MDA (Model-Driven Architecture)

Contract Driven Development = Test Driven Development - CiteSeerX

and Architecture-Driven Development in the Context of ... - Uni-Augsburg

Model-Driven Development of a Web Service-Oriented Architecture ...

enhancing cloud saas development with model driven architecture

Model- and Architecture-Driven Development in the ... - Informatik

Model-Driven Development of a Web Service-Oriented Architecture

Architecture-driven Problem Decomposition - CiteSeerX

Architecture-Driven Reliability and Energy

Security in Model-Driven Architecture

Architecture-driven Problem Decomposition - CiteSeerX

Model-Driven Autonomic Architecture

Enterprise Architecture & Security Architecture Development

Quality gates in use-case driven development (PDF Download ...

Toward Quality-Driven Development of 3D Computer Games