Dokumenti i Procesit të Menaxhimit të Specifikimeve (SMPD)

Ky dokument, pavarësisht nga titulli ose përmbajtja e tij, nuk është një Specifikim Bluetooth i nënshtruar licencave të dhëna nga Bluetooth SIG Inc. ("Bluetooth SIG") dhe anëtarëve të tij nën Marrëveshjen e Licencës për Patentë / Të Drejtën e Autorit dhe Marrëveshjen e Licencës së Markës Tregtare Bluetooth.

KJO DOKUMENT ISSHT I SIGURUAR "SI IS" DHE SHENJA BLUETOOTH, AN MTART E TIJ, DHE NDFRMARRSIT E TYRE NUK BAKEJN NO PESRFAQESSUESE OSE GARANCI DHE SHKELQN T ALL GJITHA GARANCIT, SHPREH ORT OSE IMPLIKUARA, PCRFSHIR NDONJ GARANCI SE P THERMBAJTJA E KISTIJ DOKUMENT ISSHT PA GABIME.

DERI NT SHKALLN NUK NDALOHET NGA LIGJI, SIG BLUETOOTH, AN MTART E TIJ, DHE NDFRMARRSIT E TYRE SHPENZOJN ALL T ALL GJITHA PIARGJEGJSIN AR QIS LIDHEN OSE LIDHEN ME P USRDORIMIN E KISTIJ DOKUMENTI DHE ÇDO INFORMACION T CON PTARMBAJTUR N TH KIST D DOKUMENT, P ,RFSHIR PRFSHIRS NDERRPRERJE, OSE P DR D DME T SP VEÇANTA, indirekte, konsekuente, aksidentale ose ndëshkuese, sidoqoftë të shkaktuara dhe pa rëndësi të teorisë së përgjegjësisë, madje edhe nëse shenja bluetoot, anëtarët e saj, ose ndihmësit e shoqërve të tyre mund të jenë

Ky dokument është në pronësi të Bluetooth SIG. Ky dokument mund të përmbajë ose të përfshijë lëndë që është pronë intelektuale e Bluetooth SIG dhe anëtarëve të tij. Dhënia e këtij dokumenti nuk jep asnjë licencë për ndonjë pronë intelektuale të Bluetooth SIG ose anëtarëve të tij.

Ky dokument mund të ndryshojë pa paralajmërim.

Të drejtat e autorit © 2004–2019 nga Bluetooth SIG, Inc. Shenja dhe logot e fjalës Bluetooth janë në pronësi të Bluetooth SIG, Inc. Marka dhe emra të tjerë të palëve të treta janë pronë e pronarëve të tyre përkatës.

1. Hyrje

Dokumenti i Procesit të Menaxhimit të Specifikimeve (SMPD) përshkruan proceset që specifikojnë autorët dhe riviewErs duhet të ndjekin për të zhvilluar specifikime të reja dhe për të rritur specifikimet ekzistuese (p.sh., për të shtuar ose hequr funksionalitetin ose për të ndryshuar funksionalitetin specifik në një specifikim të miratuar), për të ruajtur specifikimet e miratuara dhe për të menaxhuar fundin e jetës së specifikimeve të miratuara. Përveç kësaj, ky dokument përshkruan procesin e krijimit, riviewing, dhe miratimin e letrave të bardha.

Ka ndryshime në procesin e zhvillimit të specifikimeve midis zhvillimit të specifikimeve të reja dhe përmirësimit të specifikimeve ekzistuese për shkak të ndryshimeve të qenësishme në fushën e këtyre detyrave; këto ndryshime janë theksuar në këtë dokument.

Procesi i zhvillimit të specifikimeve përfshin:

Faza e Kërkesave (përshkruar në Seksionin 3) për të përcaktuar kërkesat funksionale
Një Fazë Zhvillimi (e përshkruar në Seksionin 4) për tu zhvilluar dhe riview specifikimet

Një fazë e vlerësimit (përshkruar në seksionin 5) për të vërtetuar specifikimet me anë të testimit të prototipit ndërveprues (IOP)
Një fazë e miratimit / aprovimit (përshkruar në seksionin 6) për të paraqitur specifikimet te bordi i drejtorëve Bluetooth SIG (BD) për miratim / aprovim

Dokumenti i Specifikimit të Procesit Errata (EPD) [3] përshkruan procesin për propozimin dhe riviewfutja e erratave të specifikimeve, dhe miratimi i tyre si Korrigjime të Erratës (siç përcaktohen në Rregulloret [2]) për specifikimet e miratuara. Nëse nuk shënohet ndryshe, të gjitha referencat ndaj gabimeve në këtë SMPD nënkuptojnë errata specifikimi.

1.1 Precedenca

Rregulloret e Bluetooth SIG, Inc. (Rregulloret) dhe marrëveshjet e anëtarësimit [2] kanë përparësi ndaj çdo përmbajtjeje konfliktuale në ato dokumente dhe SMPD. Pavarësisht nga çdo gjë në këtë dokument, BD mban diskrecionin dhe autorizimin përfundimtar për të ndërmarrë veprime dhe për të marrë vendime edhe nëse ato veprime dhe vendime nuk ndjekin ose nuk bien ndesh me asgjë në këtë dokument, dhe asgjë në këtë dokument nuk kufizon ose kufizon autoritetin e pavarur të BD-së dhe diskrecionin.

Nëse ka ndonjë konflikt midis tekstit në SMPD dhe figurave, teksti ka përparësi.

1.2 Grupet dhe komitetet e referuara

Llojet e mëposhtme të grupeve janë të referuara në këtë dokument: Grupet e Studimit (SG), Grupet e Ekspertëve (EG) dhe Grupet e Punës (GP). Një GP gjithashtu mund të ketë një nëngrup që i raporton GP. Në mënyrë të ngjashme, llojet e mëposhtme të komiteteve janë referuar në këtë dokument: Bluetooth Architectural Review Bordi (BARB), Bluetooth Test dhe Interoperability (BTI), dhe Bluetooth Qualification Review Bordi (BQRB). Ky dokument i referohet gjithashtu Stafit Teknik Bluetooth SIG (BSTS) dhe Bordit Drejtues.

1.3 Komiteti reviews dhe miratimet

Një komitet review është një review që kryhet nga anëtarët e një komiteti (zakonisht 3 anëtarë) për të siguruar reagime brenda një kohe të caktuar (zakonisht 2-3 javë), megjithatëview koha mund të ndryshojë në varësi të gjatësisë dhe kompleksitetit të materialit dhe përparësive të tjera brenda komitetit. Grupi që kërkon riview dhe komiteti që drejton riview secili pajtohet për kohëzgjatjen e riviewMe Grupi dhe anëtarët e komitetit përdorin mjetet Bluetooth SIG për të njoftuar dhe regjistruar fillimin dhe mbarimin e riviewMe Grupi në përgjithësi do të përpunojë reagimet e komisionit kur të merret. Kur komiteti riview koha skadon, grupi përfundon duke adresuar reagimet e komitetit, dhe gjithashtu duhet të marrë në konsideratë çdo ri-mbërritje të vonëview reagimet duke pasur parasysh se materiali mund t'i nënshtrohet miratimit të mëvonshëm nga komiteti.

Një miratim i komisionit merret me një votë të anëtarëve të komisionit në përputhje me Dokumentin e Procesit të Grupit të Punës [4].

1.4 Njoftimet për anëtarët dhe mundësia e pranimit të materialeve

Të gjitha njoftimet e dhëna anëtarëve në përputhje me këtë dokument mund të sigurohen me email, siç është një azhurnim teknik periodik. Njoftimet që do t'u ofrohen të gjithë anëtarëve do t'u dërgohen të gjithë anëtarëve aktivë (dmth., Kur anëtarësimi nuk është pezulluar, përfunduar ose tërhequr). Kur njoftimet të dërgohen me email ato do të dërgohen në adresën e fundit të njohur të postës elektronike (siç pasqyrohet në regjistrat aktualë aktualë të Bluetooth SIG) të secilit individ që është regjistruar nën llogarinë e anëtarësimit të kompanisë anëtare dhe i cili nuk ka zgjedhur të marrë njoftime me email. Asgjë në këtë dokument nuk ndryshon detyrimet ose kërkesat e Bluetooth SIG në lidhje me sigurimin e njoftimit sipas Rregulloreve ose ndonjë marrëveshje tjetër midis Bluetooth SIG dhe cilitdo anëtar.

Kudo që ky dokument i referohet a webfaqe që është e arritshme për të gjithë anëtarët, kjo i referohet aksesit për individët që kanë një llogari aktive Bluetooth SIG. Anëtarët që nuk kanë një llogari aktive mund të krijojnë një llogari përmes SIG Bluetooth webfaqe.

1.5 Modelet

Për secilin lloj dokumenti (p.sh., specifikimet, letrat e bardha, dokumentet e provës) të referuara në këtë SMPD, Bluetooth SIG siguron një model. Modeli duhet të përdoret si bazë për secilin dokument të prodhuar në përputhje me këtë SMPD. Mos përdorimi i shabllonit të duhur mund të rezultojë në mos miratimin e dokumentit. Modelet janë të disponueshme në SIG Bluetooth websiti [8].

1.6 Llojet e specifikimeve

Ekzistojnë disa lloje të specifikimeve të Bluetooth SIG. Në mënyrë hierarkike, të gjitha specifikimet varen nga Specifikimi kryesor i Bluetooth. Specifikime të tilla si tradicionale profiles; protokollet tradicionale; dhe pro me bazë në GATTfiles, shërbimet e bazuara në GATT dhe protokollet e bazuara në GATT të gjitha varen nga veçoritë brenda Specifikimit Core. Specifikimet e tjera, të tilla si specifikimet e Mesh Model, varen nga Mesh Profile specifikimi i cili nga ana tjetër varet nga Specifikimi Core.

Specifikimi i Shtojcës së Specifikimit Core (CSS) përcakton llojet e të dhënave, formatet e të dhënave dhe pro të zakonshmefile dhe kodet e gabimit të shërbimit që përdoren nga Specifikimi Core dhe specifikimet e tjera dhe nuk përcakton në vetvete ndonjë sjellje.

Specifikimi i Shtojcës së Specifikimit të GATT (GSS) përcakton formatet karakteristike dhe përshkruese që përdoren nga Profiles dhe Shërbimet dhe nuk përcakton në vetvete ndonjë sjellje.
Specifikimi i Mesh Device Properties (MDP) përcakton vetitë e rrjetës të përdorura nga Mesh Profile dhe specifikimet e Mesh Model dhe nuk përcakton në vetvete ndonjë sjellje.

2. Mbiview

Ky seksion ofron një mbiview të proceseve dhe nuk ka për qëllim të përfshijë të gjitha detajet.

Figura 2.1 tregon gjashtë fazat kryesore që përbëjnë Procesin e Menaxhimit të Specifikimit.

Katër fazat e para ndodhin gjatë procesit të zhvillimit të specifikimit dhe përbëhen nga Faza e Kërkesave (Seksioni 3), Faza e Zhvillimit (Seksioni 4), Faza e Vlerësimit (Seksioni 5) dhe Faza e Miratimit / Miratimit (Seksioni 6). Kjo pasohet nga dy faza pas birësimit: Faza e Mirëmbajtjes së Specifikimit (Seksioni 7) dhe Faza e Fundit të Jetës së Specifikimit (Seksioni 8).

Figura 2.2 ilustron detaje të katër fazave brenda procesit të zhvillimit të specifikimeve. Kutitë gri tregojnë produktet kryesore për secilën fazë. Kutitë portokalli përmbledhin piketat e procesit.

Në Fazën e Kërkesave (përshkruar në Seksionin 3), një propozim për të filluar punë të re (një Propozim i Punës së Re (NWP)) fillon procesin e zhvillimit të specifikimit duke përcaktuar skenarët e përdoruesve që mundësohen nëse puna e re vazhdon. Nëse NWP miratohet, një grup i caktuar krijon një Dokument të Kërkesave Funksionale (FRD). Pasi FRD miratohet dhe caktohet në një grup, fillon faza e zhvillimit.

Gjatë Fazës së Zhvillimit (përshkruar në Seksionin 4), zhvillimi i specifikimeve përparon përmes një sekuence të stages (0.5/DIPD deri 0.9/CR) duke arritur kulmin në një draft të plotë të specifikimit. Specifikimi 0.9/CR vihet në dispozicion për të gjithë anëtarët, pastaj i paraqitet Bordit i cili merr parasysh specifikimin për miratim. Pasi të miratohet, fillon Faza e Validimit.

Gjatë Fazës së Validimit të zhvillimit të specifikimeve (të përshkruara në Seksionin 5), specifikimi 0.9/CR i miratuar nga BD u vihet në dispozicion të gjithë anëtarëve që tëview dhe të vlefshme, dhe Anëtar Review është filluar. Vlefshmëria arrihet përmes testimit të ndërveprimit (IOP) midis prototipeve të ndërtuara nga anëtarët. Pasi të përfundojë testimi IOP (nëse kërkohet për specifikim) dhe BARB të miratojë raportin e testit IOP, atëherë fillon Faza e Miratimit/Miratimit.

Gjatë Fazës së Miratimit / Miratimit (përshkruar në Seksionin 6), specifikimi dhe dokumentet përkatëse të provës janë përfunduar; Merren miratimet BARB, BQRB dhe BTI; dhe paketa përfundimtare e specifikimeve i paraqitet BD-së, i cili i konsideron specifikimet për miratim (p.sh. miratimi përfundimtar).

Një specifikim mund të ketë nevojë të kthehet në fazën ose vitet e mëparshmetage nëse bëhen ndryshime të rëndësishme. Në disa raste, mund të jetë gjithashtu e mundur të heqësh dorë nga një pjesë e fazës siç përshkruhet në Seksionin 4.4.

Faza e Mirëmbajtjes së Specifikimeve (e përshkruar në Seksionin 7) fillon pasi një specifikim është miratuar nga BD. Gjatë kësaj faze raportohen dhe vlerësohen gabimet e mundshme të gjetura në një specifikim të miratuar, dhe (nëse është e nevojshme) Korrigjimet e Errata bëhen në specifikim. Faza e Mirëmbajtjes së Specifikimit vazhdon derisa specifikimi të zhvlerësohet ose të tërhiqet (shih Fazën e Fundit të Jetës së Specifikimit në paragrafin vijues).

Faza e Fundit të Jetës së Specifikimit (përshkruar në Seksionin 8) përshkruan procesin e amortizimit dhe tërheqjes së specifikimeve të miratuara.

3. Faza e kërkesave

Faza e Kërkesave fillon ose me një NWP (i cili shpreh dëshirën për të filluar punën në një ose më shumë skenarë të përdoruesit) ose pas një përcaktimi që puna e re e dëshiruar tashmë është e mbuluar nga statuti i tyre i GP. Nëse një GP dëshiron të fillojë punë të re që beson se është tashmë brenda fushës së statutit të saj të GP, GP duhet të ndjekë procesin e përcaktuar në Seksionin 3.1 për të vazhduar drejtpërdrejt me zhvillimin e një FRD. Për të gjitha artikujt e tjerë të punës, GP duhet të ndjekë procesin e përcaktuar në Seksionin 3.2. FRD përcakton fushën e kërkesave funksionale që përdoren për të ndërtuar specifikimet në fazën e zhvillimit. Faza e Kërkesave ilustrohet në Figurën 3.1.

