Download pdf - Application Guidance for ISO/IEC 15288 (IEEE Std 15288 ... Guidance on ISO-IEC 15288... · Copyright Project Performance (Australia) Pty Ltd 2009 Page 3 of 14 P045‐004509‐1 and

CopyrightProjectPerformance(Australia)PtyLtd2009 Page1of14P045‐004509‐1

ApplicationGuidancefor:ISO/IEC15288(IEEEStd15288 ‐2008)‐SecondEdition2008‐02‐01

Systemsandsoftwareengineering–SystemLifeCycleProcesses

byRobertHalligan,FIEAust

1. BackgroundISO/IEC15288:2008isaprocessstandardofconsiderablesignificance,intendedtohelp:

• anorganizationestablishanenvironmentofdesiredprocesses;

• aprojectselect,structureandemploytheelementsofanestablishedenvironmenttoprovideproductsandservices; and

• anacquirerandasupplierdevelopanagreementconcerningprocessesand

activities.Viatheagreement,theprocessesandactivitiesintheInternationalStandardareselected,negotiated,agreedtoandperformed.

ISO/IEC15288:2008isalsointendedforusebyprocessassessors—toserveasaprocessreferencemodelforuseintheperformanceofprocessassessmentsthatmaybeusedtosupportorganizationalprocessimprovement.Theexperienceoftheauthoristhatprocessstandardsdonotnecessarilyalwaysachievetheobjectivesestablishedforthem.YearsofparticipationinISO/IECandotherstandardsdevelopmenteffortsinthefieldofsystemsengineeringleadstheauthortoconcludethatprocessstandardsalmostalwaysrepresentthelowestcommondenominatorofagreementamongstparticipants.Further,processstandardsareoftendevelopedinhighlypoliticalenvironmentsrepletewithpoliticalagenda.Asaconsequence,publishedstandardsmaybelessthanperfect.Thepurposeofthispaperistoprovideinformationforconsiderationbyanyuser,orpotentialuser,ofISO/IEC15288:2008,withaviewtomaximisingvaluethatcanbeachievedinrelationtoISO/IEC15288:2008practices,andminimisinganylossthatcouldarisefromuseofISO/IEC15288:2008practices.

2. ISO/IEC15288:2008 ApplicationGuidance.Applicationguidanceisprovidedintabularform,keyedtotheparagraphnumbersofISO/IEC15288:2008againstwhichguidanceisprovided.

15288Para ApplicationGuidance1.1Scope Thestandardstatesthatitmaybeappliedatanylevelinthe

hierarchyofasystem’sstructure,andmaybeconfiguredwithhardware,butthengoesontosay“whenthesystemelementishardware,refertootherinternationalstandardsoutsidethescopeofSC7”.Thestatementsappeartobecontradictory.Apartfromunitaryelementsthathavenointernalstructure,e.g.aconventionalcoinformedfromamaterial,hardwareelements(includinginformationtechnology)areinvariablysystems, inaccordancewith15288anddictionarydefinitions.Theexclusionofpurelyhardwareelementsfromcoverageofthestandard,ifintended,isunfortunate,assomeofthemosteffectiveimplementationsofsystemsengineeringthatIhavefoundhavebeenincompanieswhich engineerhardwareproducts,andusesystems

www.ppi-int.com


engineeringasamajortoolforachievingcustomersatisfactionandcommercialsuccess.Severity:8

4.9enablingsystem

ThedefinitioninISO/IEC15288:2008ofan“enablingsystem”admitsthepossibilityofan“enablingsystem”contributingdirectlytothefunctionofthesystem‐of‐interest,andthereforebeingapartofthesystemofinterest.Theverb“supports”admitsanysystemwhichinteroperateswiththesystem‐of‐interest.Forthesereasons,thedefinitionisinappropriate.Thedefinitionisatoddswiththeconceptsofconcurrentengineering(alsoknownassimultaneousengineering),aconceptwhichtheconceptofenablingsystemsisfundamentallyintendedtosupport.OnlytheexampleinISO/IEC15288:2008ofaproductionsystemasanenablingsystemhelpscorrecttheimpressionconveyedbythedefinition.Amoresuitabledefinitionofanenablingsystemis“asystemwhichenablesoneormorephasesofthelife‐cycleofthesystem‐of‐interest,whilstnotitselfbeingapartofthesystem‐of‐interest”.NOTE. Theconsequenceofasystem‐of‐interest/enablingsystemrelationshipisthattheinternaldesignofonedependsontheinternaldesignoftheother,oftenleadingtothepracticeofconcurrentengineering.Severity:6

4.22qualification

Thedefinitionofqualificationfailstodifferentiatebetweenthemanagementactionofdeeminganitemqualified,usuallyforadefinedpurpose,andthetechnicalactivityofverifyingthatanitemcomplieswiththerequirementswhichapplytothatitem.TheISO/IEC15288:2008definitionofqualificationisinconsistentwiththeOxfordEnglishDictionary(OED)andthereforeinconflictwiththeISODirectives(therulesfordevelopingISOstandards).Thedistinctionbetweenqualificationandverificationisvery,veryusefulinmanagingtechnicalprojects,butislostinISO/IEC15288:2008. Severity:4

4.27security TheinclusioninISO/IEC15288:2008ofreliabilitywithinthedefinitionofsecurityishighlyunconventionalandnotsupportedbytheOED.Thedisciplinesofreliabilityengineeringandsecurityengineeringaresubstantiallydifferentastoknowledgebaseandmethods.Severity:2

4.31system ThedefinitioninISO/IEC15288:2008of“system”isinfactadefinitionofanengineeredsystem,notadefinitionofasystemingeneral.Thedefinitionisflawedasadefinitionofanengineeredsystembylimitingto“forastatedpurpose”.Isasystemengineeredtoaknownbutunstatedpurposenotasystem?Severity:1

4.34task ThisisanobtusedefinitionnotwellsupportedbyOED.Severity:1

4.37validation Thedefinitionofvalidation,byinvokingtheflawedISO9000:2005definition,createsthesameproblemthatexistswithISO9000:2005

www.ppi-int.com


andISO9001:2008.Validationisasub‐categoryofverificationunderthisISO9000:2005definition.Thedefinitiondepartsfromthevastlymorewidelyused,andhighlybeneficialdistinctionbetweenverificationandvalidation:verification–doestheitemcomplywiththerequirementsfortheitem(OEDdefinitionofrequirement);validation–doestheitemsatisfytheneedfortheitem(OEDdefinitionofneed).Thisdistinctionbetweenverificationandvalidationcomesaboutbecauseoftherealitythatrequirementscanbewrong,andrequirementsareinevitablyincomplete.Thus,itispossibletosatisfyrequirements,butfailtosatisfytheneed.Todevelopsuccessfulsystems,wemustbeconcernedwithbothmeetingrequirementsandsatisfyingneed.Severity:10

5.1.2Systems Thereferenceto“itsarchitectureanditssystemelements”isconfusingandlackslogic,sincetheidentificationofthesystemelementsisapartofthe(physical)architectureofasystem.Severity:2

6.1.1.1Purpose(ofAcquisitionProcess)

ThepurposeoftheAcquisitionProcessisnotonlytoobtainaproductorserviceinaccordancewithrequirements(imperatives);itisalsotoacquirethemostoveralleffective(best)amongstsolutionalternatives.Severity:6

6.1.1.3a)2) Goalsandvaluerelationshipsneedalsotobeincluded,wheregoalsexist.Severity:6

