WIXLIB

ISO standardsISO 12207, ISO 15504 & ISO 9126ISACA – CETIC Meeting23 May 20071

IntroductionProcess standardsISO 12207 common framework forthe lifecycle of the software¾ Architecture of the software lifecycleprocesses (processes, activities, tasks)ISO 15504 also known as SPICE(Software Process Improvement andCapability Determination) "frameworkfor the assessment of softwareprocesses"¾ Derived from 12207 and CMMI2

Introduction (2)Product standardISO 9126 set of characteristics todescribe software product quality¾ Internal, external and use-related features¾ Each characteristic subcharacteristics metric to assess conformance withrequirements3

ISO 12207Software lifecycle processes4

Agenda1. Context and Purpose2. Scope3. History4. Basic concepts5

1. Context and PurposeDomain : software engineeringFocus : software lifecycle processesPurpose : to establish a common frameworkfor the life cycle of softwareÆ to foster mutual understanding amongbusiness partiesÆ to acquire, supply, develop, operate andmaintain softwareISO 122076

2. ScopeStakeholders: acquirers, suppliers, users etcApplication: corporate processes related toproject products and project servicesISO 12207 covers process definitions anddescriptionsISO 122077

3. HistoryISO 122078

3. History (2)ISO/IEC 12207 Sponsor : Joint Technical Committe 1 (JTC1) (Information Technology) ofInternational Organization for Standardization (ISO) andInternational Electrotechnical Commission 7 (IEC).Developer: Subcommittee 7 (SC7) (Software Engineering)Proposed in June 1988Published 1 August 1995Participants: Australia, Canada, Denmark, Finland, France,Germany, Ireland, Italy, Japan, Korea, Netherlands, Spain,Sweden, UK, USAISO 122079

4. Basic Concepts – Life cycle andarchitectureISO 1220710

4. Basic Concepts – Rules forpartitioning the life cycleModularityCohesion (Functional): Tasks in a process must be functionallyrelatedCoupling (Internal): Links between processes must be minimalAssociationIf a function is used by more than one process, then thefunction becomes a process in itselfIf Process X is invoked by Process A and Process A only, thenProcess X belongs to Process AResponsibilityEach process is under a responsibilityA function with parts under different responsibilities shall notISO 12207be a process11

4. Basic Concepts – The ProcessTreeISO 1220712

4. Basic Concepts – Rules forpartitioning a processA process is partitioned into PDCA activities based on the PDCAcycle principlesISO 1220713

4. Basic Concepts – Activity andTasksAn activity is divided into tasks, which are grouped intosimilar actionsBased on TQM PrinciplesEach party/participant has appropriate responsibilityISO 1220714

4. Basic Concepts – What 12207 isnotNot certifyingNot prescriptive, no how-tosNot a standard for methods, techniques & modelsdoes not prescribe management and engineeringmethodsdoes not prescribe computer languagesEtcNot a standard for metricsmany tasks need metrics and indicatorsbut prescribes no specific metrics/indicatorsreferences ISO/IEC 9126 for guidanceISO 1220715

ISO 15504 (SPICE)Software Quality16

Agenda1. Context and Purpose2. History3. Basic concepts4. CETIC products derived from ISO1550417

1. Context and PurposeNormalized structure devoted to managingrequirements related to a softwaredevelopment processModel for process management set ofrequirements/guidelines to assess/improvethose processesISO 1550418

2. HistoryEarly 1990’s: process improvement andcapability determination methodsdeveloped in several countriesÆ Internationalconsensus on the urgent need fora public domain standar for software processassessmentJune 1991 in London, Joint TechnicalCommittee 1/Sub-Committee 7 of theISO/IEC: resolution to develop aninternational standard on software processassessmentISO 1550419

3. Basic concepts - Process5 process categoriesCustomer-Provider Acquisition process (process for selectiong provider) Process for support to customerEngineering Process for analyzing requirements and designing the systemSupport Documentation processManagement Risk management processOrganization Process for managing human resourcesISO 1550420

3. Basic concepts - Process6 maturity levels for assessing the processes543210::::::optimizingquantitatively manageddefinedmanagedinitialincompleteTo assess a process, we define it as follows:Purpose/goalResults/attributes that should be met to reach asuccessful implementation of the processISO 1550421

3. Basic concepts - Process and maturitylevels (2)Example : process for software testing(1/2)6 niveaux de maturitéPurpose: to test the integrated softwareenprocessoptimisationResult of a successful implementation5of:theprévisibleAcceptance criteria are developed4in: orderto verify compliancewith requirements3 : établiThe integrated software is verified using the defined acceptance2 : gérécriteriaThe testing results are taken in 1 : réaliséA non-regression strategy is establishedin order to test the0 : incompletintegrated software again if software is modifiedThe regression testing is performed when necessaryISO 1550422

3. Basic concepts - Assessing each processFor each attribute:N not implementedP partly implementedL largely implementedF fully implemented 0 % 15 % 16 % 50 % 51 % 85 % 86 % 100 %A level is achieved ifThe attribute(s) of this level L or FFAttributes of lower levels FISO 1550423

Quality assuranceconfiguration management achieved leveltestinglevel 1buildinglevel 2PA3.2PA3.1PA2.2PA2.1PA1.1designlevel 3Requirements analysis3. Basic concepts - Example of NL1ISO 1550424