3.1 Punë e re e mbuluar nga një statut i GP

Kur një GP dëshiron të fillojë punë të re dhe në mënyrë të arsyeshme beson se funksionaliteti që dëshiron të shtojë është tashmë brenda fushës së statutit të saj të GP, GP mund të fillojë punën në FRD, me kusht që ata menjëherë të njoftojnë BARB. GP do të përfshijë në njoftimin e saj për BARB një përshkrim të punës së re të propozuar dhe një kopje të statutit të GP me gjuhë të theksuar që i autorizon ata të fillojnë punën e re.

Nëse BARB refuzon analizën e GP, GP duhet të ndalojë punën në FRD dhe të vazhdojë me procesin e NWP të përshkruar në Seksionin 3.2. Nëse BARB miraton analizën e GP, GP do të njoftojë menjëherë BSTS (përmes postës elektronike në specification.manager@bluetooth.com) dhe BSTS do të shtojë çështjen në rendin e ditës të BD.

GP do të përfshijë në njoftimin e saj për BSTS të njëjtin informacion që i dha BARB. Nëse BD-ja refuzon analizën e GP-së, GP-ja duhet të ndalojë punën në FRD dhe të vazhdojë me procesin e NWP të përshkruar në Seksionin 3.2. Nëse BD miraton analizën e GP, GP mund të vazhdojë të punojë në FRD siç përshkruhet në Seksionin 3.3.

3.2 Propozimi i Punës së Re (NWP)

Çdo anëtar, WG, SG, ose EG mund të krijojë dhe të paraqesë një NWP (përmes Bluetooth SIG websiti [10]). Një NWP duhet të përfshijë, të paktën, informacion mbi sa vijon duke përdorur modelin zyrtar të dhënë në [8]:

Skenarët e përdoruesit
Angazhimi i anëtarëve për të zhvilluar FRD -në dhe në cilën fushë (a) (p.sh., Kontribuesi, Autori, Reviewer, Prototipizimi)

Udhëheqja e propozuar e punës së FRD
Detyra e grupit të propozuar për punën e FRD
Adresa e postës elektronike të autorit (ave) kryesorë

Shënim: Udhëzimet për procesin NWP janë në dispozicion në Bluetooth SIG websiti [10].

BSTS do të kryejë detyrat e mëposhtme gjatë zhvillimit të NWP:

Siguroni autorit (ave) një vërtetim të marrjes (zakonisht brenda shtatë ditëve kalendarike nga marrja) dhe përshkruani hapat e ardhshëm.

Nëse është e nevojshme, punoni me autorin (et) në mënyrë që NWP të jetë e qartë dhe e plotë. Kjo mund të kërkojë disa përsëritje të NWP.
Nëse NWP përmban deklarata në lidhje me gabimet në specifikimet e miratuara të Bluetooth, punoni me autorin (et) për file hyrjet në sistemin e errata.
Nëse vërehet se NWP potencialisht po kopjon punën që është tashmë në proces ose tashmë është përfunduar, njoftoni autorin (et) për veprën tjetër për vlerësimin e tyre.

Postoni NWP në NWP webfaqe e arritshme për të gjithë anëtarët.
Njoftoni të gjithë anëtarët që NWP është i disponueshëm për riview dhe nëse nevojitet angazhim shtesë i anëtarëve për të zhvilluar FRD -në.

Anëtarët mund të kontaktojnë autorin (et) për të bërë pyetje ose për të dhënë komente në lidhje me NWP.

Të paktën tre kompani anëtare duhet të angazhohen për të marrë pjesë në përfundimin e FRD që rezulton që NWP të bëhet një kandidat për miratimin e BD, dhe të paktën një kompani anëtare duhet të jetë anëtare e Asociuar ose Promovuese. Pas aprovimit të BD-së për NWP, BD-ja do t'ia caktojë NWP një nëngrupi ekzistues të GP-së ose SG-së, për të punuar në FRD (përshkruar në Seksionin 3.3). Nëse një nëngrup i duhur i GP ose SG nuk ekziston, një mund të krijohet.

Për NWP-të që kanë angazhim të mjaftueshëm të anëtarëve, BSTS do të kryejë këto detyra shtesë:

Të paktën 13 ditë para se NWP të propozohet të miratohet nga BD, njoftoni BARB dhe grupin në të cilin rekomandohet NWP për caktim, për miratimin në pritje të NWP. Kjo është bërë për të siguruar një mundësi për reagime në fusha të tilla si grupi i propozuar, nëse PKV është tashmë i mbuluar nga puna ekzistuese, etj.

Dorëzoni NWP të përfunduar në BD.

Nëse NWP paraqitet nga anëtarët që nuk janë të lidhur me një grup, rregulloni që një nga anëtarët të paraqesë NWP në BD.
Nëse PKV është dorëzuar nga një grup, rregulloni që kryesuesi i grupit të paraqesë NWP në BD.

Ftojeni kryetarin e BARB dhe kryesuesit e grupit, tek i cili rekomandohet NWP për caktim, në mbledhjen e BD-së.
Nëse NWP miratohet dhe caktohet nga BD, njoftoni grupin që i është caktuar; autori (t); anëtarët e identifikuar në PKP si të angazhuar për të zhvilluar FRD përkatëse; dhe nëse PKV është propozuar nga një grup, grupi i rezultatit dhe hapat e ardhshëm.

Pasi të miratohet një NWP nga BD, përditësoni statusin në NWP webfaqe.

Çdo NWP mund të refuzohet nga BD sipas gjykimit të tij, p.shamppor, për shkak të kufizimeve të burimeve, nëse puna është përfunduar tashmë plotësisht, puna është jashtë fushëveprimit të dokumenteve qeverisëse të Bluetooth SIG (p.sh., Ndërfaqja e Programimit të Aplikacionit (API)) [2], ose nëse puna e propozuar duhet të jetë filed si një gabim. Nëse NWP refuzohet, BSTS do të njoftojë autorin (ët), anëtarët e identifikuar në NWP se janë zotuar të zhvillojnë FRD -në përkatëse, dhe, nëse NWP -ja propozohet nga një grup, grupi. Njoftimi do të përfshijë çdo arsye për refuzimin. Autori (ët), anëtarët e angazhuar ose grupi mund të kërkojnë kohë në rendin e ditës së BD për të apeluar refuzimin.

Nëse një anëtar ose grup dëshiron të propozojë heqjen e një tipari nga një specifikim i miratuar, grupi ose anëtari duhet të përgatisë një NWP. NWP duhet të përfshijë një analizë të ndikimit që do të ketë heqja në pajtueshmërinë dhe ndërveprueshmërinë e prapambetur, duke përfshirë një analizë të ndikimit në rastet e provës.

NWP nuk kërkohen për përmirësime në specifikimet CSS, GSS ose MDP: zakonisht, azhurnimet në specifikimet CSS, GSS ose MDP vijnë nga azhurnimet e specifikimeve të tjera që kanë NWP-të e tyre.

3.3 Dokumenti i Kërkesave Funksionale (FRD)

FRD përcaktojnë kërkesat funksionale për të mundësuar skenarët e përdoruesve. Një FRD duhet të përfshijë, së paku, informacion mbi sa vijon duke përdorur modelin zyrtar të dhënë në [8]:

Skenarët e përdoruesit
Kërkesat funksionale bazuar në skenarët e përdoruesit

Angazhimi i anëtarëve për të zhvilluar specifikimet (rezultatet) që rezultojnë
Mbështetje prototip opsionale nga anëtarët për rolet e parashikuara
GP të rekomanduar për të zhvilluar specifikimet (rezultatet) që rezultojnë

Zhvillimi i FRD

FRD-të krijohen nga nëngrupi i GP i anëtarëve të caktuar ose anëtarët e SG me mbështetje editoriale nga BSTS. Çdo anëtar i interesuar për të marrë pjesë në zhvillimin e FRD mund të bashkohet me grupin.

FRD-të duhet të tregojnë një angazhim nga të paktën dy (megjithëse inkurajohen tre) kompani anëtare të nivelit të Asociuar ose Promovues për të marrë pjesë në zhvillimin e specifikimeve që rezultojnë. GP ose GP që paraqesin një FRD duhet të përpiqen të arrijnë mbështetje të gjerë nga kompanitë anëtare të grupit që përfaqësojnë segmentin e synuar të industrisë të identifikuar në FRD.

Funksionaliteti i ri që propozohet në një FRD duhet të jetë i mbështetshëm në sa më shumë transporte dhe pajisje ekzistuese të jetë e mundur. Kjo përfshin, për shembullample, duke mbështetur pro-bazuar në GATTfiledhe shërbimet si në transportin e Shkallës Themelore/Shkallës së Zgjeruar të të Dhënave (BR/EDR) ashtu edhe në transportin me Energji të Ulët Bluetooth (LE). Nëse funksionimit të ri i mungon mbështetja e mjaftueshme e anëtarëve për një transport, për shembullamppër shkak të mungesës së angazhimit të anëtarëve për të përcaktuar përdorimin e transportit ose një numër potencialisht të pamjaftueshëm të platformave të testimit të IOP për një ose më shumë role, mbështetja në atë transport mund të përjashtohet nga FRD.

Nëse nuk justifikohet ndryshe, funksionalitet i ri, profiles, dhe shërbimet duhet të jenë në përputhje me kërkesat e pajtueshmërisë së prapambetur të përshkruara në Seksionin 3.3.2.

GP ose SG duhet ta paraqesin FRD tek BARB për riview dhe miratim. BARB ose duhet të miratojë ose refuzojë FRD bazuar në gjykimin e tij inxhinierik. Nëse miratohet nga BARB, FRD do të vihet në dispozicion për të gjithë anëtarët dhe njoftimi për disponueshmërinë e tij do të lëshohet nga BSTS.

FRD nuk kërkohen për përmirësime në specifikimet CSS, GSS ose MDP: zakonisht, azhurnimet në specifikimet CSS, GSS ose MDP vijnë nga azhurnimet e specifikimeve të tjera që kanë FRD-të e tyre.

Kërkesat e përputhshmërisë së prapambetur

Përputhshmëri e prapambetur për BR / EDR

Për funksionimin BR / EDR, kërkesa e pajtueshmërisë së prapambetur përcaktohet si ndërveprim me pjesën BR / EDR të Specifikimit të Bërthamës Bluetooth v1.1 dhe më të ri.

Përputhshmëri e prapambetur për Bluetooth Low Energy

Për funksionimin LE, kërkesa e pajtueshmërisë së prapambetur përcaktohet si ndërveprim me pjesën LE të Specifikimit të Bërthamës Bluetooth v4.0 dhe më të ri.

Përputhshmëri e prapambetur për specifikime të ndryshme nga specifikimet thelbësore

Për specifikimet e ndryshme nga Specifikimi Core Bluetooth, përputhshmëria e prapambetur e një versioni të caktuar duhet të ruhet me të gjitha versionet e mëparshme që kanë të njëjtin numër të madh të versionit. Për ishample, versioni 1.3 duhet të jetë në përputhje me versionet 1.2, 1.1 dhe 1.0, por versioni 2.0 mund të mos jetë i pajtueshëm me versionet 1.0, 1.1, 1.2 dhe 1.3. Vini re se një rritje në numrin e versionit kryesor të Specifikimit Core nuk nënkupton mungesë të pajtueshmërisë së prapambetur me versionet e mëparshme.

Përjashtimi nga kërkesat e pajtueshmërisë së prapambetur

GP ose SG mund të propozojnë përjashtimin e funksionimit specifik nga kërkesa e pajtueshmërisë së prapambetur nëse jepet justifikim. Për ishamppo, nëse funksionaliteti tregohet të ketë norma të ulëta të adoptimit të tregut ose, për shkak të çështjeve të ndërveprimit, është më mirë të hiqni ose zëvendësoni funksionalitetin sesa të modifikoni funksionalitetin. GP ose SG duhet të përfshijnë çdo përjashtim të pajtueshmërisë së prapambetur në FRD, të cilat miratohen nga BARB pas miratimit të FRD. Çdo përjashtim i miratuar nga BARB do t'i paraqitet BD për miratim në 0.9/CR Stage.

3.4 Statuti i Grupit të Punës

Kur BARB miraton një FRD që propozohet t'i caktohet një GP ekzistuese, ajo GP duhet të përgatisë një draft azhurnimi të statutit të tij për të shtuar funksionimin e ri në fushë (përveç nëse BD kishte miratuar më parë analizën e GP se një azhurnim i statutit të GP është nuk kërkohet). Sidoqoftë, kur BARB miraton një FRD që propozohet të caktohet në një GP të ri, BARB dhe anëtarët që janë të interesuar në zhvillimin e funksionalitetit të përshkruar në FRD duhet të përgatisin një draft statut për një GP të ri me funksionalitetin e ri të përfshirë në fushën e statutit .

Pasi të përgatitet statuti i ri ose i përditësuar i GP, ai duhet t'i paraqitet BARB -it për riview dhe miratim. Pasi BARB miraton statutin, drafti i statutit të ri ose të përditësuar të GP do t'i paraqitet BD për miratim.

Sapo BD të miratojë statutin, GP të cilit i është caktuar puna për zhvillimin e specifikimeve nga BD duhet të punojë ngushtë me grupin që përgatiti FRD në rast se kërkohen azhurnime ose sqarime të nevojshme për atë FRD. Nëse një azhurnim i FRD është i nevojshëm gjatë Fazës së Zhvillimit, proceset e përshkruara në Seksionin 3.3 dhe kjo pjesë duhet të ndiqen; megjithatë, zhvillimi i specifikimeve mund të ndodhë paralelisht me azhurnimet e kartës FRD dhe GP.

3.5 Kërkesat Kërkesat e daljes në fazë

Faza e Kërkesave është e plotë dhe Faza e Zhvillimit fillon kur një statut i GP me fushën e nevojshme për FRD ose konfirmohet ose miratohet nga BD dhe kërkesat e mëposhtme janë përmbushur:

PKB ose është aprovuar nga BD, ose BD ka rënë dakord që një NWP është e panevojshme.

FRD dhe statuti përkatës i GP është aprovuar nga BARB.

4. Faza e zhvillimit

Gjatë fazës së zhvillimit, GP-të e caktuar krijojnë specifikimin e ri dhe / ose përmirësojnë një specifikim ekzistues. FRD përcakton kërkesat e specifikimit të ri ose të zgjeruar të Bluetooth. Asnjë funksionalitet nuk lejohet në specifikim që nuk lidhet në mënyrë të arsyeshme me kërkesat në FRD. Objektivi është të krijojmë një specifikim 0.9 / CR që është gati për Fazën e Vlerësimit (përshkruar në Seksionin 5) në përfundim të Fazës së Zhvillimit.
Gjatë Fazës së Zhvillimit, një specifikim (ose përmirësim i specifikimit) përparon përmes tre stages.