6.1.2.3a) Theheadingof6.1.2.3a)isincorrect.Thesupplierrespondstoarequestfortender(orrequestforproposal)withatender.Theacquirerrespondstothetender(proposal)byacceptingit,rejectingit,ornegotiatingchange.Severity:3

6.1.2.3b) Therearemanycircumstanceswhereitwillbeentirelyappropriateforasuppliertopreparearesponsethatdoesnotsatisfythesolicitation,e.g.wheresomerequirementsinthesolicitationareinfeasibleorconflicting,orwherethesupplier’sinterestsarebestservedbymakingacounter‐offer.Asupplier,tobeabletoclaimcompliancewithISO/IEC15288:2008,mustonlysubmitfullycomplianttenders.Thatisabsurd.Severity:8

6.2.2.1Purpose(ofInfrastructureManagementProcess)

Thisparagraphneedstoemphasizethestatusoftheinfrastructureelementsaselementsofoneormoreenablingsystems(e.g.ProjectSystem,ProductionSystem,MaintenanceSystem),theelementsneedingtoformpartofanoptimumdesignofeachrespectiveenablingsystem,complementingandinbalancewiththehumanelementsoftheenablingsystem,andsubjectintheirdevelopmenttothepracticeofconcurrentengineering.Thiscriticallyimportantrelationshipisignored,exceptforanobliquereferencein6.2.2.3b)2).Severity:6

6.2.4.1Purpose Thisparagraphneedstoemphasizethestatusofhumanresourcesas

www.ppi-int.com


(ofHumanResourceManagementProcess)

elementsofoneormoreenablingsystems(e.g.ProjectSystem,ProductionSystem,MaintenanceSystem),needingtoformpartofanoptimumdesignofeachenablingsystem,complementingandinbalancewiththeinfrastructureelementsoftheenablingsystem,andsubjectintheirdevelopment(e.g.bytraining)tothepracticeofconcurrentengineering.Thiscriticallyimportantrelationshipisignored.Severity:7

6.2.5.3b)2) Basingqualityobjectivesonstakeholderrequirementsalonereliesonthoserequirementsbeingconsistentwith,andanadequatestatementof,stakeholderneeds.Thisisrarelythecase.Qualityobjectivesmustbebasedonstakeholderrequirements,valuesandneeds,tobestservethestakeholders.

6.3.1.1Purpose(ofProjectPlanningProcess)

