Extending the ISO/IEC 9126-1 Quality Model with Non-Technical Factors for COTS Components Selection

1
Extending the ISO/IEC 9126-1 Quality Model with
Non-Technical Factors for COTS Components
Selection

• Juan Pablo Carvallo Xavier Franch
• ETAPATELECOM Univ. Politècnica
  Catalunya
• Cuenca (Ecuador) Barcelona
  (Spain)
• WoSQ'06
• Shanghai (China)

2
Motivation
COTS selection

• Evaluation of technical issues
• use of quality factors catalogues (quality
  models)
• but also
• Evaluation of non-technical issues
• licensing, supplier characteristics,
• Usually not integrated
• both in the process and in the style of
  description

3
Importance of non-technical issues
Consider the following real cases of selection

• Mail server
• on-line support
• Workflow system
• academic licensing
• Requirements management tool
• local support
• ERP system
• budget
• team experience

4
Our approach
Integration of technical and non-technical
factors in the framework of ISO/IEC 9126-1

• ISO/IEC 9126-1
• 6 caract.
• 27 subc.

5
NT-ISO/IEC design principles
Use of Reingruber and Gregory principles for ER

• Quality factor identification
• Quality factor naming
• syntactic conventions
• semantic conventions
• Quality factor definition
• Domain-related issues
• split-domain rule
• In addition
• Uniformity
• Abstraction

6
NT-ISO/IEC contents
Supplier Organizational structure
Supplier Positioning and strength
Supplier Reputation
Supplier Services offered
Supplier Support
Cost Licensing schema
Cost Ownership
Cost Guarantees
Cost Licensing costs
Cost Platform cost
Cost Implementation cost
Cost Network cost
Product History
Product Deliverables
Product Paramerization and customization
7
Extended NT-ISO/IEC structure
Up to 126 new features

• Decomposition
• Metrics
• Dependencies
• Overlapping

NT-attribute Metrics Example
Time of product in the market Time Ratio Time FloatYear 5 years
Versions curre-ntly in market Versions List(ltVersion Ordinal, Time Ratiogt) V1, 1 year V2, 2 years
Own manu-facture product Own Nominal Own Label(Yes, Not) Yes
8
Application
Constructing Request for Information forms

• Step 1 determining the architecture of the
  system
• Step 2 issuing RFIs
• Step 3 obtaining answers from suppliers

9
Application
Constructing Request for Information forms

• Step 1 determining the architecture of the
  system
• Step 2 issuing RFIs
• identification of intrinsec requirements
• elimination of abstract requirements
• debugging of ill-formed requirements
• implicit extension of requirements
• Step 3 obtaining answers from suppliers

10
Application
Constructing Request for Information forms

• Step 1 determining the architecture of the
  system
• Step 2 issuing RFIs
• Step 3 obtaining answers from suppliers
• make easier identification of mismatches
• identify potential risks
• define a prospective budget
• propose and initial schedule
• analyse the viability of the project

11
Conclusions
Contributions

• 3-level definition of factors
• alineation of technical and non-technical factors
• versatility
• use in tendering processes

12
Thanks!
Questions? GESSI URL http//www.lsi.upc.ed
u/gessi