Për një specifikim të ri, tre stagato janë:

0.5 Stage
0.7 Stage

0.9 Stage

Për një përmirësim të specifikimeve, të tre stagato janë:

Draft Dokumenti i Propozimit për Përmirësim (DIPD) Stage

Dokumenti i Propozimit për Përmirësimin Final (FIPD) Stage
Kërkesa për Ndryshim (CR) Stage

Secila stage është përshkruar më tej në nënseksionet që vijojnë. Figura 4.1 më poshtë ilustron dokumentet e ndryshme që GP do të përgatisë në secilën stage.

Figura 4.1: Mbiview të specifikimit stages që ndodhin gjatë Fazës së Zhvillimit

Roli i BARB gjatë gjithë procesit të zhvillimit të specifikimeve është të sigurojë GP-të me këshilla dhe asistencë teknike. GP mund, në çdo kohë, t'i bëjë kërkesë BARB për këshilla teknike në lidhje me zhvillimin e specifikimeve dhe konceptet arkitektonike që do të përdoren në një specifikim. GP-të inkurajohen veçanërisht për të kërkuar reagime të hershme nga BARB për karakteristikat që kanë konsiderata më komplekse arkitektonike.

4.1 0.5/DIPD Stage

Gjatë 0.5/DIPD Stage, GP do të zhvillojë sa vijon duke përdorur shabllonet zyrtare të dhëna në [8]:

Për një specifikim të ri, një draft të specifikimit 0.5, i cili duhet të përfshijë, së paku, informacion mbi sa vijon:

Arkitektura për të mbuluar kërkesat siç thuhet në FRD

Për protokollet, përcaktohen pikat e hyrjes në shërbim
Për shërbimet, të dhënat dhe sjelljen e ekspozuar
Për profiles, protokollet e identifikuara dhe funksionaliteti i specifikuar

2. Për një përmirësim të specifikimit, një draft i DIPD, i cili duhet të përfshijë, së paku, informacion mbi sa vijon:

Sfondi: Shtrirja e punës, objektivat që udhëheqin punën dhe si ky propozim specifik përshtatet në fushëveprim
Mbiview e propozimit: Një përmbledhje e funksionalitetit të zgjeruar (fleksibiliteti i shtuar, performanca e përmirësuar, etj.) E siguruar nga DIPD duke përfshirë një përshkrim të qartë në lidhje me mënyrën se si funksionon funksionimi i ri në versionin aktual të specifikimit. Nëse GP ka vlerësuar shumë propozime, këto propozime duhet të përfshihen për t'i dhënë mundësi BARB të përcaktojë nëse është bërë kujdes i mjaftueshëm për zgjedhjen e propozimit të preferuar.

Mbulimi i kërkesave: Një përmbledhje e mbulimit të kërkesave funksionale të dhëna nga propozimi, duke iu referuar kërkesave të përshtatshme të sistemit dhe skenarëve të përdorimit të dhënë në FRD-në e shoqëruar
Përkufizimi i problemit: Një deklaratë e problemeve të zgjidhura nga propozimi (et)
Kriteret e përzgjedhjes: Një deklaratë në lidhje me kriteret e përzgjedhjes / performancës nga matjet shoqëruese të vlerësimit që kanë udhëhequr procesin e përzgjedhjes

Arsyetimi i zgjedhjes: Një ekzaminim i metrikave të vlerësimit që justifikojnë zgjedhjen midis propozimeve dhe zbulojnë shkëmbime
Përshkrimi: Një përshkrim i funksionalitetit dhe protokolleve të zgjeruara. Ky seksion mund të përshtatet me nevoja të ndryshme duke shtuar nën-seksione përkatëse.

3. Strategjia e Testit: Një përshkrim i funksionalitetit të propozuar për t'u testuar (ose jo i testuar) si pjesë e Programit të Kualifikimit Bluetooth dhe mënyrën se si propozohet të testohet funksionaliteti (p.sh. pritshmëritë për Testuesin (ët) e Poshtëm ose Testuesin (ët) e Epërm, dhe nëse testet do t'i atribuohen si teste konformiteti ose ndërveprimi ose një kombinim i të dyjave). Kjo mund të jetë në një dokument të veçantë ose një seksion të veçantë brenda specifikimit 0.5/DIPD. Konventat që do të përdoren në një Strategji Testi përshkruhen në Strategjinë e Testit dhe Terminologjinë e Përfunduarview dokument (TSTO) [5].

Publiku kryesor i dokumenteve në këtë stage janë anëtarët e GP dhe BARB të cilët riview propozimet arkitekturore dhe mbulimi i kërkesave, dhe BTI të cilët riviewështë Strategjia e Testit. Në shumicën e rasteve, dokumentet në këtë stage nuk kanë për qëllim të përmbajnë tekst që është planifikuar për t'u përfshirë në specifikimin përfundimtar.

BSTS duhet të riview të gjitha dokumentet për pajtueshmëri me Udhëzimet për Hartimin e Bluetooth [1] dhe identifikojnë çështjet që GP duhet të adresojë. BARB duhet të riview specifikimi 0.5/DIPD. Për një përmirësim të specifikimeve, BARB gjithashtu duhet të riview DIPD për pajtueshmërinë me kërkesat e pajtueshmërisë së prapambetur të përshkruara në Seksionin 3.3.2. BTI duhet të riview Strategjia e Testit.

BARB ose duhet të miratojë ose refuzojë specifikimin 0.5/DIPD bazuar në gjykimin e tij inxhinierik. Nëse miratohet nga BARB, specifikimi 0.5/DIPD do të vihet në dispozicion në Bluetooth SIG webfaqe për të gjithë anëtarët e Asociuar dhe Promovues dhe njoftimi për disponueshmërinë e tij do të lëshohet nga BSTS. Në 0.5/DIPD Stage, miratimi i Strategjisë së Testit nuk kërkohet.
0.5/DIPD Stage nuk kërkohet për përmirësime në specifikimet CSS, GSS ose MDP

0.5/DIPD Stage kërkesat për dalje

0.5/DIPD Stage është i plotë dhe 0.7/FIPD Stage fillon kur plotësohen kërkesat e mëposhtme të daljes:

BSTS ka përfunduar riviewduke specifikuar 0.5/DIPD dhe Strategjinë e Testimit.

BARB ka aprovuar specifikimin 0.5 / DIPD.
BTI ka përfunduar rikthimin e sajview të Strategjisë së Testit.
BSTS ka vendosur specifikimin e miratuar 0.5 / DIPD të disponueshëm për të gjithë anëtarët e Asociuar dhe Promovuesit.

4.2 0.7/FIPD Stage

Gjatë 0.7/FIPD Stage, GP do të zhvillojë sa vijon duke përdorur shabllonet zyrtare të dhëna në [8]:

Për një specifikim të ri, një draft të specifikimit 0.7, i cili duhet të përfshijë, së paku, informacion mbi sa vijon:

Një përshkrim i të gjitha ndryshimeve që janë bërë që nga miratimi i BARB 0.5, përfshirë propozimet e reja ose të modifikuara, kriteret e përzgjedhjes dhe arsyetimin e zgjedhjes. Ndryshimet duhet të përshkruhen në të njëjtin nivel detajesh siç kërkohet në 0.5 Stage.

Të gjitha kërkesat funksionale nga FRD adresuar.

2. Për një përmirësim të specifikimit, një draft i FIPD, i cili duhet të përfshijë, së paku, informacion mbi sa vijon:

Një përshkrim i të gjitha ndryshimeve që janë bërë që nga DIPD i miratuar nga BARB, përfshirë propozimet e reja ose të modifikuara, kriteret e përzgjedhjes dhe arsyetimin e zgjedhjes. Ndryshimet duhet të përshkruhen në të njëjtin nivel detajesh siç kërkohet në DIPD Stage.

Sipas nevojës, fushat e zhvilluara më tej janë përshkruar në Seksionin 4.1 në lidhje me DIPD.
Një përshkrim i përfunduar i përmirësimit.
Një përshkrim i azhurnuar arkitektonik.
Të gjitha kërkesat funksionale nga FRD adresuar.

3. Dokumentet e provës 0.7 / FIPD, të cilat duhet të përfshijnë, së paku, informacion mbi sa vijon:

Një Test Suite, i përbërë nga një listë e Qëllimeve të Provës siç përshkruhet në TSTO [5].
Një Deklaratë e Përputhshmërisë së Zbatimit (SHKB), siç përshkruhet në OSTO [5].

Për përmirësime të specifikimeve, Test Suite dhe ICS mund të sigurohen ose si dokumente të veçanta ose si seksione shtesë në FIPD.

Publiku kryesor i dokumenteve të prodhuara në këtë stage janë anëtarët e GP dhe BARB të cilët riview përshkrimi i plotë i veçorisë ose përmirësimit duke përfshirë një tekst të planifikuar për t'u përfshirë në specifikimin përfundimtar. BTI është auditori për riview të dokumenteve të provës.

BSTS do të riview pjesët e reja ose të ndryshuara të specifikimit 0.7/FIPD dhe dokumentet e testimit për përputhshmërinë me Udhëzimet e Hartimit Bluetooth, përfshirë konventat gjuhësore të krijuara nga Bluetooth SIG. BARB do të riview specifikimi 0.7/FIPD.

BSTS do të ndihmojë GP në përgatitjen e dokumenteve të provës 0.7 / FIPD në përputhje me TSTO [5].

BTI duhet të riview dokumentet e testit 0.7/FIPD. GP duhet të sigurojë specifikimin 0.7/FIPD për BTI si referencë kur të jetë përsëriviewduke përfshirë dokumentet e testit 0.7/FIPD, të cilat BTI do t'i ripërtërijëview në përputhje me Specifikimin e BTI Review Lista kontrolluese e procesit [6].

Pasi BARB ka përfunduar ri -in e sajview të specifikimit 0.7/FIPD dhe BTI ka përfunduar rikthimin e tijview nga dokumentet e testimit 0.7/FIPD, BSTS do të bëjë riviewed 0.7/Specifikimi FIPD i disponueshëm për të gjithë anëtarët e Asociuar dhe Promovues.

0.7/FIPD Stage nuk kërkohet për përmirësime në specifikimet CSS, GSS ose MDP.

0.7/FIPD Stage kërkesat për dalje

0.7/FIPD Stage është i plotë dhe 0.9/CR Stage fillon kur plotësohen kërkesat e mëposhtme të daljes:

BSTS ka përfunduar riviewnë specifikimet 0.7/FIPD dhe dokumentet e testimit.
BARB ka përfunduar riviewduke specifikuar 0.7/FIPD.
BTI ka përfunduar riviewnë grupin e testeve 0.7/FIPD (qëllimet e testimit) dhe 0.7/FIPD ICS.
BSTS ka bërë riviewed 0.7/Specifikimi FIPD i disponueshëm për të gjithë anëtarët e Asociuar dhe Promovues.

4.3 0.9/CR Stage

Ekzistojnë dy lloje të CR: Një CR i Integruar, i cili është një dokument i ndjekur nga ndryshimet i një specifikimi të tërë të miratuar që tregon të gjitha ndryshimet që nga versioni i mëparshëm, dhe një CR i Shkurtuar, i cili është një dokument që ofron udhëzime për modifikimin vetëm të pjesëve të prekura të versionin e specifikimit në të cilin bazohet CR.

Gjatë 0.9/CR Stage, GP do të zhvillojë sa vijon duke përdorur shabllonet zyrtare të dhëna në [8]:

Për një specifikim të ri, një draft i plotë i përmbajtjes i specifikimit 0.9, i cili duhet të përfshijë, së paku, informacion mbi sa vijon:

Një përshkrim i të gjitha ndryshimeve që janë bërë që nga BARB-reviewed specifikimi 0.7 (ose që nga specifikimi 0.5 nëse prodhimi i specifikimit 0.7 ishte hequr dorë), përfshirë të reja ose
propozimet e modifikuara, kriteret e përzgjedhjes dhe arsyetimin e zgjedhjes. Ndryshimet duhet të përshkruhen në të njëjtin nivel detajesh siç kërkohet në 0.5 Stage dhe 0.7 Stage.

2. Për një përmirësim të specifikimit:

Ose një CR i Integruar, i cili duhet të përfshijë, së paku, informacion mbi sa vijon:
Një përshkrim i të gjitha ndryshimeve që janë bërë që nga BARB-reviewed FIPD (ose që nga DIPD nëse FIPD është hequr dorë) duke përfshirë propozimet e reja ose të modifikuara, kriteret e përzgjedhjes dhe arsyetimin e zgjedhjes. Ndryshimet duhet të përshkruhen në të njëjtin nivel detajesh siç kërkohet në DIPD Stage dhe FIPD Stage.
Të gjitha ndryshimet e propozuara në specifikimet e miratuara më parë duke përdorur gjurmimin e ndryshimeve.
Të gjitha erratat teknike të miratuara (me secilin gabim të referuar me një numër erratumi), të paraqitura duke përdorur gjurmimin e ndryshimeve, që ende nuk janë përfshirë në versionin specifikues të miratuar më parë, dhe atë tekst ndikimi që shoqërohet me përmirësimin e specifikimit; ose që ndryshe ndikojnë në testimin e IOP.

3. Ose një CR të Shkurtuar, i cili duhet të përmbajë, së paku, informacion mbi sa vijon:

Një përshkrim i të gjitha ndryshimeve që janë bërë që nga BARB-reviewed FIPD (ose që nga DIPD nëse FIPD është hequr dorë) duke përfshirë propozimet e reja ose të modifikuara, kriteret e përzgjedhjes dhe arsyetimin e zgjedhjes. Ndryshimet duhet të përshkruhen në të njëjtin nivel detajesh siç kërkohet në DIPD Stage dhe FIPD Stage.
Të gjitha ndryshimet e propozuara për secilin seksion të prekur dhe paragrafin e specifikimit që CR propozon të ndryshojë.
Të gjitha erratat teknike të miratuara (me secilin gabim të referuar me një numër erratumi), të paraqitura duke përdorur shënime, që ende nuk janë përfshirë në versionin specifikues të miratuar më parë, dhe që teksti i ndikimit shoqërohet me përmirësimin e specifikimit; ose që ndryshe ndikojnë në testimin e IOP.

4. Një CR i CSS (nëse kërkohen shënime të reja nga specifikimi), i cili mund të jetë i ngulitur në një CR të Shkurtuar të specifikimit.
5. Një GSS CR (nëse shënimet e reja kërkohen nga specifikimi), i cili mund të jetë i ngulitur në një CR të Shkurtuar të specifikimit.
6. Një CR i MDP (nëse kërkohen shënime të reja nga specifikimi), i cili mund të jetë i ngulitur në një CR të Shkurtuar të specifikimit.
7. Dokumentet e provës 0.9 / CR, të cilat duhet të përfshijnë, së paku, informacion mbi sa vijon duke përdorur modelin zyrtar të dhënë në [8]:

Test Suite 0.9 / CR, i cili përfshin raste të testit me përmbajtje të plotë dhe Tabelën e Hartësimit të Rasteve të Testit (TCMT), siç përshkruhet në TSTO [5].
ICS 0.9 / CR, siç përshkruhet në OSTO [5].
Nëse konfigurimi i testeve kërkon parametra specifik për Implementation Under Test (IUT), Informacioni i EXtra për Zbatimin 0.9 / CR për Testim (IXIT).
Lista e Referencës së Rastit të Testit 0.9 / CR (TCRL) (opsionale për azhurnimet e specifikimeve kryesore).

8. Një analizë e mbulimit të provës që tregon se cilat kërkesa të specifikimit janë testuar ose jo të testuara brenda Suite Test 0.9 / CR (për përmirësimet e specifikimit, analiza e mbulimit të testit duhet të përfshijë vetëm funksionalitetin e shtuar rishtas dhe të ndikuar, dhe jo zonat e pa ndikuara të specifikimi origjinal).
9. Një plan testimi IOP.

Për përmirësime të specifikimeve, Test Suite, ICS dhe IXIT mund të sigurohen ose si dokumente të veçanta ose si seksione shtesë në CR të Shkurtuar.

Në shumicën e rasteve, një CR i Integruar ose i Shkurtuar duhet të bazohet në versionin e specifikuar të miratuar më parë, por gjithashtu mund të bazohet në draftin e fundit të ndërmjetëm. Numri i fundit i versionit të specifikimit të ndërmjetëm të fundit duhet të jetë numri i versionit i shoqëruar me një version të dokumentit që është ngrirë dhe që nuk do të ndryshojë me kalimin e kohës. Përndryshe, informacione shtesë identifikuese (të tilla si data e dokumentit dhe a URL në një vend të përhershëm) duhet të sigurohet për të identifikuar versionin specifik "bazë". Nëse përdoret një draft i ndërmjetëm, çdo ndryshim që nuk lidhet drejtpërdrejt me CR brenda një seksioni të caktuar që CR po modifikon duhet të përfshihet, por nuk kërkohet të shfaqet duke përdorur shënimin. Nëse pjesët përkatëse të draftit të ndërmjetëm azhurnohen më vonë, CR duhet të azhurnohet për të pasqyruar azhurnimet në draftin e ndërmjetëm.

Në mënyrë ideale, materiali i shkurtuar CR është i integruar në një draft të specifikimit të plotë dhe dokumenteve të plota të provës përkatësisht, para Fazës së Vlerësimit, por ato gjithashtu mund të integrohen në fillim të Fazës së Vlerësimit. Nëse shumë karakteristika janë duke u zhvilluar për një specifikim (p.sh., Specifikimi Bërthamë), mund të jetë e dëshirueshme të integrohen tiparet në një draft të vetëm pasi të ketë përfunduar testimi i IOP.

BSTS do të riview specifikimet 0.9/CR dhe dokumentet e testimit për përputhshmërinë me Udhëzimet e Hartimit të Bluetooth. Pastaj BARB do të riview specifikimi 0.9/CR i ndjekur më vonë nga plani i testit IOP (siç përshkruhet në Seksionin 4.3.1). Pasi specifikimi 0.9/CR të dorëzohet nga GP në BARB për riview, BSTS do ta bëjë atë të arritshëm për të gjithë anëtarët që të riview dhe njoftoni të gjithë anëtarët për disponueshmërinë e tij. Nga kjo pikë përpara në procesin e zhvillimit të specifikimeve, BSTS do t'i bëjë draftet e specifikimit të paraqitur në BARB në dispozicion të të gjithë anëtarëve me njoftime periodike të dërguara për të gjithë anëtarët.

Për një përmirësim të specifikimit, GP do t'i rekomandojë BD-së nëse versionet e mëparshme të specifikimit duhet të zhvlerësohen ose të tërhiqen, duke përfshirë arsyet teknike të rekomandimit (ve).

BARB do të riview analiza e GP -së për pajtueshmërinë e specifikimit 0.9/CR me kërkesat e dhëna në FRD, çdo çështje të mundshme të sigurisë, çdo çështje rregullatore, pajtueshmëri me arkitekturën Bluetooth dhe, për një përmirësim specifikimi, pajtueshmëri me kërkesat e pajtueshmërisë së prapambetur të përshkruara në Seksionin 3.3.2 .XNUMX Nëse BARB identifikon ndonjë çështje të mundshme të sigurisë, BARB do të njoftojë BSTS për riview dhe koordinimi me Grupin e Ekspertëve të Sigurisë; dhe nëse BARB identifikon ndonjë implikim rregullator, BARB do të njoftojë BSTS për riview dhe koordinoni me Komitetin Rregullator dhe këshilltarin juridik të Bluetooth SIG. BARB ose duhet të miratojë ose refuzojë specifikimin 0.9/CR bazuar në gjykimin e tij inxhinierik dhe marrjen parasysh të faktorëve të përshkruar në këtë paragraf.

BTI do të riview dokumentet e testit 0.9/CR duke marrë parasysh analizën e mbulimit të testit. BTI ose duhet të miratojë ose refuzojë dokumentet e testit 0.9/CR.

Pasi BARB miraton specifikimin 0.9/CR, GG i paraqet planin e testimit të IOP BARB për riview.

Specifikimi i aprovuar nga BARB 0.9 / CR i paraqitet BD-së për të aprovuar fillimin e testimit të IOP dhe publikimin e specifikimit 0.9 / CR për të gjithë anëtarët.

Për të nxjerrë në pah çështjet e mundshme ligjore, GP -të mund të kërkojnë një specifikimview nga këshilltari juridik i Bluetooth SIG (ri juridikview) para ri ligjore të detyrueshmeview zhvillohet gjatë Fazës së Birësimit/Miratimit. Megjithatë, për përmirësimet e specifikimeve, ri ligjoreview duhet të bëhet në një CR të Integruar (në krahasim me një CR të shkurtuar) dhe kjo duhet të paracaktohet sa më parë që të jetë e mundur në mënyrë që burimet të jenë në dispozicion.

Plani i provës IOP

GP do të zhvillojë një plan të shkruar të testit të IOP që duhet të plotësojë të gjitha kërkesat e përcaktuara më poshtë për përdorim gjatë Fazës së Validimit në ngjarjet e testit IOP. GP -të duhet të paraqesin planin e testimit të IOP në BARB për riview para se të fillojnë ngjarjet (et) e testit të IOP. Për përmirësime të thjeshta të specifikimeve (veçanërisht ato që nuk kërkojnë modifikim ose shtim të rasteve të testimit në Suite Test), testimi IOP mund të mos jetë i nevojshëm dhe GP mund të paraqesë një kërkesë në BARB për heqjen dorë nga testimi IOP duke përdorur procesin e përcaktuar në Seksionin 4.4.

Plani i provës IOP duhet të përmbajë:

Testoni raste për të verifikuar të gjitha tiparet e reja të detyrueshme, opsionale dhe të kushtëzuara
Të paktën një rast prove për secilin kod op
Të paktën një rast provë për secilin parametër
Të paktën një rast prove për secilin lloj pakete
Rastet e provës së pajtueshmërisë së prapambetur për përmirësimet e specifikimit në mënyrë që kërkesat e renditura në Seksionin 3.3.2 të plotësohen për të gjithë funksionalitetin e zgjeruar (shih gjithashtu Seksionin 4.3.1.1).
Rastet e provës kur IUT është e ekspozuar ndaj vlerave jashtë kufijve të përcaktuar ose ndaj aspekteve të sjelljes të konsideruara të pavlefshme ose të papritura (Rastet e provave të pavlefshme të sjelljes). Vini re se pritet që një testues i tillë si PTS ose mjet tjetër i provës të jetë iniciatori i çdo sjelljeje të pavlefshme.
Çdo numër i caktuar i përkohshëm (i zgjedhur në koordinim me BSTS për të shmangur mbivendosjen në ngjarjet e ardhshme të testit IOP) që do të përdoret në ngjarjen e provës IOP, siç përshkruhet në Seksionin 4.3.1.2.
Identifikimi i numrit të kërkuar të zbatimeve të pavarura që duhet të kalojnë çdo rast prove, duke marrë parasysh kërkesat e mbulimit të përshkruara në Seksionin 4.3.1.3
Identifikimi i rasteve të provave në Test Suite që GP beson se duhet të përjashtohen dhe arsyetimi për përjashtimin e tyre. Këto zakonisht përfshijnë: • Raste të provave të Vërtetimit në të Ardhmen (p.sh., teste të zakonshme në mënyrë që shtesat e mundshme në të ardhmen të mund të akomodohen, të tilla si karakteristika shtesë, karakteristika shtrirëse ose përdorimi i bitëve ose fushave të Rezervuara për Përdorim të Ardhshëm (RFU))
• Raste testimi që janë një nëngrup i testeve të tjera të përfshira
• Raste gjenerike provash që janë praktikisht identike me testet që ekzekutohen për disa specifikime të tjera (p.sh., shkaktimi i kodeve të zakonshme të gabimit)
• Provoni raste me të njëjtin qëllim provë si rastet e provës që kalojnë mbi një transport tjetër (p.sh., një rast prove BR / EDR që është i ngjashëm me një rast prove LE)
• Fuqia ose testimi i stresit i zbatimit

Plani i testimit të IOP mund të përfshijë gjithashtu teste që janë unike për testimin e IOP, siç janë rastet e provave fund-për-fund që bashkojnë sekuenca më komplekse që mund t'i ngjajnë një skenari tipik të përdoruesit.

Megjithëse nuk kërkohet miratimi nga BARB i planit të provës IOP (duke kuptuar që plani i provës IOP do të vazhdojë të modifikohet dhe përmirësohet me secilën ngjarje të testit IOP), kërkohet miratimi nga raporti i testit IOP nga BARB (shih Seksionin 5.1.1) . Nëse një plan i testimit të IOP nuk përmbush të gjitha kërkesat e përcaktuara në Seksionin 4.3.1, GP duhet të paraqesë një përmbledhje të çdo ndryshimi të njohur dhe arsyetimin për secilën ndryshim te BARB para se të fillojë ngjarja (provat) e IOP.

Plani i provës IOP dhe rastet e provës duhet të bazohen kryesisht në përmbajtjen brenda dokumenteve të provës së specifikimit të lidhur.

Për t'i bërë ngjarjet e provës IOP efikase, GP duhet të ketë të kompletuar planin e provës IOP dhe të gjitha rastet e provës shoqëruese dhe të disponueshme për zbatuesit në mënyrë ideale të paktën një muaj para ngjarjes së parë të testit IOP.

Planifikimi për testimin e përputhshmërisë prapa
Për përmirësimet e specifikimeve, testimi IOP i pajtueshmërisë së prapambetur duhet të marrë parasysh verifikimin kundër të gjitha versioneve aktive dhe të vjetruara të specifikimit sepse ato specifikime dhe funksionalitete që gjenden zakonisht në produktet Bluetooth mund të kenë një jetëgjatësi shumë të gjatë (p.sh. automjete). GP -ja duhet të analizojë nivelin e duhur të testimit të pajtueshmërisë së prapambetur të nevojshme (nëse ka) duke përfshirë cilat versione të testohen dhe testet për të kryer, dhe t'ia sigurojë këtë analizë BARB -it. BARB duhet të riview analizën dhe rekomandimin e ndryshimeve (nëse ka) që GP të përfshihen në planin e testimit të IOP.

Anëtarët që marrin pjesë në testimin e pajtueshmërisë së prapambetur inkurajohen të sjellin pajisje të trashëguara që janë kualifikuar kundrejt versionit (eve) specifikimit të mëparshëm. GP duhet të raportojë çdo dështim të përputhshmërisë së prapambetur në raportin e testit IOP. Kompanitë anëtare inkurajohen gjithashtu që të kryejnë testimin e pajtueshmërisë së prapambetur në laboratorët e tyre jashtë vendndodhjes së ngjarjes së testit IOP dhe të raportojnë çdo çështje që lidhet me specifikimet në GP.

Numrat e caktuar të përkohshëm që përdoren në testimin e IOP
Duhet të këshillohen BSTS dhe BARB për të koordinuar caktimin e përkohshëm të numrave të caktuar që do të përdoren në ngjarjen e provës IOP në mënyrë që të mos ketë mbivendosje ose përplasje me specifikimet e tjera. Këto vlera të përkohshme duhet të përfshihen në planin e provës IOP dhe nuk do të caktohen për përdorim nga ndonjë specifikim i miratuar.

Për testimin e IOP ku po propozohen një ose më shumë vlera të reja 16 bit UUID, vlerat brenda intervalit prej 0x7F00 deri 0x7FFF janë të rezervuara për testimin e IOP.

Për testimin e IOP ku po propozohen një ose më shumë vlera të reja të Multiplekserit të Shërbimit të Protokollit Fiks (PSM), do të përdoren vlerat që fillojnë nga fundi i intervalit të vlefshëm nga 0x0000 në 0x007F, siç specifikohet në Specifikimin Bërthamë.

Kërkesat e mbulimit
GP duhet t'i sigurojë BARB provë se numri i kërkuar (siç përshkruhet në seksionet që vijojnë) të zbatimeve të pavarura kanë kaluar çdo rast prove. Çdo kërkesë e GP për përjashtime nga numri i kërkuar i zbatimeve të pavarura duhet të tregohet në planin e provës IOP që i paraqitet BARB.

Zbatimet konsiderohen të jenë të pavarura nga njëra-tjetra, për sa kohë që të gjitha pjesët që janë të rëndësishme për vërtetimin janë zhvilluar në mënyrë të pavarur, dmth., Nga ekipe të ndryshme (të cilat jo domosdoshmërisht vijnë nga kompani të ndryshme). BSTS mund të ndihmojë në vlerësimin nëse prototipat mund të konsiderohen të pavarur nga njëri-tjetri për të ruajtur anonimitetin dhe konfidencialitetin e detajeve të zbatimit.

Vini re se mjetet e provës, përfshirë PTS, nuk konsiderohen të jenë implementime të pavarura.

Specifikimet kryesore Kërkesat e mbulimit të IOP
Një tipar i Specifikimit Bërthamë zakonisht përcakton një ose më shumë role ku secili rol është krijuar për të ndërvepruar me një ose më shumë role të tjerë ose ndoshta me vetveten.

Për secilën palë rolesh që janë krijuar për të ndërvepruar me njëri-tjetrin, të paktën tre implementime të pavarura të secilit rol duhet të demonstrohen për të ndërvepruar me tre implementime të pavarura të rolit plotësues.

Për secilin rol që mund të ndërveprojë me një pajisje tjetër në të njëjtin rol, të paktën tre zbatime të pavarura të këtij roli duhet të tregojnë se ata mund të bashkëveprojnë me njëri-tjetrin në atë rol.

Specifikimet e shërbimit Kërkesat e mbulimit të IOP
Të paktën tre implementime të pavarura të shërbimit duhet të tregojnë se ato ndërveprojnë me të paktën një zbatim të klientit, i cili mund të jetë PTS.