ThestatusoftheProjectSystemasanenablingsystem,subjectinitsdevelopmenttothepracticeofconcurrentengineeringwithrespecttothesystem(s)tobeengineered,needstobeemphasized.Thiscriticallyimportantrelationshipisignored.Manyaprojecthasbeenseriouslycompromisedbyplansandtechnicalrealities/decisionsneverhavingbeenaligned,orbybecomingmisaligned.Severity:7

6.3.1.3c)1) Inrequiringaplanfortechnicalmanagementandexecutionoftheproject,asopposedtooneorasetofplans,ISO/IEC15288:2008rulesouttheuseofempoweredIntegratedProductTeams(IPTs),thathavebeensosuccessfulinshorteningtimeframes,reducingcost,andincreasingproductquality.AnempoweredIPTwilldoitsownplanning,withinenterprise‐wideandprojectwideconstraints,andconsistentwithhigherlevelplanningwhichgeneratesthetaskingoftheIPT.Severity:7

6.3.3DecisionManagementProcess

PlacingdecisionmanagementasaProjectprocesscanconveytheimpressionthattechnicaldecisionscanandshouldbereferredto,andmadeby,thoseinaprojectmanagementrole.ThisisatoddswiththeprinciplesofIPTs,whichhavebeenenormouslysuccessful.RealIPTsareempoweredtomakedecisionswithintheirboundsofassignedresponsibilityforrealizationofasystemorasystemelement.ThisDecisionManagementprocessneedstolinkstronglyintothetechnicalprocessesthatinvolvedecisionmaking.Severity:5

6.3.4RiskManagementProcess

NotwithstandingitsISO/IEC16085‐AS4360heritage,thiswholesectionofthestandardispoorindeed,primitive,missingthepointregardingrisk,andregardingeffectiveriskmanagement:

• riskisexpectedloss,notathingthatcouldgowrong(that’sathreat)

• riskiswithreferencetoadefinedlevelofvaluedoutcome,e.g.cost,schedule,capability,safety,nationalsecurity,socialbenefit,politicaloutcome,etc

• riskhastheingredientsofthevalueoftheoutcome,whatcangowrongthatthreatensthatoutcome,andhowvulnerableweareifthatthreatisrealized.Whenthese

www.ppi-int.com


ingredientsandtheirprobabilitiesareconvolved,weendupwitharelativeprobabilityofdifferentdegreesoflosswithrespecttoavaluedoutcome,duetoasetofthreatsrelevanttothatoutcome.Inamajorproject,thereareusuallythousandsofthreatsconttributingtothelevelofriskwithrespecttoavaluedoutcome(e.g.contributingtothecostrisk).

• effectiveriskmanagementbeginswithanunderstandingofrisk!

• effectiveriskmanagementtheninvolvesensuringthatuncertainties(leadingtoriskandopportunity)arefactoredintoallprojectdecisions,regardlessofwhomakesthem

• effectiveriskmanagementreliesonpeoplewhoaremakingdecisions,doingsoonanexpectedvaluebasis(value,takingintoaccountbalanceofprobabilities),eitherinformally,orforimportantdecisions,formally.

Severity:9

6.4.1.1Purpose(ofStakeholderRequirementsDefinitionProcess)

Thestatementofpurposeneedstoincludetheresolutionofconflictsbetweenstakeholderrequirements,especiallyconflictsbetweentherequirementsofdifferentstakeholders.Severity:4

6.4.1.2Outcomes

Thestatement“Stakeholderrequirementsforvalidationareidentified”isambiguousandincomplete.Thestatementshouldread“Stakeholderrequirementsforsystemverificationandsystemvalidationareidentifiedandspecified”Severity:5

6.4.1.2Outcomes

Stakeholdermeasuresofeffective,goalsandvaluerelationshipsarealsoanimportantoutcome.Withoutthisinformation,developersofsolutioncanhavenosoundbasisforselectingbetweenfeasiblesolutionalternatives,andnobasisforsolutionoptimisation.Severity:7

6.4.1.3ActivitiesandTasks

Thesectionneedstorecognizeandreflectprimarystakeholders(thestakeholdersthatthesupplierisserving–e.g.theircompanyorshareholders),versussecondarystakeholders(thestakeholderswhoarenotprimarystakeholders,butwhoseinterestsinfluencetheinterestsoftheprimarystakeholders–e.g.customers,operationalusers).Otherwise,onceMOEsandgoalsarerecognized,thestandardcanhavetheeffectofrequiringthesuppliertoactasacharity.Tofailtoacknowledgeanddealwiththeserealitiesconsiderablyreducesthereal‐worldrelevanceofISO/IEC15288:2008.Severity:6

6.4.1.3a)NOTE Thestatement“Stakeholderrequirementsdescribetheneeds,wants,desires,expectationsandperceivedconstraintsofidentifiedstakeholders”isverydamagingtoISO/IEC15288:2008,becauseitistotallyatoddswiththeEnglishlanguageasdefinedbytheOxfordEnglishDictionary.Asaresult,thestatementviolatestheISOrulesfordevelopingISOstandards.Requirement:anorder,ademand,animperative(OED)Need:aconditionoflackingoracquiringsomenecessarything,eitherphysicallyorpsychologically(OED)Want:wishforpossessionof(OED)Expectation:aninstanceofexpectingorlookingforward(OED)Constraint:Alimitationorrestriction(OED).