3. Basic concepts - ConclusionSPICE is very interesting to prepare an improvement planCan be applied to the way a team worksGives the opportunity to deploy progressively the action plan:By targeting first and foremost the most critical processesBy targeting the levels in ascending order On a mid-term: target level 2 On a long term: target level 3ISO 1550425

4. CETIC products - OWPL(Observatoire Wallon des Pratiques Logicielles)Model based on CMM and SPICE (ISO15504)Adapted to SMO’sgoal: improve software productionprocessesISO 1550426

4. CETIC products - OWPL (2)model structure:10 processes (each split up in practices):¾requirements management,¾project planification,¾project onfiguration management,¾outsourcing management,¾quality managemenet,¾process for capitalizing knowledgeSuccess factors organized in 4 categories:¾organization within the processes take place,¾the management policy,¾the human resources¾the « used » technical toolsISO 1550427

4. CETIC products - OWPL (3)Success story: PEPITeCETIC has assessed the PEPITo software withOWPLGoal: inform PEPITe about their softwaredevelopment practices to improve themÆ Improve their products and servicesCETIC has provided a complete assessmentreport recommendations to improve theirdevelopment practicesISO 1550428

4. CETIC products - NOEMIbased on existing standards such asISO/IEC15504The NOEMI assessment method has beendeveloped by Centre HENRI TUDOR(Luxemburg).Two goals:improve the perception of computer maturity in SMO’sor VSMO’smethodological tool for improving those companies’ SIISO 1550429

4. CETIC products - NOEMI (2)Assessment according to an exhaustive list of thetypical computer activities in SMO’s/VSMO’s dividedin 5 mentationISO 1550430

4. CETIC products - NOEMI (3)Success Story: GREISCH (Liège), Architects officeInterviews conducted with 3 types of users: One responsible within the computer department The director of the computer department 3 end-users (architects)CETIC has provided GREISCH with an assessment reporton their practices within the computer department andthe quality of the services/products delivered to the endusers (the architects) by the computer scientistsCETIC has also provided recommendations to improvetheir products and servicesISO 1550431

ISO 9126Software Product Quality32

Agenda1. Scope2. History3. Basic concepts4. CETIC products derived from ISO 912633

1. ScopeISO 9126 is an international standard forthe evaluation of software.It will be overseen by the project SQuaRE,ISO 25000:2005, which follows the samegeneral conceptsfour parts:quality model;external metrics;internal metrics;and quality in use metrics.ISO 912634

2. HistoryLate 1980’s: need for a framework assessingthe quality of a software product1991: Joint Technical Committee of theISO/IEC develops ISO 9126Standard revised in 2001Will be overseen by SQuaRE (ISO25000:2005)ISO 912635

3. Basic concepts – First partThe quality model established in the first partof the standard, ISO 9126-1, classifiessoftware quality in a structured set ofcharacteristics and sub-characteristics asfollows:ISO 912636

3. Basic concepts – First partISO 912637

3. Basic concepts – First part (2)Functionality - A set of attributes that bear onthe existence of a set of functions and their specifiedproperties. The functions are those that satisfystated or implied needs.Reliability - A set of attributes that bear on thecapability of software to maintain its level ofperformance under stated conditions for a statedperiod of time.Usability - A set of attributes that bear on theeffort needed for use, and on the individualassessment of such use, by a stated or implied set ofusers.ISO 912638

3. Basic concepts – First part (3)Efficiency - A set of attributes that bear on therelationship between the level of performance of thesoftware and the amount of resources used, under statedconditions.Maintainability - A set of attributes that bear on theeffort needed to make specified modifications.Portability - A set of attributes that bear on the abilityof software to be transferred from one environment toanother.ISO 912639

3. Basic concepts – First part (4)Each quality sub-characteristic (as adaptability)is further divided into attributes.An attribute is an entity which can be verified ormeasured in the software product.Attributes are not defined in the standard, asthey vary between different software products.ISO 912640

3. Basic concepts – First part (5)AssessGrid - Non functional using requirements: ISO-9126Security: dataintegrity for trustassessment,confidentialitySLA issuesUI leveldetailed in laterportal reviewTime overheadnot criticalResource overheadAligned onOpen SourcepracticesUnix/linuxReusableCCS target41

3. Basic concepts - Description ofthe standardInternal metrics are those which do notrely on software execution (staticmeasures).External metrics are applicable to runningsoftware.Quality in use metrics are only availablewhen the final product is used in realconditionsIdeally, the internal quality determinesthe external quality and external qualitydetermines quality in use.ISO 912642

3. Basic concepts – Internal metricMetric Name: Data corruption preventionPurpose: how complete is the implementation of data corruption preventionMethod of application: Count the number of implemented instances of datacorruption prevention as specified and compare with the number of instances ofoperations/access specified in requirements as capable of currption/destroyingdataMeasurement, formula and data element computations: X A/B with A number of implemented instances of data corruption prevention as specifiedconfirmed in review and B Number of instances of operation/access identified inrequirements as capable of corruption/destroying data Note: consider securitylevels when using this metricInterpretation of measured value: 0 X 1 with the closer to 1, the morecompleteMetric scale type: absoluteMeasure type: X count/countA countB countInput to measurement : Requirement specification, Design, Source code, ReviewISO 9126report43