Profile dhe specifikimin e protokollit kërkesat e mbulimit të IOP
Profile dhe specifikimet e protokollit zakonisht përcaktojnë një ose më shumë role ku secili rol është krijuar për të ndërvepruar me një ose më shumë role të tjera, ose ndoshta me vetveten.

Për secilën palë rolesh që janë krijuar për të ndërvepruar me njëri-tjetrin, të paktën dy implementime të pavarura të secilit rol duhet të demonstrojnë se ato ndërveprojnë me dy implementime të pavarura të rolit plotësues.

Për secilin rol që mund të ndërveprojë me një pajisje tjetër në të njëjtin rol, të paktën tre zbatime të pavarura të këtij roli duhet të demonstrojnë se ata ndërveprojnë me njëri-tjetrin në atë rol.

Specifikimet e modelit Kërkesat e mbulimit të IOP
Të paktën tre implementime të pavarura të modelit të serverit ose modelit të kontrollit duhet të tregojnë se ato ndërveprojnë me të paktën një implementim të klientit (që mund të jetë PTS), dhe të paktën një implementim i modelit të klientit duhet të demonstrojë që ndërvepron me të paktën një zbatim të modelit të serverit dhe PTS.

Numërimi i versionit të specifikimit

Gjatë 0.9/CR Stage, GP duhet të përgatisë një rekomandim për t'i paraqitur BD -së në lidhje me numrin e versionit që do të aplikohet në specifikim kur miratohet.

Versionet e specifikimeve ndahen në dy lloje: versione të lëshimit të plotë, të cilat përfshijnë tipare të reja ose të azhurnuara, dhe versione të lëshimit të mirëmbajtjes (të njohura edhe si "versione me pikë-Z"), të cilat integrojnë errata teknike dhe editoriale, por nuk përfshijnë të reja ose të azhurnuara karakteristikat. Versionet e lëshimit të plotë kanë numra me dy pjesë në formën e XY, të tilla si 2.1 ose 5.0, ndërsa versionet e lëshimit të mirëmbajtjes kanë numra me tre pjesë në formën e XYZ, siç është 2.1.2. Vlera e Z nuk mund të jetë 0.

Për çdo dy versione, njëri quhet "versioni më i lartë" dhe tjetri është "versioni më i ulët". Kjo përcaktohet në përputhje me rregullat e mëposhtme:

Nëse përbërësit X ndryshojnë, ai me vlerën më të lartë X është “versioni më i lartë”.
Nëse përbërësit X janë të njëjtë, por përbërësit Y ndryshojnë, ai me vlerën më të lartë Y është “versioni më i lartë”.
Nëse përbërësit XY janë të njëjtë, por përbërësit Z ndryshojnë, ai me vlerën më të lartë Z është “versioni më i lartë”. Për këtë qëllim, një numër dypjesësh XY trajtohet si një numër trepjesësh XY0.

Për shembullampLe, numrat e mëposhtëm të versionit do të ishin në rregull nga versioni më i ulët në versionin më të lartë: 1.4, 2.0, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.2. Për CSS, çdo përditësim rrit vetëm përbërësin X të numrit të versionit.

Parakushtet e miratimit të BD-së
Në fund të fazës së Zhvillimit të Specifikimeve, kërkesat e mëposhtme duhet të plotësohen përpara se një specifikim 0.9 / CR të paraqitet në BD për miratim:

GP ka përfunduar analizën e mbulimit të testit.
BSTS ka përfunduar riviewnë specifikimet 0.9/CR dhe dokumentet e testimit.
BARB ka aprovuar specifikimin 0.9 / CR.
BARB ka aprovuar CSS CR (nëse shënimet e reja kërkohen nga specifikimi) i cili mund të jetë i ngulitur në një CR të Shkurtuar të specifikimit.
BARB ka aprovuar GSS CR dhe MDP CR (nëse hyrjet e reja kërkohen nga specifikimi).
BTI ka miratuar Suite Test 0.9/CR, ICS dhe TCRL, së bashku me një IXIT (me kusht që IXIT të jetë i nevojshëm për të kryer testet në Suite Test). TCRL është opsionale në këtë stage për azhurnimet në Specifikimin Core.
GP -ja i ka dorëzuar planin e testimit të IOP BARB -it për riview (nëse testimi nuk hiqet nga BARB).

Dokumentet e paraqitura në BD duhet të përfshijnë specifikimin e aprovuar nga BARB 0.9 / CR dhe një prezantim në BD i cili duhet të përfshijë:

Çdo kërkesë e njohur për të hequr dorë nga testimi i IOP ose ndonjë nga kërkesat e përcaktuara në Seksionin 4.3.1
Një listë e transporteve që specifikimi mbështet (p.sh., BR / EDR, LE. Etj.)
Për një përmirësim të specifikimit, çdo përjashtim nga kërkesat e pajtueshmërisë së prapambetur (përshkruar në Seksionin 3.3.2) që kërkohen nga GP
Për një përmirësim të specifikimit, një rekomandim nga GP që numri i versionit të zbatohet për specifikimin e miratuar
Për një përmirësim të specifikimit, rekomandimi i GP i fundit të jetës për versionin (et) e mëparshëm të specifikimit të miratuar, duke përfshirë çdo arsye teknike pse amortizimi ose tërheqja e ndonjë versioni të mëparshëm të specifikimit është ose nuk rekomandohet, dhe arsyetimi për rekomandimin
Çdo shqetësim serioz i pazgjidhur nga anëtarët e BARB ose BTI (p.sh. arsyet për asnjë Votim Jo gjatë miratimeve, shqetësime që rezultojnë ngaview të dokumenteve të testimit, ose shqetësimet se specifikimi 0.9/CR është jashtë fushëveprimit të FRD ose statutit)
Statusi i përgatitjes së Profile Suite Tuning (PTS) ose mjete të tjera të nevojshme të lidhura me birësimin që përgatiten nga BSTS

BD mund të zgjedhë të miratojë specifikimin 0.9 / CR për testimin e IOP siç kërkohet nga Rregulloret [2], përpara se BTI të miratojë dokumentet e provës 0.9 / CR dhe para se GP të konfirmojë që plani i testit IOP plotëson kërkesat e përcaktuara në Seksionin 4.3.1. 0.9 BD-ja gjithashtu mund të kushtëzojë miratimin e tij të specifikimit 0.9 / CR për testimin e IOP me miratimin e BTI të dokumenteve të testit XNUMX / CR.

0.9/CR Stage kërkesat për dalje
0.9/CR Stage është e plotë dhe Faza e Validimit fillon kur BD miraton fillimin e testimit të IOP.

4.4 Heqja dorë nga procesi i zhvillimit të specifikimeve

Një GP mund të kërkojë të heqë dorë nga një ose më shumë nga hapat e mëposhtëm të procesit:

0.5/DIPD Stage
0.7/FIPD Stage
Testimi i IOP brenda Fazës së Vlerësimit

Për të kërkuar heqjen dorë, GP duhet të përdorë modelin e heqjes dorë nga procesi të siguruar nga Bluetooth SIG [8] dhe të paraqesë një kërkesë për heqje dorë nga secili komitet (p.sh., BARB ose BTI) që kërkohet të riview ose miratoni draftin e specifikimit ose dokumentet e provës të lidhura në stage që GP propozon heqjen dorë dhe secili prej këtyre komiteteve duhet të miratojë kërkesën e heqjes dorë.

Një kërkesë për heqje dorë duhet të përmbajë sa vijon:

Një identifikim i stage (t) që GP do të heqë dorë
Një justifikim pse stage (s) duhet të hiqen dorë
Një identifikim i secilit komitet (p.sh., BTI dhe/ose BARB) që kërkohet të ri -riprodhohetview dhe miratoni kërkesën e heqjes dorë

Komiteti që konsideron heqjen dorë mund të kërkojë që një përfaqësues i GP të bëjë një prezantim për të justifikuar heqjen dorë nga procesi SMPD përpara se të vendosë për kërkesën e heqjes dorë.

Nëse një heqje dorë kërkon të heqë dorë nga hapa të shumtë dhe një pjesë e heqjes dorë refuzohet dhe një pjesë miratohet, përgjigja e komitetit duhet të tregojë se cilat hapa në kërkesën e heqjes dorë janë aprovuar dhe cilët janë refuzuar. Nëse një kërkesë për heqje dorë refuzohet, njoftimi i refuzimit duhet të përfshijë arsyet e refuzimit.

5. Faza e vlerësimit

Gjatë Fazës së Validimit, GP do të kryejë testimin e IOP në specifikimin 0.9/CR me objektivin e dhënies së një raporti të testit IOP për BARB review dhe miratim. Sa herë që është e mundur, testimi IOP i përmirësimeve të specifikimeve duhet të bëhet kundër draft specifikimit të integruar. Përveç kësaj, Anëtarja Review, siç kërkohet nga aktet nënligjore [2], fillon gjatë kësaj faze.

Nëse specifikimi (ose përmirësimi) nuk kërkon testimin e IOP, atëherë testimi i IOP brenda Fazës së Vlerësimit mund të hiqet duke përdorur procesin e përshkruar në Seksionin 4.4.

Gjatë rrjedhës së testimit të IOP (i cili mund të jetë një ose më shumë ngjarje), GP duhet të gjurmojë çështjet duke përdorur sistemin e përcjelljes së çështjeve të Bluetooth SIG dhe të përsëritet për të përfshirë përditësimet në draft specifikimet, dokumentet e testimit dhe planin e testimit të IOP. Sapo të përfundojë testimi IOP, GP duhet të plotësojë azhurnimet në draft specifikimet dhe dokumentet e testimit për të adresuar të gjitha çështjet, dhe të përgatisë dhe dorëzojë një raport të testit IOP në BARB për riview dhe miratim. Kjo është ilustruar në Figurën 5.1.

Gjatë fazës së vlerësimit ka disa aktivitete që mund të fillojnë. Këto aktivitete mund të ndodhin paralelisht dhe përfshijnë sa vijon:

Specifikimi i miratuar nga BD 0.9/CR vihet në dispozicion për të gjithë anëtarët nga BSTS me njoftimin për fillimin e Re Anëtarview periudha e kërkuar nga aktet nënligjore.
Çdo azhurnim i kërkuar është i përfshirë në CSS (i cili mund të jetë i ngulitur në një CR të Shkurtuar të specifikimit).
Përkufizimet karakteristike ose përshkruese përfshihen në specifikimet GSS, si dhe PTS për testimin e IOP.
Përkufizimet e pronave të rrjetës janë përfshirë në specifikimin e PZHK-së, si dhe PTS për testimin e IOP.
BSTS mundëson regjistrimin e platformës IOP dhe mjetin e hyrjes së rezultateve në përgatitje të testimit të IOP.
Testimi i IOP, nëse kërkohet (shih Seksionin 5.1).
Review komentet dhe çështjet, përfshirë ato të paraqitura si rezultat i testimit të IOP, përpunohen dhe ndryshimet përfshihen në draft specifikimin.

5.1 Testimi i IOP

Objektivi kryesor i testimit IOP është të vërtetojë specifikimet nga, për shembullample, kontrollimi i saktësisë dhe paqartësisë brenda tekstit, reviewing për çdo gabim dhe lëshim themelor të projektimit, dhe sigurimin e vlefshmërisë kundrejt kërkesave të përcaktuara më parë të zhvilluara më herët në procesin e zhvillimit të specifikimeve. Testimi IOP mund të rezultojë në ndryshime në specifikimin e projektit dhe ngjarje të shumta të testit IOP mund të jenë të nevojshme për të përfunduar të gjithë testimin e kërkuar.

Importantshtë e rëndësishme t'u jepet mundësi anëtarëve jashtë GP të marrin pjesë në testimin e IOP sepse ata ofrojnë një të pavarur view të specifikimit dhe mund të zbulojë fusha të paqartësisë në specifikim që mund të mos jenë të dukshme për anëtarët e GP që kanë hartuar draftin. Para çdo ngjarje të testit të IOP, BSTS do të bëjë të disponueshme detajet e ngjarjes, specifikimin e fundit të draftit, Suite Test dhe planin e testit IOP dhe do të njoftojë të gjithë anëtarët në mënyrë ideale një muaj para çdo ngjarjeje. Draft specifikimi i azhurnuar, Test Suite dhe plani i testit IOP i përdorur në një ngjarje testimi IOP duhet të jetë i disponueshëm të paktën një javë para çdo ngjarjeje.

Gjatë testimit të IOP, kombinimet dyshe të platformave do të përpiqen të ekzekutojnë testet dhe pjesëmarrësit në testimin e IOP do të regjistrojnë rezultatet e kalimit / dështimit të secilit test dhe komente. Një përmbledhje anonime e këtyre rezultateve (duke iu referuar p.sh., "Platforma A", "Platforma B", etj.) Dhe çdo koment, do të mblidhet gjatë ngjarjeve të provës së IOP dhe do t'u vihet në dispozicion anëtarëve të GP gjatë dhe pas IOP. ngjarje provë. Në rast se nevojiten informacione shtesë për të kuptuar më mirë çdo koment ose dështim të ndodhur gjatë testimit të IOP, BSTS mund të veprojë si ndërmjetës për të mbledhur informacione të mëtejshme nga anëtari dorëzues.

Nëse është e mundur, PTS duhet të azhurnohet për të mbështetur testimin e IOP me platforma në të gjitha shtresat mbi Ndërfaqen e Kontrolluesit të Hostit (HCI), dhe të jetë i pranishëm në ngjarjet e provës IOP për ato shtresa. Mjete të tjera testimi mund të jenë gjithashtu të pranishme në ngjarjet e provës IOP. Një përmbledhje e rezultateve të testimit me PTS ose mjete të tjera të provës (nëse ka) duhet të përfshihet në raportin e testit të IOP.

Testimi i IOP do të jetë i hapur për të gjithë anëtarët që duan të ofrojnë një zbatim prototip, megjithatë, Bluetooth SIG mund të kushtëzojë pjesëmarrjen në pranimin e marrëveshjeve me Bluetooth SIG (përfshirë pjesëmarrjen dhe marrëveshjet e konfidencialitetit). GP është përgjegjëse për përpunimin dhe zgjidhjen e çështjeve të zbuluara gjatë testimit të IOP dhe azhurnimin e dokumenteve të prekura; Ndryshimet e miratuara nga GP duhet të përfshihen si azhurnime të draftit të specifikimeve dhe dokumenteve të provës për përdorim në secilën ngjarje të testimit të IOP.

Para Fazës së Vlerësimit, GP mund të kryejnë testimin paraprak të IOP në ngjarje që janë të hapura vetëm për anëtarët e GP, megjithatë rezultatet e testimit joformal mund të mos përfshihen në rezultatet e testit IOP.

Mund të ndodhë që të ndiqen të gjitha hapat që çojnë deri në ngjarjen e parë të testit IOP, duke përfshirë një datë dhe vendndodhje të njoftuar të IOP me synimin për të filluar testimin e IOP, por miratimi i BD nuk ishte siguruar para fillimit të ngjarjes së provës. Në këtë rast, BD mund të autorizojë përfshirjen e rezultateve të provave që janë mbledhur para miratimit të BD për të filluar testimin e IOP, me kusht që rezultatet e mbledhura të bazohen në të njëjtën specifikim dhe Test Suite të aprovohet nga BD.