www.ppi-int.com


Severity:9

6.4.1.3a) Thissectionhasmanypointsoflanguage,detail,andincompletenesswhichdiminishitsvalue.Severity:4

6.4.2RequirementsAnalysisProcess

Ifthe“system”referredtoin6.4.2isthesamesystemasreferredtoin6.4.1,thenthe“RequirementsAnalysisProcess”isaduplicationof6.4.1.3b)andc),nowsaying,ineffect,“havingdone6.4.1.3b)andc)poorly,nowdo6.4.1.3b)andc)properly.Thissectionreferstoa“technicalview”,“fromthesupplier’sperspective”.“Technical”means“relatingtotechnology”or“relatingtotechnique”.Soinwhatsenseittheview“technical”?Thisprocesshasthesuppliertellingtheacquirerwhattheacquirer’srequirementsare,creatingtheopportunityforthesuppliertomanipulatetheagreementtosupplywhatthesupplierwantstosupply,reflectingtheworstaspectsofnon‐performingacquisitionsystemsworldwide.Yes,6.4.2referstosatisfactionofstakeholderrequirements,butwithstakeholderrequirementsmadepurposefullyvagueunder6.4.1(implicitlynotmeasurable,sincetheRequirementsAnalysisProcessistoresult“inmeasurablesystemrequirements”.TheRequirementsAnalysisProcessisconspicuousinitsabsenceofreferencetosatisfactionofstakeholderneeds.Itisnotaltogetherclearthatthesystemreferredtoin6.4.2isthesamesystemasreferredto6.4.1.Stakeholdersgenerallyseektoachieveoutcomes.End‐useitems,engineeringsystems,productionsystems,transitionsystems,maintenancesystemsanddisposalsystems(forexample)areallapartofthemeansofdoingso,i.e.areapartofsolution.Theterm“productsolution”,referredtoin6.4.2.2butnotin6.4.1,iscommonlyusedtorefertoanend‐useproductalone.Ifthereferencesto“system”in6.4.1and6.4.2arenotintendedtobereferencestothesamesystem,then6.4.2ismandatinga“thenamiracleoccurs”process,asdiditspredecessor,ISO/IEC15288:2002.Thislatterviewoftheworldhasbeenoneofthethreeprimarycontributorstomostfailuresoflargeprojects.Severity:10

6.4.2.3a)1) Thiscontentessentiallyduplicates6.4.1.4b)–ifthesamesystemisbeingreferredto.Severity:10

6.4.2.3a)1) “Mass”isneitheraninterfaceconstraintnorisitinvolvedindefiningthefunctionalboundaryofasystem.Mechanicalandthermalflowsmaybeinvolvedindefiningrequirementsotherthanbehaviouralrequirementsofthesystematitsboundary.Severity:3

6.4.2.3a)2) 2)overlapsincontentsubstantiallywith1).Sub‐para2)isamuchmoresoundstatementofgoodpracticeinrequirementsanalysisthanis1),however,1)containssomevalidadditionalcontent.

www.ppi-int.com


Severity:36.4.2.3a)3) “Unavoidablesolutionlimitations”notintroducedin(valid)

stakeholderrequirementsarenotsystemrequirements,justbecausetheyareunavoidable–orthoughttobeso.ThisrequirementofISO/IEC15288:2008violatestheprincipleofmaintainingacleardistinctionbetweenproblemandsolution,destroyinganybasisfordesignandsystemverification,andleavingthedesignerinignoranceofwhatcanbechangedinadesign,andwhatcannotbechangedindesign,ifthesystemrequirementschange.Severity:6

6.4.2.3a)4) Thenoteismisleading.Criticalperformancemeasuresmayormaynotbemeasuresofeffectiveness.Intheformercase(wheremoreorlesswithrespecttosomemeasureisbetter),criticalperformancemeasuresarenotassociatedwithmeasuresofeffectiveness,theyaremeasuresofeffectiveness.Thisnotegivesweighttothetheorythatdifferentsystemsarebeingreferredtoin6.4.1and6.4.2.Ifthatisthecase,thecriticalperformancemeasuresarederivedmeasuresofeffectivenessofoneormoresub‐systems.ThenotealsoseemstobemixingupwhatareconventionallycalledTechnicalPerformanceMeasures(TPMs),usedtoinstrumentaprojectprimarilyforpurposesofriskmanagement,withMeasuresofEffectiveness,usedtoevaluateandselectbetweenfeasibledesignalternatives,andfordesignoptimization.Severity:7

6.4.2.3a)5) Theparagraphsays“specifysystemrequirementsandfunctions”,implyingthatsystemrequirementsandfunctionsaresomehowmutuallyexclusive.Wheredoesthatleavefunctionalrequirements?Severity:4