Testimi i IOP nuk kërkohet për përmirësimet në specifikimet e CSS, GSS ose MDP.

Raporti i provës IOP
Pasi të ketë përfunduar testimi IOP, GP duhet të dorëzojë raportin e testit të IOP në BARB me qëllim të demonstrimit se numri i kërkuar i platformave të pavarura kanë kaluar testet e kërkuara. BARB duhet të riview dhe miraton ose refuzon raportin e testit të IOP dhe do të njoftojë GP nëse testimi IOP shtesë është i nevojshëm para se të dorëzoni paketën e specifikimit të Draft Votimit në BD. BSTS dhe GP duhet të sigurojnë që asnjë informacion identifikues i anëtarëve të mos shfaqet në raportin e testit të IOP para se ta dorëzoni raportin në BARB.

Raporti i testit IOP duhet të përmbajë:

Një listë e të gjitha ngjarjeve të testit IOP që ndodhën gjatë Fazës së Vlerësimit, duke përfshirë datat dhe vendndodhjet e tyre.
Numri i ndërmarrjeve anëtare dhe platformave të pavarura që morën pjesë në çdo ngjarje të IOP, përfshirë nëse është përdorur PTS.
Një listë e specifikimeve, Test Suite dhe versioneve të planit të provës IOP të përdorura në secilën ngjarje.
Një përmbledhje ekzekutive që tregon nëse të gjitha rastet e provës i plotësuan kriteret minimale të kalimit.
Një përmbledhje e çdo ndryshimi nga kërkesat e planit të provës IOP të përcaktuara në Seksionin 4.3.1 dhe arsyetimin për secilën ndryshim.
Një përmbledhje e mbulimit të PTS për rastet e provës në Test Suite.
Një listë e të gjitha rasteve të provës (përfshirë testet e pajtueshmërisë së prapambetur) nga plani i provës IOP, numri i provave të kaluara, numri i dështimeve të testit dhe nëse kriteret minimale janë përmbushur për çdo rast prove duke përfshirë një shpjegim pse ndonjë kërkesë nuk ishin u takua
Një përmbledhje e çështjeve, komenteve dhe pyetjeve në çdo ngjarje (përfshirë ato filed kundër specifikimit gjatë testimit të IOP) dhe ndikimit në specifikimet dhe dokumentet e testimit.

5.2 Kërkesat e daljes nga Faza e Vlerësimit

Faza e Vlerësimit ka përfunduar dhe Faza e Miratimit / Miratimit fillon kur BARB ka miratuar raportin e testit IOP (përveç nëse testimi është hequr dorë nga BARB) dhe të gjitha kërkesat e mëposhtme janë përmbushur:

BSTS ka vënë specifikimin e miratuar 0.9/CR në dispozicion për të gjithë anëtarët për Re Review siç kërkohet nga aktet nënligjore dhe njoftoi të gjithë anëtarët për disponueshmërinë e tij.
Të gjitha çështjet që janë identifikuar gjatë testimit të IOP dhe që kanë një ndikim në provë, janë përfshirë dhe testuar.
GP ka përfunduar testimin e IOP (përveç nëse testimi nuk është hequr nga BARB).

6. Faza e Miratimit / Miratimit

Gjatë Fazës së Miratimit/Miratimit, specifikimet dhe dokumentet e testit përkatës përfundojnë, BARB, BQRB dhe BTI miratohen, njoftimi për datën e propozuar të Miratimit lëshohet së bashku me versionin përfundimtar të draft specifikimit të paraqitur në BD për miratim ( Draft Voting), dhe pakoja përfundimtare e specifikimeve i paraqitet BD -së. Pas kohëzgjatjes minimale të anëtarit Review e kërkuar nga aktet nënligjore [2]) është përmbushur, BD do të marrë në konsideratë specifikimet për miratim në datën e adoptimit. Pas miratimit, specifikimi publikohet dhe sistemi i kualifikimit është aktivizuar. Faza e Miratimit/Miratimit është ilustruar në Figurën 6.1.

6.1 Projekt Votimi

Drafti i Votimit është krijuar duke përfshirë azhurnimet (të dhëna në Fazën e Vlerësimit) në dokumentet e kërkuara të specifikimit, dhe përgatitjen e një drafti përfundimtar të specifikimeve të reja. Për përmirësimet e specifikimit, BSTS do të krijojë specifikimin e integruar duke integruar një ose më shumë CR (a) në versionin më të lartë të specifikimit të miratuar më parë (shih Seksionin 4.3.2) nëse nuk ka përfunduar tashmë para Fazës së Vlerësimit.

Nëse bëhen ndryshime në specifikim gjatë kësaj faze dhe GP, BARB ose BTI përcakton se çdo ndryshim kërkon testimin shtesë të IOP, specifikimi do të kthehet në pjesën e testimit të IOP të Fazës së Vlerësimit për GP për të kryer testet shtesë. Gjatë Fazës së Miratimit / Miratimit, dokumentet e mëposhtme do të plotësohen dhe do të vihen në dispozicion të BD para datës së miratimit:

Drafti i Votimit
Të gjitha specifikimet mbështetëse (p.sh., CSS, GSS, MDP) siç kërkohet për specifikimin përkatës (ose përmirësimin), nëse nuk janë miratuar më parë
Për përmirësimet e specifikimeve, një version i ndjekur nga ndryshimi i versionit të specifikuar të specifikuar që tregon ndryshimet e propozuara në Projekt Votimin
Një përshkrim nga GP i çdo kërkese të pajtueshmërisë së prapambetur (siç përshkruhet në Seksionin 3.3.2) që nuk janë përmbushur dhe arsyetimi për ndonjë përjashtim
Një përshkrim nga GP -ja i çdo kërkese të planit të testit të IOP (siç përshkruhet në Seksionin 4.3.1) që nuk janë përmbushur dhe justifikimin për çdo devijim së bashku me raportin e testit të IOP (i cili mund të sigurohet duke siguruar një lidhje me një kopje në Bluetooth SIG webfaqe)
Një rekomandim nga GP për zhvlerësimin ose tërheqjen e çdo versioni (ve) të mëparshëm të specifikimit të miratuar së bashku me një justifikim, duke theksuar ndryshimet që nga 0.9/CR Stagrekomandim për fundin e jetës
Një përmbledhje, e përgatitur nga GP, e ndryshimeve në veçoritë ose funksionalitetin që nga specifikimi 0.9 / CR (nëse ka)
Një përmbledhje, e përgatitur nga BARB, e shqetësimeve të ngritura nga anëtarët e BARB se specifikimet e prodhuara nga GP janë përtej qëllimit të statutit të miratuar nga BD (nëse ka)
Një listë e çështjeve të mbetura të pazgjidhura juridike nga re ligjoreview (nëse ka)
Test Suite i aprovuar nga BTI, së bashku me përmbledhjen e miratuar nga GP për mbulimin e testit të specifikimeve të Projekt Votimit. Në rast të funksionalitetit të shtuar rishtas ose të modifikuar pa mbulim të provës, kërkohet një arsyetim me shkrim për lëshimin
ICS dhe IXIT të aprovuara nga BTI (nëse kërkohet nga specifikimi)
TCRL e aprovuar nga BTI dhe BQRB
Një raport i përgatitur nga BSTS së bashku me BTI në lidhje me statusin e gatishmërisë së mjetit (p.sh., PTS dhe mjete të tjera të provës, Bluetooth Launch Studio) duke përfshirë nëse ndonjë rast testimi në TCRL nuk mbështetet nga mjetet e provës
Një përmbledhje, e përgatitur nga GP, e të gjithë numrave të caktuar të caktuar
Një listë e plotë e birësimit e përgatitur nga BSTS dhe GP që tregon se të gjitha produktet e dorëzueshme në këtë pjesë janë përfunduar të gjitha
Të gjitha informacionet e tjera të kërkuara nga BD

Gjatë Fazës së Miratimit / Miratimit, GP duhet të përdorë sistemin e ndjekjes së çështjeve Bluetooth SIG për të kapur çështje dhe komente kundër specifikimit të projektit dhe dokumenteve të provës në mënyrë që ato të llogariten në finalizimin e specifikimeve të Projekt Votimit. Për një përmirësim të specifikimit, të gjitha erratat përkatëse të miratuara (dmth. Ato errata të miratuara nuk janë integruar ende) duhet të përfshihen, dhe duhet të identifikohen duke përdorur ndryshimet e gjurmuara.

GP -ja duhet të dorëzojë draft specifikimin përfundimtar në BSTS për rishikim ligjorviewMe Për specifikimet e reja, ri ligjoreview do të përfshijë të gjithë specifikimin. Për përmirësimet e specifikimeve, riview do të përqëndrohet kryesisht në pjesët e ndryshuara të specifikimit. Qëllimi i ri ligjoreview është kryesisht për të identifikuar rreziqet ligjore që GP duhet të marrë parasysh dhe të kërkojë t'i zgjidhë. Reagimet ligjore do të kategorizohen në bazë të ashpërsisë. Nëse një ri ligjore opsionaleview është kryer në 0.9/CR Stage, versioni që paraqitet për ri -ligjorview duhet të tregojë, si ndryshime të gjurmuara, të gjitha ndryshimet që janë bërë që nga ai version (të krijuara ose nga WG ose BSTS). Pas përfundimit të ri ligjoreview, GP dhe BSTS do të bien dakord për reagimet që do të përfshihen në draft specifikimet. Nëse ka ndonjë koment ligjor të pazgjidhur nga juridike review në draftin e specifikimit, Kryetari i GP -së mund të kërkojë kohë në agjendën e BD -së për të rënë dakord mbi zgjidhjen.

Paralelisht me re ligjoreview, GP duhet të dorëzojë draftin e specifikimit në BARB për riviewMe Me dorëzimin fillestar në BARB, BSTS do të njoftojë të gjithë anëtarët se draft specifikimi i është dorëzuar BARB -it përview dhe se është gjithashtu në dispozicion për anëtarët ReviewMe Nëse GP-ja paraqet azhurnime në draft specifikimin për ri-rikthimin e BARBview, BSTS do të dërgojë njoftime shtesë për të gjithë anëtarët në mënyrë periodike.

Pas përfundimit të BARB review, GP dhe BARB do të bien dakord për reagimet që do të përfshihen në draft specifikimet.

Nëse re ligjoreview rezulton në çdo ndryshim thelbësor, ri shtesëview nga BARB mund të kërkohet. Në mënyrë të ngjashme, nëse BARB riview rezulton në çdo ndryshim thelbësor, BSTS do të përcaktojë nëse do të ketë një shtesë ligjoreview nga ato ndryshime kërkohet. Pas përfundimit të ri ligjoreview dhe BARB review, BARB ose duhet të miratojë ose refuzojë Draftin e Votimit.

Nëse ndonjë dokument i provës kërkon azhurnimin, BSTS do të ndihmojë GP në azhurnimin e dokumenteve të provës. BTI ose duhet të miratojë ose refuzojë dokumentet e provës. Nëse miratohet nga BTI, BTI do të ndihmojë në finalizimin e TCRL dhe do t'ia dorëzojë këtë dokument BQRB së bashku me SHKB, IXIT dhe Test Suite të shoqëruara. BSTS do të vlerësojë datën e mbledhjes së BD kur BD synon të votojë mbi miratimin e Projektit të Votimit (Data e Miratimit) dhe t'i sigurojë BTI për përdorim në TCRL. Miratimi BARB i specifikimit, miratimi BTI i të gjitha dokumenteve të provës (përfshirë Test Suite, TCRL, ICS dhe IXIT) dhe miratimi i BQRB i TCRL duhet të ndodhë në ose para datës së birësimit.

BSTS do të informojë të gjithë anëtarët për finalizimin dhe disponueshmërinë e Draftit të Votimit dhe Data e Miratimit. Data e adoptimit do të caktohet jo më herët se 60 ditë pasi anëtarët të jenë njoftuar për specifikimet 0.9/CR të miratuara nga BD, përveç rasteve kur Anëtari Review periudha shkurtohet nga BD në përputhje me Aktet nënligjore, dhe të paktën 14 ditë pas njoftimit për datën e birësimit u jepet anëtarëve në përputhje me Rregulloret. Për rastet kur CR -të e shumta janë integruar në një Draft Votim, fillimi i anëtarit Review është data në të cilën anëtarët u njoftuan për CR më të fundit të miratuar nga BD.

Pas njoftimit të anëtarëve për datën e miratimit, lejohen korrigjimet e miratuara nga BD për gabimet tipografike në draftin e votimit. Afati kohor i specifikimit të miratimit ilustrohet në figurën 6.2.

6.2 Numrat e caktuar

Bluetooth SIG mban një grup publik të disponueshëm të numrave të caktuar në numrat e caktuar të SIG Bluetooth websiti [7]. Këta numra të caktuar grupohen në hapësira të ndryshme numrash (një grup numrash të ndërlidhur pa kopjime). Numrat e caktuar mund të mbivendosen me numrat e tjerë të caktuar në hapësira të ndryshme numrash, por asnjë numër brenda një hapësire numrash nuk lejohet të ripërdoret. Hapësira të ndryshme të numrave përcaktohen në specifikimin që përcakton përdorimin e numrave të caktuar.

Pasi BARB të miratojë raportin e testit të IOP, GP do t'i paraqesë një kërkesë BARB për caktimin e numrave të rinj brenda hapësirës (ave) të numrave të kërkuar nga specifikimi përfundimtar. BARB do të riview kërkesën dhe punën me BSTS për të përcaktuar numrat e caktuar. Me miratimin e BARB, BSTS do të caktojë publikimin e numrave të caktuar që do të bëhen publikisht në dispozicion në numrat e caktuar të SIG Bluetooth webfaqe [7] brenda një jave nga miratimi i specifikimit.

Pasi publikimi i numrave të caktuar në Bluetooth SIG Assigned Numbers webnë sit ose brenda një specifikimi të miratuar, numrat e caktuar synohen të jenë të pandryshueshëm (të mos ndryshojnë as në vlerë dhe as në kuptim). Nëse ato bëhen të papërdorshme për ndonjë arsye, ato bëhen vlera të rezervuara dhe nuk lejohen të ripërdoren.

6.3 Kërkesat e fazës së miratimit / aprovimit

Faza e Miratimit / Adoptimit është e plotë kur BD ka miratuar specifikimin dhe aktivitetet e mëposhtme pas miratimit kanë përfunduar:

BSTS ka vënë në dispozicion publikisht numrat e caktuar të caktuar në Bluetooth SIG webfaqe.
BSTS i ka bërë të disponueshme publikisht specifikimet e miratuara në Bluetooth SIG webfaqe
BSTS ka bërë të disponueshme publikisht të gjitha dokumentet mbështetëse (p.sh., CSS, GSS, MDP) për specifikimet përkatëse në Bluetooth SIG webfaqe.
BSTS ka vënë në dispozicion dokumentet e testit të lidhur për të gjithë anëtarët në Bluetooth SIG webfaqe.
Për përmirësimet e specifikimeve, BSTS ka bërë një version informativ të përcjellë me ndryshime të versionit të specifikimit të miratuar më parë me të gjitha ndryshimet e bëra nga versioni i sapo miratuar dhe e ka vënë atë në dispozicion për të gjithë anëtarët në Bluetooth SIG webfaqe.
BSTS ka mundësuar sistemin e kualifikimit.
BSTS ka njoftuar të gjithë anëtarët për disponueshmërinë e specifikimeve të miratuara dhe të gjitha dokumentet mbështetëse.

Bluetooth SIG planifikon të përfundojë këto aktivitete pas birësimit brenda një jave pas miratimit të specifikimit.

7. Faza e Mirëmbajtjes së Specifikimeve

Faza e Mirëmbajtjes së Specifikimit fillon pasi të ketë përfunduar Faza e Miratimit / Miratimit. Nëse gjenden probleme (p.sh. paqartësi formulimi ose gabime teknike) me specifikimin ose dokumentet e lidhura të provës, ato duhet të dokumentohen duke krijuar propozime errata duke përdorur mjetin Bluetooth SIG Errata. Propozimet e erratumit të specifikimit do të përpunohen, kategorizohen dhe miratohen në përputhje me EPD [3]. Erratumi i Test Suite përpunohet dhe kategorizohet sipas TSTO [5]. Nëse ka ndonjë konflikt midis SMPD dhe EPD ose TSTO, SMPD merr përparësi.

Erratumi i specifikimit duhet të përdoret vetëm për të korrigjuar gabimet teknike ose editoriale në specifikimet e fundit të miratuara të Bluetooth. Shtimi, ndryshimi dhe heqja e funksionalitetit mund të bëhen vetëm me anë të procesit të përmirësimit të specifikimit të përcaktuar më parë në këtë dokument.

7.1 Procesi i shpejtimit të erratumit

Kur një gabim miratohet duke ndjekur procesin e përcaktuar në EPD [3], GP, BARB ose BSTS mund të rekomandojnë që të konsiderohet urgjente dhe duhet përshpejtuar. Kur kjo ndodh, BSTS së bashku me GP ose BARB do t'i paraqesin rekomandimin BD. BD do të vendosë nëse do ta pranojë ose refuzojë rekomandimin. Nëse rekomandimi pranohet, BSTS do të përfshijë menjëherë gabimin e miratuar në modelin e gabimit [8] dhe do të punojë me GP përgjegjës për të finalizuar një Korrigjim të Erratuar të Shpejtuar që do t'i paraqitet GP -së përview dhe aprovimin.

Një mbiview i procesit të shpejtuar të gabimit është ilustruar në Figurën 7.1.

Dokumentet e mëposhtme duhet të plotësohen dhe t'i vihen në dispozicion BD para datës së miratimit:

Drafti i aprovuar nga BARB Korrigjimi i Shpejtë i Errata.
Një përshkrim nga GP i çdo kërkese të pajtueshmërisë së prapambetur (siç përshkruhet në Seksionin 3.3.2) që nuk janë përmbushur dhe arsyetimi për ndonjë përjashtim.
Një listë e çështjeve të mbetura të pazgjidhura juridike nga re ligjoreview (nëse ka).
Test Suite, ICS dhe IXIT të aprovuar nga BTI (nëse kërkohet nga erratumi).
TCRL të aprovuara nga BTI dhe BQRB (nëse kërkohet nga erratumi).
Një raport i kompletuar nga BSTS së bashku me BTI në lidhje me statusin e gatishmërisë së mjetit (p.sh., PTS dhe mjete të tjera të provës, Bluetooth Launch Studio) duke përfshirë nëse ndonjë rast testimi në TCRL nuk mbështetet nga mjetet e provës dhe një shpjegim (nëse kërkohet nga errati )
Një listë e plotë e birësimit e plotësuar nga BSTS dhe GP që tregon se produktet e dorëzimit në këtë pjesë janë përfunduar të gjitha.
Të gjitha informacionet e tjera të kërkuara nga BD.

BSTS do të punojë me GP përgjegjëse për të finalizuar draftin e Korrigjimit të Përshpejtuar të Erratës dhe për të krijuar një version për t'iu dorëzuar GP -së përgjegjëse përview dhe aprovimin.

GP -ja duhet të dorëzojë Korrigjimin e Përshpejtuar të Erratës në BSTS për rigjykim ligjorviewMe Pas përfundimit të ri ligjoreview, GP dhe BSTS do të bien dakord mbi reagimet që do të përfshihen në Korrigjimin e Erratuar të Shpejtuar. Nëse ka ndonjë koment ligjor të pazgjidhur nga juridike review në Korrigjimin e Përshpejtuar të Erratës, Kryetari i GP mund të kërkojë kohë në axhendën e BD për të kërkuar kontributin e BD për zgjidhjen.

Paralelisht me re ligjoreview, GP duhet të paraqesë Korrigjimin e Përshpejtuar të Erratës në BARB për riviewMe Pasi Korrigjimi i Përshpejtuar i Erratës të paraqitet në BARB, BSTS do ta bëjë të arritshme për të gjithë anëtarët që tëview dhe njoftoni të gjithë anëtarët për disponueshmërinë e tij. Pas përfundimit të BARB review, GP dhe BARB do të bien dakord për reagimet që do të përfshihen në Korrigjimin e Erratuar të Shpejtuar.

Nëse ndonjë dokument i provës kërkon azhurnimin, BSTS do të ndihmojë GP në azhurnimin e dokumenteve të provës. Pas aprovimit nga BTI të dokumenteve të provës, BTI do të ndihmojë në finalizimin e TCRL dhe do t'ia dorëzojë dokumentin BQRB së bashku me ICS, IXIT dhe Test Suite të shoqëruara, siç është e zbatueshme. BSTS do të vlerësojë datën e miratimit dhe do t'ia sigurojë atë BTI për përdorim në TCRL. Miratimi BARB i Korrigjimit të Shpejtë të Errata, miratimi BTI i të gjitha dokumenteve të provës (përfshirë Test Suite, TCRL, ICS dhe IXIT sipas rastit) dhe miratimi i BQRB i TCRL duhet të ndodhë në ose para datës së birësimit.

BSTS do të informojë të gjithë anëtarët për finalizimin dhe disponueshmërinë e Korrigjimit të Shpejtë të Errata dhe datës së propozuar të Birësimit. Data e Adoptimit do të caktohet dhe do t'u njoftohet të gjithë anëtarëve në përputhje me Rregulloren [2] dhe Data e Adoptimit do të jetë të paktën 14 ditë pasi njoftimi t'u sigurohet anëtarëve. Pasi njoftimi për datën e propozuar të miratimit u është dhënë anëtarëve, BD-ja mund të miratojë korrigjimet e gabimeve tipografike në Korrigjimin e Shpejtë të Errata pa dhënë një njoftim shtesë të datës së propozuar të Birësimit dhe duke pritur 14 ditët e kërkuara.

Bluetooth SIG do ta bëjë publikisht të disponueshëm Korrigjimin e përshpejtuar të Errata të miratuar dhe planifikon ta bëjë këtë brenda një jave pas miratimit. Njoftimi për disponueshmërinë e tij do të lëshohet nga BSTS për të gjithë anëtarët.

Procesi i përshpejtuar i erratumit është i plotë kur BD ka miratuar Korrigjimin e Shpejtë të Errata dhe aktivitetet e mëposhtme pas miratimit kanë përfunduar:

BSTS ka bërë korrigjimin e miratuar të Erratës të miratuar dhe dokumentet e provës të lidhura (nëse kërkohet nga gabimi) të jenë publikisht të disponueshme në Bluetooth SIG webfaqe.
BSTS ka mundësuar sistemin e kualifikimit (nëse kërkohet nga erratumi).
BSTS ka njoftuar të gjithë anëtarët për disponueshmërinë e Korrigjimit të Përshpejtuar të Errata të miratuar.

Në përfundim të këtyre aktiviteteve, Korrigjimi Errata do të planifikohet për integrim në specifikimet e prekura ose si pjesë e një përmirësimi të specifikuar të specifikimit ose në një lëshim të ardhshëm të mirëmbajtjes siç përshkruhet në Seksionin 7.2.

7.2 Procesi i lëshimit të mirëmbajtjes (specifikimet .Z)

Në baza afërsisht vjetore, BSTS do të përcaktojë nëse ka ndonjë errata të miratuar (referuar si Korrigjime Errata) që klasifikohen si Teknike / të Larta ose Teknike / Kritike dhe që ende nuk janë përfshirë në tekstin e ndonjë specifikimi aktiv (dmth., një specifikim i miratuar që nuk është zhvlerësuar ose tërhequr). Shihni Shtojcën A për përkufizimet e klasifikimit të erratave. Një Pronar i Specifikimit (ose GP i emëruar për të ruajtur specifikimin, ose BARB nëse asnjë GP nuk është i regjistruar për të ruajtur specifikimin) gjithashtu mund të kërkojë një lëshim më të hershëm të mirëmbajtjes së një specifikimi aktiv në të cilin do të përfshihen çdo errata të miratuar. Me përcaktimin e BSTS, ose me kërkesën e Pronarit të Specifikimit, procesi i lëshimit të mirëmbajtjes do të fillojë.

Një mbiview i procesit të lëshimit të mirëmbajtjes është ilustruar në Gabim! Burimi i referencës nuk u gjet.

Në fillim të procesit të lëshimit të mirëmbajtjes, BSTS së bashku me Pronarin e Specifikimit, BARB dhe BTI do të zhvillojnë dhe paraqesin një plan për BD për përfshirjen e Korrigjimeve Errata në versionin e botuar të specifikimeve. Plani i propozuar duhet të tregojë nëse Korrigjimet Errata do të përfshihen në një njoftim mirëmbajtje të specifikimit (dmth., Një version .Z) ose një përmirësim specifikimi që është tashmë në proces (dmth., Një version XY). Plani i propozuar duhet të marrë parasysh nëse janë shtuar ndonjë tipar i ri i detyrueshëm midis versioneve të specifikimeve të miratuara, kohës së parashikuar kur përmirësimi i specifikimit të ardhshëm është planifikuar për birësim dhe faktorëve të tjerë.

Pas miratimit të një plani nga BD, BSTS së bashku me Pronarin e Specifikimit do të vazhdojnë të përfshijnë të gjitha Korrigjimet Errata Teknike / të Mesme, Teknike / të Larta dhe Teknike / Kritike në një specifikim të projektit të referuar si "Drafti i Lirimit të Mirëmbajtjes". Për korrigjimet redaktuese ose teknike / të ulta të gabimeve, nëse Korrigjimi i Erratave zbatohet për më shumë se një version të specifikimeve, BSTS do, përveç nëse BD tregon ndryshe, do t'i integrojë ato errata në vetëm versionin më të fundit të specifikimeve më të larta në azhurnimin tjetër të këtij versioni . Asnjë ndryshim nuk mund të përfshihet në një Draft Publikimi të Mirëmbajtjes përveç përfshirjes së Korrigjimeve Errata. Çdo draft i lëshimit të mirëmbajtjes duhet të identifikojë të gjitha korrigjimet e përfshira në Errata duke përdorur ndjekjen e ndryshimeve për të treguar ndryshimet e propozuara në versionin e miratuar më parë të specifikimeve të botuara.

Koha e përfshirjes së propozuar për secilin korrigjim Errata në një draft të lëshimit të mirëmbajtjes do të varet nga ndikimi i Test Suite: të gjitha Korrigjimet e Errata që nuk kanë ndikim të Test Suite mund të përfshihen menjëherë, por Korrigjimet e Errata që ndikojnë në Test Suite do të jenë të përpunuara në mënyrë që koha të përkojë me një azhurnim të TCRL.

BTI dhe BSTS do të përcaktojnë një afat përfundimtar për përfshirjen e Korrigjimeve Errata me ndikimin e Test Suite në një Projekt të Lirimit të Mirëmbajtjes. Ky afat është zakonisht 3 deri në 6 muaj para datës së planifikuar të miratimit të lëshimit tjetër të madh TCRL. Korrigjimet e Errata me ndikimin e Test Suite që humbin afatin e përfshirjes do të përpunohen si pjesë e daljes tjetër vjetore të TCRL. Prandaj, përveç nëse kërkohet një lëshim më i hershëm, koha maksimale për Korrigjimet Errata Teknike / të Larta ose Teknike / Kritike që do të përfshihen në një azhurnim specifikimi është afërsisht 15 deri në 18 muaj.

Pronari i Specifikimit duhet të paraqesë Draftin e Lirimit të Mirëmbajtjes që ka miratuar si përfundimtar për ri -ligjorviewMe Re ligjoreview do të përqëndrohet kryesisht në pjesët e ndryshuara të specifikimit. Pas përfundimit të ri ligjoreview, Pronari i Specifikimit dhe BSTS do të bien dakord për reagimet që do të përfshihen në Draftin e Lirimit të Mirëmbajtjes. Nëse ka ndonjë koment ligjor të pazgjidhur nga juridike review në Draftin e Lirimit të Mirëmbajtjes, Pronari i Specifikimit mund të kërkojë kohë në axhendën e BD për të kërkuar kontributin e BD për zgjidhjen.

Paralelisht me re ligjoreview, pronari i Specifikimit duhet të paraqesë draftin e lëshimit të mirëmbajtjes në BARB për riviewMe Pasi Drafti i Lirimit të Mirëmbajtjes të dorëzohet në BARB, BSTS do ta bëjë atë të arritshëm për të gjithë anëtarët që tëview dhe njoftoni të gjithë anëtarët për disponueshmërinë e tij. Pas përfundimit të BARB review, Pronari i Specifikimit dhe BARB do të bien dakord për reagimet që do të përfshihen në draft specifikimin.

Për Korrigjimet e Erratave që ndikojnë në dokumentet e provës dhe ku errata përkatëse e testit do të përpunohet me kohë për lëshimin e ardhshëm TCRL, BSTS do të punojë me Pronarin e Specifikimit dhe BTI për të azhurnuar dokumentet e provës. Pas aprovimit nga BTI të dokumenteve të provës, BSTS do të vlerësojë datën e adoptimit dhe do t'ia sigurojë datën e propozuar të miratimit BTI për përdorim në TCRL. BTI do të dorëzojë TCRL në BQRB së bashku me ICS, IXIT dhe Test Suite të shoqëruara siç është e zbatueshme. Miratimi BARB i specifikimit, miratimi BTI i të gjitha dokumenteve të provës (përfshirë Test Suite, TCRL, ICS dhe IXIT siç është e zbatueshme), dhe miratimi i BQRB i TCRL duhet të ndodhë në ose para datës së birësimit.