6.4.2.3a)5) Thenoteseemstomuddleupproblemandsolution.Theprincipleofmaintainingacleardistinctionbetweenproblemandsolutionappliesnolesstosafetyrequirementsandsafetysolution,andsimilarlysecurity,forthesamereasonsaspreviouslystated.Severity:5

6.4.2.3b)2) Thisrequirementconfirmsthesuspicionthatthestandardisadvocatingthatthesupplier,inperformingrequirementsanalysis,inventrequirementsinformation,thenseekstakeholderacceptanceoftheinventions.Thestandardshould,infact,beadvocatingtheidentificationinrequirementsanalysisofeachrequirementsissue,followedbydialoguewiththerelevantstakeholder(s)onthatissue,toresolvetheissue.Ifthesupplierisdelegatedresponsibilitybytheacquirertoinventrequirementsonbehalfoftheacquirer(whichusuallyinvolvesaconflictofinterestincommercialtransactions),thestandardshouldbeadvocatingtheuseofdesignprocesses,notrequirementsanalysisprocesses,fordoingso.Severity:9

6.4.3Architectural

Callingthisprocessthe“ArchitecturalDesignProcess”conflictswiththedefinitionofarchitectureinthestandard,andinOED,andinuse

www.ppi-int.com


DesignProcess throughoutengineering.Thenamingisanunfortunatethrow‐backtoISO/IEC15288:2002,whichdefined“architecture”asdesignathighphysicallevels,ascontrastedwithdesignatlowphysicallevels.Meanwhile,therestoftheworldhasusedtheword“architecture”tomeandesignataconceptuallevelofdetail,asdistinctfromanimplementablelevelofdetail.Theprocessshouldbereadas,andcalled,“DesignProcess”.Subsequentcommentsarepredicatedonthisinterpretation.Severity:9

6.4.3.2f) Thestandardneedstodistinguishbetweenbuildingthesysteminsystemintegration,andbuildingthesysteminproduction.Forsomesystems,thesebuildsareidentical,e.g.aone‐offairtrafficmanagementsystem.Forothersystems,thetwobuildstructurescanbeverydifferent,e.g.acommercialaircraft.TheDesignProcessisconcernedwithestablishingabasisforbothsystemintegrationbuildsandproductionbuilds.Thelatternecessitatesconcurrentengineeringpractices,whichinturnimpactonthesystemintegrationbuildstructure(orshoulddoso).Severity:5

6.4.3.3a)ActivitiesandTasks,DefinetheArchitecture

6.4.3.3a)ismissingthefundamentalactivityofconceptualisationofphysicalsolutionalternatives,perpetuatingthemisunderstandingsandmisinformationinIEEE1220thathasdonesomuchdamagetoenterprisesthathavetriedtofollowthatstandard.Therelationshipbetweenlogicalandphysical(structural)design–twosidesofthesamecoin‐ismissing.Thewordsin2)“Partitionthesystemfunctionsidentifiedinrequirementsanalysis…Generatederivedrequirementsasneededfortheallocations.”andthewordsof1)meanexactlythesamething,placinginquestionthecredibilityofthisstandard.Severity:10.

6.4.3.3a) Thewords“partitioning”and“allocating”areusedloosely.Severity:3

6.4.3.3a) Thissectiontalksabout“thearchitecture”,ratherthanthedivergentprocessofconceptualizingdesignalternatives,andtheconvergentprocessofmakingdecisionsbetweendesignalternatives,progressivelyfromhighlevelsofabstractiontoimplementablelevelofabstraction(i.e.fromarchitecturetodetaileddesignofthesystem‐of‐interestwithreferencetoaphysicallevelonelevelbelowthesystemofinterest)Severity:8.

6.4.3.3a) Thissectiontotallyignorestheroleofnon‐functionalrequirementsinframingalternativearchitecturesanddetaileddesigns.Severity:8

6.4.3.3b)1) Thisparagraphandtherelatednotearewithoutmeaning.The“designcriteria”foreachelementweredefinedintheactivityof6.4.3.3a)Severity:4

6.4.3.3b)2) Thisparagraphisspurious.Theactivityhasalreadybeenperformed

www.ppi-int.com


intheactivityof6.4.3.3a)–orshouldhavebeen.Also,theparagraphseemstogetintotroublewiththedistinctionbetweenuse,andoperationbyanoperator.Severity:4

6.4.3.3b)3) Thisactivityisanintegralpartof6.4.3.3a)Severity:4

6.4.3.3b)4) Thisparagraphhasalternative“designsolutions”–whateverthatmeans–beingevaluated,withouthavingbeencreated.Evaluationof,andselectionbetween,alternativedesigns(oralternativesolutiondescriptions,thesamethingexceptfornon‐developmentalsolutions),eachcapableofmeetingrequirements,isaverygoodideaprovidedtheexpectedbenefitexceedstheexpectedcostoftheevaluation.Thedecision‐makingbetweendesignalternativesis i n P rojectProcesses–nothelpful!Severity:6

6.4.3.3c) Thewordsaresomewhatobtuseanddetractfromtheusefulnessofthestandard.Severity:2

6.4.4.1Purpose(ofImplementationProcess)

Specifiedbehaviourandinterfacesareimplementationconstraints(allrequirementsareimplementationconstraints).Severity:1


Theterm“designrequirement”isusedforthefirsttime,apparentlytomean“requirement”.Iftheterm“designrequirement”isusedtomean“requirement”,everyrequirementisa“designrequirement”.Thatisnotreallyveryuseful!Severity:4


Thisparagraphstates:“Thisprocessresultsinasystemelementthatsatisfiesspecifieddesignrequirementsthroughverificationandstakeholderrequirementsthroughvalidation.”Thestatementisabsurd–verificationprovidesevidence,notthemeans,ofsatisfactionofrequirements.Validationprovidesevidence,notthemeans,ofsatisfactionofstakeholderneeds.Severity:4

6.4.4.2a)Outcomes(oftheImplementationProcess)

Thedefinitionofanimplementationstrategy(i.e.implementationsystemconceptualdesign)isstatedtobeanoutcomeofthisprocess.But5.1.4correctlystatesthatanenablingsystemcanbeconsideredtobea“system‐of‐interest”toanentityresponsibleforitsimplementation,whilst5.1.3correctlyemphasisestherecursivenatureofdevelopmentofsystemsandsubsystems.Animplementationsystem,e.g.productionsystem,isasystemlikeanyothersystem,butisalsoasubsystemofthebiggersystem,ofwhichproductionisapartofthesolution.Theprocessofdefininganimplementationsystemdesigniscoveredthereforeunder6.4.3.

www.ppi-int.com


Oh,whatamessinthisparagraph!Inapplyingthismuddledpartofthestandard,ImplementationProcessshouldbeconfinedto6.4.4.2c)and6.4.4.2d)Severity:7

6.4.4.3a) Pleaseseecommentson6.4.4.2a).Thevalidcontentof6.4.1to6.4.3inclusiverelates.Severity:7

6.4.4.3b)2) Asystemelementdoesnotnormallymeetsupplieragreements,etc.,unlessdesignisspecifiedinrequirements.Theaimisthatthesystemelementbeconsistentwithmeetingsuchagreements.Severity:3

6.4.5.1Purpose(ofIntegrationProcess)

Thestatementneedstomakeitclearthatthepurposeistoassemblethesystemindevelopment,andexcludesassemblyinproduction,forcaseswheremorethanoneinstanceofasystemistobeproduced.Severity:5

6.4.5.2Outcomes(ofIntegrationProcess)

Thedefinitionofanintegrationstrategy(i.e.integrationsystemconceptualdesign)isstatedtobeanoutcomeofthisprocess.But5.1.4correctlystatesthatanenablingsystemcanbeconsideredtobea“system‐of‐interest”toanentityresponsibleforitsimplementation,whilst5.1.3correctlyemphasisestherecursivenatureofdevelopmentofsystemsandsubsystems.Anintegrationsystemisasystemlikeanyothersystem,butisalsoasubsystemofthebiggersystem,ofwhichintegrationisapartofthesolution.Theprocessofdefininganintegrationsystemdesignisthereforecoveredunder6.4.3.Oh,whatamessinthisparagraph!Inapplyingthismuddledpartofthestandard,IntegrationProcessshouldbeconfinedto6.4.5.2c)and6.4.5.2d)Severity:7


6.4.6.1Purpose(ofVerificationProcess)

Theterm“designrequirement”isused,apparentlytomean“requirement”.Iftheterm“designrequirement”isusedtomean“requirement”,everyrequirementisa“designrequirement”.Thatisreallyunhelpful!Severity:4

6.4.6.1Purpose(ofVerificationProcess)

LimitingtheVerificationProcesstosystemverificationisillogical,andinconsistentwithgoodpracticeinengineering.Allworkproductsarecandidatesforverification.Workproductsshouldbeverifiedwheretheriskreductionbenefitexceedstheverificationcost,andlimitedresourcescannotbeemployedinamorebeneficialway.Severity:9

6.4.6.2 Thedefinitionofaverificationstrategy(i.e.verificationsystem

www.ppi-int.com


Outcomes(ofVerificationProcess)

conceptualdesign)isstatedtobeanoutcomeofthisprocess.But5.1.4correctlystatesthatanenablingsystemcanbeconsideredtobea“system‐of‐interest”toanentityresponsibleforitsimplementation,whilst5.1.3correctlyemphasisestherecursivenatureofdevelopmentofsystemsandsubsystems.Averificationsystemisasystemlikeanyothersystem,butisalsoasubsystemofthebiggersystem,ofwhichverificationisapartofthesolution.Theprocessofdefiningaverificationsystemdesigniscoveredthereforeunder6.4.3.Oh,whatamessinthisparagraph!Inapplyingthismuddledpartofthestandard,VerificationProcessshouldbeconfinedto6.4.6.2c)and6.4.6.2d)Severity:7

6.4.6.3ActivitiesandTasks(oftheVerificationProcess)