BSTS do të informojë të gjithë anëtarët për finalizimin dhe disponueshmërinë e Projektit të Votimit dhe datës së propozuar të Miratimit. Data e Adoptimit do të caktohet dhe do t'u njoftohet të gjithë anëtarëve në përputhje me Rregulloren dhe Data e Adoptimit do të jetë të paktën 14 ditë pasi njoftimi për anëtarët të jetë dhënë. Pasi njoftimi për datën e propozuar të miratimit u është dhënë anëtarëve, BD-ja mund të miratojë korrigjimet e gabimeve tipografike në Projekt Votimin pa dhënë një njoftim shtesë për një Datë të Propozuar të Birësimit dhe duke pritur 14 ditët e kërkuara.

Dokumentet e mëposhtme duhet të plotësohen dhe t'i vihen në dispozicion BD para datës së miratimit:

Drafti i Votimit
Një version i ndjekur nga ndryshimi i Projektit të Votimit që tregon të gjitha ndryshimet në versionin e miratuar të specifikimit që ka të njëjtën vlerë XY (p.sh., nëse Drafti i Votimit propozohet si version 1.4.2, ndryshimet do të gjurmohen kundrejt 1.4.1 versioni i specifikimit)
Një rekomandim nga Pronari i Specifikimit për zhvlerësimin ose tërheqjen e çdo versioni (a) të mëparshëm të specifikimit të miratuar së bashku me një justifikim
Një listë e çështjeve të mbetura të pazgjidhura juridike nga re ligjoreview (nëse ka)
Test Suite, ICS dhe IXIT të aprovuar nga BTI (nëse kërkohet nga lëshimi i mirëmbajtjes)
TCRL të aprovuara nga BTI dhe BQRB (nëse kërkohet nga lëshimi i mirëmbajtjes)
Një raport i kompletuar nga BSTS së bashku me BTI në lidhje me statusin e gatishmërisë së mjetit (p.sh., PTS dhe mjete të tjera të provës, Bluetooth Launch Studio) duke përfshirë çdo rast testimi në TCRL që nuk mbështetet nga mjetet e provës dhe shpjegimin (nëse kërkohet nga mirëmbajtja lëshimi)
Një listë e plotë e birësimit e plotësuar nga BSTS dhe Pronari i Specifikimit që tregon se produktet e dorëzimit në këtë seksion janë përfunduar të gjitha
Të gjitha informacionet e tjera të kërkuara nga BD

Procesi i lëshimit të mirëmbajtjes është i plotë kur BD ka miratuar Projekt Votimin dhe aktivitetet e mëposhtme pas miratimit kanë përfunduar:

BSTS i ka bërë të disponueshme publikisht specifikimet e miratuara dhe dokumentet e provës të lidhura (nëse kërkohet nga lëshimi i mirëmbajtjes) në Bluetooth SIG webfaqe.
BSTS ka bërë një version informativ të përcjellë me ndryshime të versionit të specifikimit të miratuar më parë me të gjitha ndryshimet e përfshira në versionin e sapo miratuar në dispozicion për të gjithë anëtarët në Bluetooth SIG webfaqe.
BSTS ka mundësuar sistemin e kualifikimit.
BSTS ka njoftuar të gjithë anëtarët për disponueshmërinë e specifikimeve të miratuara dhe dokumenteve mbështetëse.

Bluetooth SIG planifikon të përfundojë këto aktivitete pas birësimit brenda një jave pas miratimit të specifikimit.

Në përfundim të këtyre aktiviteteve, specifikimi mbetet në fazën e Mirëmbajtjes së Specifikimit derisa specifikimi të zhvlerësohet ose të tërhiqet, siç përcaktohet në Seksionin 8.

8. Specifikimi Faza e Fundit të Jetës

Specifikimet mund të zhvlerësohen ose tërhiqen kur ato zëvendësohen nga versione të reja, të përcaktuara si teknikisht të pamjaftueshme, ose për arsye të tjera. Specifikimet e amortizuara dhe të tërhequra arkivohen dhe nuk azhurnohen më. Specifikimet e amortizuara dhe të tërhequra trajtohen ndryshe në Programin e Kualifikimit Bluetooth.

Çdo anëtar, grup ose komision mund të paraqesë rekomandime për të zhvlerësuar ose tërhequr një specifikim së bashku me një kronologji të lidhur me BSTS (përmes postës elektronike te

specifikim.manager@bluetooth.com) në çdo kohë. BSTS gjithashtu mund të rekomandojë zhvlerësimin ose tërheqjen e një specifikimi dhe afatit përkatës. BSTS do t'i referohet rekomandimit BARB dhe grupit ose komitetit përgjegjës për ruajtjen e specifikimit për riview dhe reagime.

BARB dhe grupi ose komiteti përgjegjës do të vlerësojnë rekomandimet për të zhvlerësuar ose tërhequr një specifikim dhe të marrin në konsideratë kriteret e mëposhtme (jo-shteruese):

A ka funksionalitet në një version të mëparshëm të specifikimit që është vjetëruar ose nuk duhet të përdoret?
A është shtuar funksionalitet i ri i detyrueshëm në versionet e mëvonshme?
A ka mangësi në versionet e mëparshme që dëmtojnë funksionimin ose ndërveprimin që janë korrigjuar në versionet e mëvonshme dhe janë të nevojshme për të avancuar skenarët ekzistues të përdoruesve?
A ka ndonjë funksionalitet shtesë në versionet e mëvonshme të nevojshme për të çuar përpara skenarët e rinj të përdoruesve?
A ka përmirësim të përdorshmërisë dhe ndërveprimit në versionet e mëvonshme?
A ka përmirësime të sigurisë në versionet e mëvonshme?

BARB dhe grupi ose komiteti përgjegjës mund të propozojnë një rekomandim alternativ.

Pas marrjes së reagimeve nga BARB ose grupi ose komiteti përgjegjës për ruajtjen e specifikimit, BSTS do t'i dorëzojë rekomandimet (rekomandimet) dhe reagimet tek BD për shqyrtim. BD mund të ftojë grupin ose komitetin që është përgjegjës për ruajtjen e specifikimeve të prekura për t'u takuar dhe diskutuar rekomandimet. BD do të marrë parasysh rekomandimet dhe reagimet dhe mund të pajtohet me ose modifikojë propozimin. BD do të kërkojë që BSTS të njoftojë të gjithë anëtarët për propozimet për të zhvlerësuar ose tërhequr specifikimet (et) dhe afatin (et) përkatës për një rivlerësim 30-ditorview periudhë për të lejuar të gjithë anëtarët të japin reagime shtesë para se të marrin vendimin përfundimtar.

BD do të marrë në konsideratë reagimet e marra nga anëtarët. Sapo BD të aprovojë amortizimin ose tërheqjen e një specifikimi, BSTS do të njoftojë të gjithë anëtarët për vendimin dhe kronologjinë përkatëse.

8.1 Amortizimi

Sapo të specifikohet një specifikim, do të ndodhë më poshtë:

Specifikimi nuk do të azhurnohet më.
GP përgjegjëse do të riview të gjitha gabimet e shquara të shkruara kundër specifikimeve të vjetruara për të përcaktuar nëse ato zbatohen për specifikimet e tjera. Errata mund të refuzohet në sistemin e errata dhe të rishkruhet kundër specifikimeve (ve) të zbatueshme.
GP ose BSTS do të krijojë errata për të azhurnuar çdo referencë të nevojshme për specifikimet e vjetruara në specifikimet e tjera.
BTI do të azhurnojë dokumentet e zbatueshme të provës për të treguar zhvlerësimin e specifikimit.
BSTS do të përditësojë Bluetooth SIG webfaqe me udhëzime në lidhje me specifikimet (et) alternative për t'u përdorur.
Errata të reja nuk mund të dorëzohen më kundrejt një specifikimi të amortizuar.
Specifikimet nuk do të referohen në asnjë specifikim të ardhshëm.
BSTS do të arkivojë një version të specifikimit të shënuar si të amortizuar që anëtarët të kenë qasje për qëllime historike.

8.2 Tërheqja

Sapo të tërhiqet një specifikim, përveç hapave që zbatohen për zhvlerësim, do të ndodhë sa vijon:

BTI do të azhurnojë dokumentet e zbatueshme të provës për të treguar tërheqjen e specifikimit.
BSTS do të përditësojë Bluetooth SIG webfaqe me udhëzime në lidhje me specifikimet (et) alternative për t'u përdorur.
BSTS do të arkivojë një version të specifikimeve të shënuar si të tërhequr për anëtarët për të hyrë për qëllime historike.

BD mund të zgjedhë të tërheqë një specifikim menjëherë pa i zhvlerësuar më parë specifikimet.

9. Procesi i letrës së bardhë

Dokumentet e bardha krijohen vetëm për qëllime informative. Procesi i mëposhtëm i letrës së bardhë vlen për të gjitha GP-të, EG-të, SG-të dhe komitetet Bluetooth. Ky seksion nuk zbatohet për dokumentet informuese për përdorim vetëm brenda Bluetooth SIG.

Ky proces ilustrohet në Figurën 9.1 më poshtë.

Para se ndonjë grup ose komision të fillojë punën për një letër të bardhë që ata synojnë të botohen nga Bluetooth SIG, grupi ose komiteti do të përgatisë si një azhurnim të propozuar të kartës që përcakton qartë përmbajtjen e propozuar të letrës së bardhë ashtu edhe një prezantim të propozimit të një letre të bardhë.

Paraqitja e propozimit të letrës së bardhë duhet të përfshijë së paku:

Nevoja për letrën e bardhë
Një përmbledhje e përmbajtjes së propozuar të letrës së bardhë
Një shpjegim pse përmbajtja nuk rekomandohet të përfshihet si pjesë e një specifikimi
Audienca e synuar
Çdo plan mirëmbajtjeje (p.sh., koha e parashikuar para botimit të ardhshëm të kësaj letre të bardhë mund të jetë e nevojshme)
Rekomandime për mënyrën e trajtimit të versioneve të mëparshme të letrës së bardhë, nëse ka (p.sh. arkivimi)

Përditësimi i statutit dhe prezantimi i propozimit të letrës së bardhë duhet të dorëzohen për BARB reviewMe Pas riview dhe miratimin e azhurnimit të statutit nga BARB, BSTS do t'i paraqesë përditësimin e statutit në BD për miratim së bashku me prezantimin mbështetës të propozimit të letrës së bardhë.

Nëse BD miraton azhurnimin e statutit, grupi ose komiteti mund të vazhdojë me zhvillimin e letrës së bardhë.

Kur grupi ose komiteti të ketë përfunduar zhvillimin e letrës së bardhë, BSTS do të kryejë një redaktim redaktuesview për pajtueshmëri me Udhëzimet për hartimin e Bluetooth.

Pas zgjidhjes së komenteve të BSTS, grupi duhet të dorëzojë letrën e bardhë në BSTS për ri -ligjorviewMe Pas përfundimit të ri ligjoreview, grupi dhe BSTS do të bien dakord për reagimet që do të përfshihen në letrën e bardhë. Nëse ka ndonjë koment ligjor të pazgjidhur nga juridike review në letrën e bardhë, kryesuesi i grupit mund të kërkojë kohë në axhendën e BD për të kërkuar kontributin e BD për zgjidhjen.

Paralelisht me re ligjoreview, grupi duhet të dorëzojë letrën e bardhë në BARB për riviewMe Si pjesë e ri të tyreview, BARB mund të rekomandojë nëse ndonjë pjesë e letrës së bardhë duhet të hiqet nga letra e bardhë dhe të përfshihet në një specifikim pas procesit në Seksionin 3. BARB gjithashtu mund të vendosë që t'ia dorëzojë letrën e bardhë grupeve ose komiteteve të tjera për riviewMe Pas përfundimit të BARB review, grupi dhe BARB do të bien dakord për reagimet që do të përfshihen në letrën e bardhë.

Pasi BARB të miratojë letrën e bardhë, letra e bardhë e aprovuar nga BARB do të paraqitet nga grupi autoritar ose komiteti pranë BD për miratim.

Procesi i letrës së bardhë është i plotë kur BD ka miratuar letrën e bardhë dhe aktivitetet e mëposhtme pas miratimit kanë përfunduar:

BSTS e ka bërë letrën e bardhë të miratuar publike të disponueshme në Bluetooth SIG webfaqe.
BSTS njofton të gjithë anëtarët e letrës së bardhë të miratuar.
Nëse letra e bardhë është një përmirësim i një letre të bardhë ekzistuese, BSTS do të arkivojë një version të letrës së bardhë që anëtarët të kenë qasje për qëllime historike.

Bluetooth SIG planifikon të përfundojë aktivitetet pas miratimit brenda një jave pas miratimit të letrës së bardhë.

10. Referencat

Dokumentet e referuara Bluetooth janë në dispozicion nga Bluetooth webfaqe http://www.bluetooth.com.

Udhëzimet për Hartimin e Bluetooth (në dispozicion në faqen e Modelit dhe Dokumenteve të Grupit të Punës, në https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Rregulloret e Bluetooth SIG, Inc. (në dispozicion në faqen e Dokumenteve Qeverisëse, në https://www.bluetooth.com/membership-working-groups/membership-types-levels/membership-agreements)
Dokumenti i Procesit Errata Specifikimi i Bluetooth (i disponueshëm në faqen Modelet & Dokumentet e Grupit të Punës, në https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Dokumenti i Procesit të Grupit Punues (i disponueshëm në faqen e Modelit dhe Dokumentit të Grupit të Punës, në https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Strategjia e Testit dhe Terminologjia Përfunduanview dokument (i disponueshëm në faqen Kërkesat e Testit të Kualifikimit, në https://www.bluetooth.com/specifications/qualification-test-requirements)
Specifikimi i BTI Review Lista kontrolluese e procesit (e disponueshme në faqen e Modeleve dhe Dokumenteve të Grupit të Punës, në https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Numrat e caktuar Bluetooth SIG (https://www.bluetooth.com/specifications/assigned-numbers)
Modelet dhe Dokumentet e Grupit të Punës (në dispozicion në faqen e Modelit dhe Dokumentit të Grupit të Punës, në https://www.bluetooth.com/membership-working-groups/working-groups/working-group-templates-documents)
Shtojca e Specifikimit GATT (GSS) (e disponueshme në faqen Specifikimet e GATT, në https://www.bluetooth.com/specifications/gatt)
Paraqisni një ide për një specifikim të ri https://www.bluetooth.com/specifications/submit-an-idea-for-a-specification

11. Akronimet dhe shkurtesat

Tabela A: Akronimet dhe shkurtesat

Shtojca A - Klasifikimi i ashpërsisë së Erratumit

Kjo shtojcë përmbledh udhëzimet e klasifikimit të ashpërsisë për një gabim specifikimi. Kjo tabelë do t'i shtohet një rishikimi të ardhshëm të EPD, dhe më pas kjo pjesë do të fshihet.

Lexoni më shumë rreth këtij manuali dhe shkarkoni PDF:

Dokumenti i Procesit të Menaxhimit të Specifikimeve (SMPD) - PDF e optimizuar
Dokumenti i Procesit të Menaxhimit të Specifikimeve (SMPD) - PDF origjinal

Pyetje rreth manualit tuaj? Postoni në komente!

Referencat

Manuali i Përdoruesit