Itisunfortunatethatthestandardmakesnoprovisionforverificationrequirements,meaningthatverificationdesigniscarriedoutinavacuum.Thepracticaleffectisusuallyeitherinsufficientverification,orexcessiveverification.Eitherway,stakeholdervalueisreduced.


6.4.6.3b)2) Againtheterm“designrequirements”isused.Previouscommentsapply.

6.4.7.1Purpose(ofTransitionProcess)

ByincludinginstallationofrelevantenablingsystemsinthepurposeoftheTransitionProcess,ISO/IEC15288:2008double‐countstheenablingsystemswithrespecttotransition.Thisisbecause5.1.4(correctly)statesthatanenablingsystemcanbeconsideredtobea“system‐of‐interest”,andeachenablingsystem,therefore,isalsosubjecttothetransitionprocessinitsownright.Whatamess!

6.4.7.2Outcomes(oftheTransitionProcess)

Thedefinitionofatransitionstrategy(i.e.transitionsystemconceptualdesign)isstatedtobeanoutcomeofthisprocess.But5.1.4correctlystatesthatanenablingsystemcanbeconsideredtobea“system‐of‐interest”toanentityresponsibleforitsimplementation,whilst5.1.3correctlyemphasisestherecursivenatureofdevelopmentofsystemsandsubsystems.Atransitionsystemisasystemlikeanyothersystem,butisalsoasubsystemofthebiggersystem,ofwhichtransitionisapartofthesolution.Theprocessofdefiningatransitionsystemdesigniscoveredthereforeunder6.4.3.Oh,whatamessinthisparagraph!Inapplyingthismuddledpartofthestandard,TransitionProcessshouldbeconfinedto6.4.7.2b)tof).Severity:7

6.4.7.3a) Pleaseseecommentson6.4.7.2.Thevalidcontentof6.4.1to6.4.3

www.ppi-int.com


inclusiverelates.Severity:7

6.4.7.3b)6) Thisparagraphdoesn’tallowforenablingsystemsthathaveceasedtoberelevant,e.g.developmentsystemsandproductionsystems.Worse,againthisparagraphisatoddswith5.1.4whichcorrectlystatesthatanenablingsystemcanbeconsideredtobea“system‐of‐interest”.Showingthatanend‐usesystemissustainablebytherelevantenablingsystemsisanactofsystemintegrationoftheparent(capability)system,notanactoftransitionofthesystem‐of‐interest.Severity:7

6.4.8.1Purpose(ofValidationProcess)

LimitingtheValidationProcesstosystemvalidationisillogical,andinconsistentwithgoodpracticeinengineering.Allworkproductsarecandidatesforvalidation.Workproductsshouldbevalidatedwheretheriskreductionbenefitexceedsthevalidationcost,andlimitedresourcescannotbeemployedinamorebeneficialway.Severity:7

6.4.8.2Outcomes(ofValidationProcess)

Thedefinitionofavalidationstrategy(i.e.validationsystemconceptualdesign)isstatedtobeanoutcomeofthisprocess.But5.1.4correctlystatesthatanenablingsystemcanbeconsideredtobea“system‐of‐interest”toanentityresponsibleforitsimplementation,whilst5.1.3correctlyemphasisestherecursivenatureofdevelopmentofsystemsandsubsystems.Avalidationsystemisasystemlikeanyothersystem,butisalsoasubsystemofthebiggersystem,ofwhichvalidationisapartofthesolution.Theprocessofdefiningavalidationsystemdesigniscoveredthereforeunder6.4.3.Oh,whatamessinthisparagraph!Inapplyingthismuddledpartofthestandard,theValidationProcessshouldbeconfinedto6.4.8.2b)tod)Severity:7

6.4.8.3a) Pleaseseecommentson6.4.8.2.Thevalidcontentof6.4.1to6.4.3inclusiverelates.Severity:7

6.4.8.3b)2) Thereferenceforvalidationshouldbeneed,notrequirements.Otherwise,validationceasestoserveapurposeifverificationisperformed.Inmakingthiscomment,IamusingalltermsinaccordancewiththeOxfordEnglishDictionary,andalsoreflectingverywidespreadpracticeinengineering,includingareassubjecttoregulationsuchasaviationandmedicalproducts.

6.4.8.3b)4) Diagnosingthecauseofinvalidityisaproblem‐solvingactionoutsideofthescopeofvalidation.Diagnosingthecauseofinvalidityiswithinthescopeof6.4.1and6.4.2ifcausedbydefectiverequirements,6.4.3ifcausedbydefectivedesign,andotherprocessesifcausedbyfailuresinthoseprocesses.

6.4.9.1Purpose(ofOperationProcess)

Thereferencetoanalysisofoperationalproblemsisnot(orshouldnotbe)withinthescopeoftheOperationProcess.Diagnosingthecauseofoperationalproblemsiswithinthescopeof6.4.1and6.4.2ifcausedbydefectiverequirements,6.4.3ifcausedbydefectivedesign,

www.ppi-int.com


andotherprocessesifcausedbyfailuresinthoseprocesses.6.4.9.2Outcomes(ofOperationProcess)

Thedefinitionofstrategyforoperationisstatedtobeanoutcomeofthisprocess.However,designinghowtooperateasystemanddefinitionofskillsandotherattributesrequiredofoperatorsshouldbedoneintegralwiththedesignofthetechnologyaspectsofthesolution.Also,itiscommonplacetoplaceoperatingprocedureswithintheboundaryofthesystem,butoperatorsoutsideofthatboundary.Forexample,foranaircraftsystemdevelopedandsuppliedbyAirbusorBoeing,theoperatingproceduresareinsidetheboundarybuttheoperators(aircrew)areoutsideoftheboundary.Bycontrast,theaircrewaresystemelementswithinanairtransportationsystem.Inapplyingthismuddledpartofthestandard,theOperationProcessshouldbeconfinedto6.4.9.2b)andd)Severity:10

6.4.9.3a) Pleaseseecommentson6.4.9.2.withrespecttooperationalinfrastructure.Thevalidcontentof6.4.1to6.4.3inclusiverelates.PleaseseealsotheentryrelatingtoamissingSystemManagementProcess.Severity:9

6.4.9.3c) Pleaseseecommentson6.4.9.2.withrespecttooperationalinfrastructure.Thevalidcontentof6.4.1to6.4.3inclusiverelates.Severity:9

6.4.10.2Outcomes(ofMaintenanceProcess)

Thedefinitionofamaintenancestrategy(i.e.maintenancesystemconceptualdesign)isstatedtobeanoutcomeofthisprocess.But5.1.4correctlystatesthatanenablingsystemcanbeconsideredtobea“system‐of‐interest”toanentityresponsibleforitsimplementation,whilst5.1.3correctlyemphasisestherecursivenatureofdevelopmentofsystemsandsubsystems.Amaintenancesystemisasystemlikeanyothersystem,butisalsoasubsystemofthebiggersystem,ofwhichmaintenanceisapartofthesolution.Theactofdesigningthemaintenancesystemiscoveredthereforeunder6.4.3.Oh,whatamessinthisparagraph!Inapplyingthismuddledpartofthestandard,theMaintenanceProcessshouldbeconfinedto6.4.10.2c)tof)inclusive.Severity:10

6.4.10.3a) Pleaseseecommentson6.4.10.2.withrespecttothemaintenancesystem.Thevalidcontentof6.4.1to6.4.3inclusiverelates.Severity:10

6.4.10.3b)1) Obtainingtheenablingsystems,systemelementsandservicestobeusedduringmaintenanceisnotanactofmaintenance,butanactof(maintenance)systemintegration.Severity:4

6.4.10.3b)2) Implementingproblemreportingandincidentrecordingisnotanactofmaintenance,butanactof(maintenance)systemintegration.

www.ppi-int.com


Severity:4

6.4.10.3b)5)NOTE

Theacquisition,trainingandaccreditationofpersonneltomaintainoperatornumbersandskillsisnotanactofmaintenance,butanactofsystemre‐implementation.Severity:3

6.4.11.1Purpose(ofDisposalProcess)

IftheDisposalProcessislimitedinscopetoendingtheexistenceofasystementity,thesetoflifecycleprocessesdefinedinISO/IEC15288:2008doesnotallowforsaleorothertransferofresponsibilityforasystem.Thatomissioncouldbecoveredwithina(missing)SystemManagementprocess.

6.4.11.2Outcomes(ofDisposalProcess)

Thedefinitionofadisposalstrategy(i.e.disposalsystemconceptualdesign)isstatedtobeanoutcomeofthisprocess.But5.1.4correctlystatesthatanenablingsystemcanbeconsideredtobea“system‐of‐interest”toanentityresponsibleforitsimplementation,whilst5.1.3correctlyemphasisestherecursivenatureofdevelopmentofsystemsandsubsystems.Adisposalsystemisasystemlikeanyothersystem,butisalsoasubsystemofthebiggersystem,ofwhichthemeansofdisposalisapartofthesolution.Theactofdesigningthedisposalsystemiscoveredthereforeunder6.4.3.Oh,whatamessinthisparagraph!Inapplyingthismuddledpartofthestandard,theDisposalProcessshouldbeconfinedto6.4.10.2c)toe)inclusive.Severity:10

6.4.11.3a) Pleaseseecommentson6.4.11.2.withrespecttothedisposalsystem.Thevalidcontentof6.4.1to6.4.3inclusiverelates.Severity:10

6.4.11.3b)1) Acquiringtheenablingsystemsorservicestobeusedduringdisposalisnotanactofdisposal,butanactof(disposal)systemimplementationorintegration.Theparagraphconspicuouslytrivialisestheimplementationofinfrastructureforuseindisposingoftheelementsofthesystem‐of‐interest.Severity:6

GeneralComment

Thestandardlacksasystemmanagementprocess.Systemmanagementisthedisciplineandactivityconcernedwithmanagingtheoperation,sustainment,evolution,andretirementofasystem.

www.ppi-int.com