Dokument o procesu upravljanja specifikacij (SMPD)

Ta dokument, ne glede na naslov ali vsebino, ni specifikacija Bluetooth, za katero veljajo licence, ki jih podeljuje Bluetooth SIG Inc. (“Bluetooth SIG”) in njeni člani v skladu z licenčno pogodbo o patentu / avtorskih pravicah Bluetooth in licenčno pogodbo za blagovno znamko Bluetooth.

TA DOKUMENT JE NAVEDEN "KOT JE" IN BLUETOOTH ZIG, NJENI ČLANI IN NJIHOVI PRIDRUŽENI NE PREDSTAVIJO ALI JAMSTEV IN ODPOVEDJUJO VSE JAMSTVA, IZRAŽENE ALI ZAMISLJENE, VKLJUČNO VSAKO JAMSTVO MERCHANLO DA VSEBINA TEGA DOKUMENTA NI NAPAK.

BLUETOOTH SIG, NJENI ČLANI IN NJIHOVI PRIDOBLJENI V ZVEZI Z ZAKONOM NE PREPOVEDUJEJO VSE ODGOVORNOSTI, KI IZHAJA IZ TEGA DOKUMENTA ALI V VEZI Z NJIMI VSEBENE INFORMACIJE V TEM DOKUMENTU, VKLJUČUJO ZGODBO, PRIHODEK, LOG PREKINITEV ALI POSEBNIH, POSREDNIH, POSLEDIČNIH, NAKLJUČNIH IN KAZNIVIH ŠKOD, KAKRŠNEGA VZROKOV IN NE GLEDE NA TEORIJO ODGOVORNOSTI, ČE TUDI BLUETOOTH VZPIS, SO ČLANI ALI NJIHOVI PRIDOBITELJI ADVISIVIZIRALI ADVISIVES.

Ta dokument je lastnik Bluetooth SIG. Ta dokument lahko vsebuje ali zajema vsebino, ki je intelektualna lastnina Bluetooth SIG in njegovih članov. Predložitev tega dokumenta ne daje nobene licence nobeni intelektualni lastnini Bluetooth SIG ali njegovih članov.

Ta dokument se lahko spremeni brez predhodnega obvestila.

1. Uvod

Procesni dokument upravljanja specifikacij (SMPD) opisuje procese, ki jih avtorji specifikacije in reviewmorajo slediti razvoju novih specifikacij in izboljšanju obstoječih specifikacij (tj. dodati ali odstraniti funkcionalnost ali spremeniti specifično funkcionalnost v sprejeti specifikaciji), ohraniti sprejete specifikacije in upravljati konec življenjske dobe sprejetih specifikacij. Poleg tega ta dokument opisuje postopek za ustvarjanje, reviewing in odobritev belih knjig.

V procesu razvoja specifikacij obstajajo razlike med razvojem novih specifikacij in izboljšanjem obstoječih specifikacij zaradi neločljivih razlik v obsegu teh nalog; te razlike so poudarjene v tem dokumentu.

Postopek razvoja specifikacije vključuje:

Faza zahtev (opisana v oddelku 3) za določitev funkcionalnih zahtev
Razvojna faza (opisana v 4. razdelku) za razvoj in prenovoview specifikacije

Faza validacije (opisana v oddelku 5) za potrditev specifikacij s preskušanjem interoperabilnega prototipa (IOP)
Faza sprejetja / odobritve (opisana v oddelku 6) za predstavitev specifikacij odboru direktorjev Bluetooth SIG (BoD) v sprejetje / odobritev

Dokument Specification Errata Process (EPD) [3] opisuje postopek za predlaganje in reviewugotavljanje napak v specifikaciji in njihovo odobritev kot popravke napak (kot je opredeljeno v Statutu [2]) sprejetih specifikacij. Če ni drugače navedeno, vse sklicevanja na napake v tem SMPD pomenijo napake v specifikaciji.

1.1 Prednost

Podzakonski akti Bluetooth SIG, Inc. (podzakonski akti) in pogodbe o članstvu [2] imajo prednost pred kakršno koli nasprotujočo si vsebino v teh dokumentih in SMPD. Ne glede na kar koli v tem dokumentu, ima BoD zadnjo diskrecijsko pravico in pooblastilo za ukrepanje in sprejemanje odločitev, tudi če ti ukrepi in odločitve ne sledijo ali so v nasprotju s čimer koli v tem dokumentu in nič v tem dokumentu ne omejuje ali omejuje neodvisnega organa BoD in diskretnost.

Če pride do navzkrižja med besedilom v SMPD in slikami, ima besedilo prednost.

1.2 Referenčne skupine in odbori

V tem dokumentu so navedene naslednje vrste skupin: študijske skupine (SG), strokovne skupine (EG) in delovne skupine (WG). Delovna skupina ima lahko tudi podskupino, ki poroča delovni skupini. Podobno so v tem dokumentu navedene naslednje vrste odborov: Bluetooth Architectural Review Board (BARB), Bluetooth Test and Interoperability (BTI) in Bluetooth Qualification Review Plošča (BQRB). Ta dokument se nanaša tudi na tehnično osebje za Bluetooth SIG (BSTS) in OD.

1.3 Odbor reviews in odobritve

Komisija review je soview ki ga vodijo člani odbora (običajno 3 člani), da zagotovijo povratne informacije v določenem času (običajno 2-3 tedne), vendarview čas se lahko razlikuje glede na dolžino in zapletenost gradiva ter druge prednostne naloge v odboru. Skupina, ki zahteva review in odbor, ki vodi review vsak se dogovori o trajanju review. Člani skupine in odbora uporabljajo orodja Bluetooth SIG za obveščanje in beleženje začetka in konca review. Skupina običajno obdela povratne informacije odbora, ko jih prejme. Ko je odbor review poteče, skupina dokonča obravnavo povratnih informacij odbora in mora upoštevati tudi morebitne pozne prihodeview povratne informacije ob upoštevanju, da bo gradivo lahko naknadno odobrila komisija.

Odobritev odbora se pridobi z glasovanjem članov odbora v skladu z dokumentom delovne skupine [4].

1.4 Obvestila članom in dostopnost gradiva

Vsa obvestila, poslana članom v skladu s tem dokumentom, se lahko pošljejo po elektronski pošti, na primer občasno tehnično posodobitev. Obvestila, ki jih je treba poslati vsem članom, bodo poslana vsem aktivnim članom (tj. Če članstvo ni bilo začasno ustavljeno, prekinjeno ali umaknjeno). Ko bodo obvestila poslana po e-pošti, bodo poslana na zadnji znani e-poštni naslov (kot je razvidno iz takrat veljavnih evidenc Bluetooth SIG) vsakega posameznika, ki se je registriral pod članskim računom družbe članice in ni onemogočil prejemanja e-poštnih obvestil. Nič v tem dokumentu ne spreminja obveznosti ali zahtev Bluetooth SIG v zvezi z zagotavljanjem obvestil po statutu ali katerem koli drugem dogovoru med Bluetooth SIG in katerim koli članom.

Kjerkoli se ta dokument nanaša na a webspletno mesto, ki je dostopno vsem članom, se nanaša na dostopnost posameznikom, ki imajo aktiven račun Bluetooth SIG. Člani, ki nimajo aktivnega računa, lahko ustvarijo račun prek Bluetooth SIG webmesto.

1.5 Predloge

Za vsako vrsto dokumenta (npr. specifikacije, bele knjige, testni dokumenti), omenjeno v tem SMPD, Bluetooth SIG ponuja predlogo. Predlogo je treba uporabiti kot osnovo za vsak dokument, izdelan v skladu s tem SMPD. Če ne uporabite pravilne predloge, lahko dokument ne bo odobren. Predloge so na voljo na Bluetooth SIG webspletno mesto [8].

1.6 Vrste specifikacij

Obstaja več vrst specifikacij Bluetooth SIG. Hierarhično so vse specifikacije odvisne od specifikacije jedra Bluetooth. Specifikacije, kot so tradicionalni profiles; tradicionalni protokoli; in profiles, storitve, ki temeljijo na GATT, in protokoli, ki temeljijo na GATT, so vsi odvisni od funkcij v osnovni specifikaciji. Druge specifikacije, kot so specifikacije modela Mesh, so odvisne od Mesh Profile specifikacijo, ki je odvisna od osnovne specifikacije.

Specifikacija Core Specification Supplement (CSS) opredeljuje vrste podatkov, formate podatkov in običajne profile in kode napak storitev, ki jih uporabljajo osnovna specifikacija in druge specifikacije in sama ne opredeljuje nobenega vedenja.

Specifikacija GATT Specification Supplement (GSS) opredeljuje oblike karakteristik in deskriptorjev, ki jih uporablja Profiles in storitve ter sam ne opredeljuje nobenega vedenja.
Specifikacija Mesh Device Properties (MDP) opredeljuje lastnosti mreže, ki jih uporablja Mesh Profile in specifikacije modela mreže in sam ne opredeljuje nobenega vedenja.

2. Končanoview

Ta razdelek ponuja overview procesov in ni namenjen vključevanju vseh podrobnosti.

Slika 2.1 prikazuje šest glavnih faz, ki sestavljajo postopek upravljanja specifikacij.

Prve štiri faze se pojavijo med postopkom razvoja specifikacij in so sestavljene iz faze zahtev (oddelek 3), faze razvoja (odsek 4), faze validacije (odsek 5) in faze sprejetja / odobritve (oddelek 6). Nato sledita dve fazi po sprejetju: faza vzdrževanja specifikacije (oddelek 7) in faza izteka življenjske dobe specifikacije (oddelek 8).

Slika 2.2 prikazuje podrobnosti štirih faz v procesu razvoja specifikacij. Siva polja označujejo glavne rezultate za vsako fazo. Oranžna polja povzemajo mejnike procesa.

V fazi zahtev (opisano v oddelku 3) predlog za začetek novega dela (New Work Proposal (NWP)) sproži postopek razvoja specifikacije z opredelitvijo uporabniških scenarijev, ki jih je treba omogočiti, če novo delo nadaljuje. Če je NWP odobren, dodeljena skupina ustvari dokument s funkcionalnimi zahtevami (FRD). Ko je FRD odobren in dodeljen skupini, se začne razvojna faza.

Med razvojno fazo (opisano v razdelku 4) razvoj specifikacije napreduje skozi zaporedje stages (0.5/DIPD do 0.9/CR), ki doseže vrhunec s popolnim osnutkom specifikacije. Specifikacija 0.9/CR je na voljo vsem članom, nato pa se predloži Upravnemu odboru, ki obravnava specifikacijo v odobritev. Po odobritvi se začne faza validacije.

Med fazo potrjevanja razvoja specifikacije (opisano v razdelku 5) je specifikacija 0.9/CR, ki jo je odobril OD, na voljo vsem članom, da ponovnoview in potrdi, ter član Review se začne. Validacija se izvede s testiranjem interoperabilnosti (IOP) med prototipi, ki jih izdelajo člani. Ko je testiranje IOP končano (če je zahtevano za specifikacijo) in BARB odobri poročilo o preskusu IOP, se začne faza sprejetja/odobritve.

Med fazo sprejetja / odobritve (opisano v oddelku 6) se dokončajo specifikacije in z njimi povezani preskusni dokumenti; Prejeta so dovoljenja BARB, BQRB in BTI; in končni paket specifikacij se predloži upravnemu odboru, ki obravnava specifikacijo za sprejem (tj. končno odobritev).

Specifikacija se bo morda morala vrniti na prejšnjo fazo ali stage če pride do bistvenih sprememb. V nekaterih primerih je mogoče tudi opustiti del faze, kot je opisano v razdelku 4.4.

Faza vzdrževanja specifikacije (opisana v oddelku 7) se začne po sprejetju specifikacije v upravnem odboru. V tej fazi se poročajo in ocenijo morebitne napake, ki jih najdemo v sprejeti specifikaciji, in (če je potrebno) se v specifikacijo naredijo popravki napak. Faza vzdrževanja specifikacije se nadaljuje, dokler specifikacija ne zastare ali umakne (glejte fazo izteka življenjske dobe specifikacije v naslednjem odstavku).

Faza izteka življenjske dobe specifikacije (opisana v oddelku 8) opisuje postopek za razveljavitev in umik sprejetih specifikacij.

3. Faza zahtev

Faza zahtev se začne bodisi z NWP (ki navaja željo po začetku dela na enem ali več uporabniških scenarijih) bodisi po ugotovitvi, da je želeno novo delo že zajeto v njihovi listini delovne skupine. Če želi delovna skupina začeti novo delo, za katero meni, da že spada v okvir njene listine, mora delovna skupina slediti postopku, opredeljenemu v oddelku 3.1, da začne neposredno razvijati FRD. Za vse druge delovne postavke mora delovna skupina slediti postopku, opredeljenemu v oddelku 3.2. FRD opredeljuje obseg funkcionalnih zahtev, ki se uporabljajo za izdelavo specifikacij v fazi razvoja. Faza zahtev je prikazana na sliki 3.1.

3.1 Novo delo, zajeto v listini delovne skupine

Ko delovna skupina želi začeti novo delo in utemeljeno verjame, da funkcionalnost, ki jo želi dodati, že spada v področje njene listine, lahko delovna skupina začne z delom na FRD, pod pogojem, da takoj obvesti BARB. Delovna skupina bo v obvestilo BARB vključila opis predlaganega novega dela in kopijo listine delovne skupine z označenim jezikom, ki jim dovoljuje začetek novega dela.

Če BARB zavrne analizo delovne skupine, mora delovna skupina ustaviti delo na FRD in nadaljevati postopek NWP, opisan v oddelku 3.2. Če BARB odobri analizo delovne skupine, bo delovna skupina nemudoma obvestila BSTS (po e-pošti na specification.manager@bluetooth.com) in BSTS bo točko dodal na naslednji dnevni red uprave.

Delovna skupina bo v svoje obvestilo BSTS vključila enake informacije, kot jih je posredovala BARB. Če BoD zavrne analizo delovne skupine, mora delovna skupina ustaviti delo na FRD in nadaljevati postopek NWP, opisan v oddelku 3.2. Če bo odbor odobril analizo delovne skupine, bo morda nadaljeval z delom na FRD, kot je opisano v oddelku 3.3.

3.2 Nov predlog dela (NWP)

Vsak član, delovna skupina, SG ali EG lahko ustvari in predloži NWP (prek Bluetooth SIG webstran [10]). NWP mora vključevati vsaj informacije o naslednjem z uporabo uradne predloge iz [8]:

Uporabniški scenariji
Zavezanost članov razvoju FRD in na katerem(ih) področju(-ih) (npr. avtor, avtor, Reviewhja, prototipiranje)

Predlagano vodstvo dela FRD
Predlagana skupinska naloga za delo FRD
E-poštni naslov glavnega avtorja

Opomba: Navodila za postopek NWP so na voljo na Bluetooth SIG webspletno mesto [10].

BSTS bo med razvojem NWP opravljal naslednje naloge:

Avtorjem pošljite potrdilo o prejemu (običajno v sedmih koledarskih dneh od prejema) in opišite naslednje korake.

Po potrebi sodelujte z avtorji, da bo NWP jasen in popoln. To lahko zahteva več ponovitev NWP.
Če NWP vsebuje izjave o napakah v sprejetih specifikacijah Bluetooth, sodelujte z avtorjem(-i) do file vnosi v sistem napak.
Če opazite, da NWP lahko podvaja delo, ki že poteka ali je že končano, obvestite avtorje drugega dela za njihovo oceno.

Objavite NWP v NWP webstran dostopna vsem članom.
Obvestite vse člane, da je NWP na voljo za ponovnoview in ali je potrebna dodatna zaveza članic za razvoj FRD.

Člani se lahko obrnejo na avtorja (avtorje), da mu zastavijo vprašanja ali dajo povratne informacije v zvezi z NWP.

Vsaj tri družbe članice se morajo zavezati, da bodo sodelovale pri dokončanju nastale FRD, da NWP postane kandidat za odobritev uprave, najmanj eno podjetje pa mora biti pridruženi član ali predlagatelj. Po odobritvi upravnega odbora za NWP bo upravni odbor dodelil obstoječi podskupini delovnih skupin ali skupnemu delovnemu odboru, ki bo deloval na FRD (opisano v oddelku 3.3). Če ustrezna podskupina delovne skupine ali SG ne obstaja, se lahko ustvari ena.

Za NWP, ki imajo zadostno zavezanost članom, bo BSTS izvedel naslednje dodatne naloge:

Vsaj 13 dni pred predlagano odobritvijo NWP s strani upravnega odbora obvestite BARB in skupino, ki ji je NWP priporočljiva za dodelitev, o odobritvi NWP v teku. To se naredi, da se zagotovi priložnost za povratne informacije na področjih, kot je predlagana skupina, ali NWP že pokriva obstoječe delo itd.

Izpolnjeni NWP predložite upravnemu odboru.

Če NWP predložijo člani, ki niso povezani s skupino, poskrbite, da bo eden od članov NWP predstavil upravnemu odboru.
Če NWP predloži skupina, poskrbite, da predsednik skupine NWP predstavi upravnemu odboru.

Povabite predsednika BARB in predsednike skupine, ki jim je priporočljiva NWP, na sejo upravnega odbora.
Če nadzorni svet odobri in dodeli NWP, obvestite skupino, ki ji je bila dodeljena; avtor (-ji); člani, ki so v NWP opredeljeni kot zavezani k razvoju ustrezne FRD; in če NWP predlaga skupina, skupina rezultatov in naslednji koraki.

Ko NWP odobri Upravni odbor, posodobite stanje na NWP webmesto.

Upravni odbor lahko po lastni presoji zavrne kateri koli NWP, nprample, če je delo že v celoti končano, zaradi omejitev virov delo izven obsega veljavnih dokumentov Bluetooth SIG (npr. aplikacijskega programskega vmesnika (API)) [2] ali če bi bilo treba predlagano delo filed kot napaka. Če je NWP zavrnjen, bo BSTS obvestil avtorja(-e), člane, ki so v NWP opredeljeni kot zavezanci za razvoj ustreznega FRD, in, če NWP predlaga skupina, skupino. Obvestilo bo vsebovalo vse razloge za zavrnitev. Avtor(i), predani člani ali skupina lahko zahtevajo čas na dnevnem redu Upravnega odbora za pritožbo na zavrnitev.

Če želi član ali skupina predlagati odstranitev funkcije iz sprejete specifikacije, mora skupina ali član pripraviti NWP. NWP mora vključevati analizo vpliva, ki ga bo imela odstranitev na povratno združljivost in interoperabilnost, vključno z analizo vpliva na testne primere.

NWP niso potrebni za izboljšave specifikacij CSS, GSS ali MDP: običajno posodobitve specifikacij CSS, GSS ali MDP izvirajo iz posodobitev drugih specifikacij, ki imajo lastne NWP.

3.3 Dokument o funkcionalnih zahtevah (FRD)

FRD definirajo funkcionalne zahteve za omogočanje uporabniških scenarijev. FRD mora vključevati vsaj informacije o naslednjem z uporabo uradne predloge iz [8]:

Uporabniški scenariji
Funkcionalne zahteve na podlagi uporabniških scenarijev

Zaveza članov za razvoj nastalih specifikacij
Izbirna podpora prototipa članov za predvidene vloge
Priporočena delovna skupina za razvoj nastalih specifikacij

Razvoj FRD

FRD ustvarjajo dodeljene podskupine delovne skupine ali člani SG z včlanjenimi člani s pomočjo uredniške podpore BSTS. Vsak član, ki ga zanima sodelovanje v razvoju FRD, se lahko pridruži skupini.

FRD morajo navesti zavezo vsaj dveh (čeprav se spodbujajo trije) pridruženih podjetij ali družb članic na ravni promotorjev, da bodo sodelovale pri razvoju nastale specifikacije. Delovne skupine ali GS, ki predložijo FRD, bi morale poskušati doseči široko podporo družb članic skupine, ki predstavljajo predvideni ciljni segment industrije, opredeljen v FRD.

Nova funkcionalnost, ki je predlagana v FRD, bi morala biti podprta na čim več transportih in obstoječih napravah. To vključuje nprample, ki podpira GATT profiles in storitve tako pri prenosu osnovne hitrosti/razširjene hitrosti prenosa podatkov (BR/EDR) kot pri prenosu z nizko porabo energije (LE) Bluetooth. Če nova funkcionalnost nima zadostne članske podpore za transport, nprampker je zaradi pomanjkanja zavezanosti članov k opredelitvi uporabe transporta ali potencialno nezadostnega števila testnih platform IOP za eno ali več vlog, je podpora za ta transport lahko izključena iz FRD.

Če ni drugače utemeljeno, nova funkcionalnost, profiles, storitve pa morajo biti skladne z zahtevami glede združljivosti za nazaj, opisanimi v razdelku 3.3.2.

Delovna skupina ali SG mora FRD predložiti BARB za ponovnoview in odobritev. BARB mora odobriti ali zavrniti FRD na podlagi svoje inženirske presoje. Če ga odobri BARB, bo FRD na voljo vsem članom, obvestilo o njegovi razpoložljivosti pa bo izdal BSTS.

FRD niso potrebni za izboljšave specifikacij CSS, GSS ali MDP: običajno posodobitve specifikacij CSS, GSS ali MDP izvirajo iz posodobitev drugih specifikacij, ki imajo svoje FRD.

Zahteve glede združljivosti za nazaj

Združljivost za nazaj za BR / EDR

Za delovanje BR / EDR je zahteva glede združljivosti za nazaj opredeljena kot interoperabilnost z delom BR / EDR specifikacije Bluetooth Core v1.1 in novejših.

Združljivost za Bluetooth z nizko porabo energije

Za delovanje LE je zahteva glede združljivosti za nazaj opredeljena kot interoperabilnost z delom LE specifikacije Bluetooth Core v4.0 in novejšim.

Združljivost za nazaj za specifikacije, ki niso Core Specification

Za specifikacije, ki niso osnovne specifikacije Bluetooth, je treba ohraniti združljivost dane različice za nazaj z vsemi prejšnjimi različicami, ki imajo enako glavno številko različice. Za nprample, različica 1.3 mora biti združljiva z različicami 1.2, 1.1 in 1.0, vendar različica 2.0 morda ne bo združljiva z različicami 1.0, 1.1, 1.2 in 1.3. Upoštevajte, da povečanje glavne številke različice osnovne specifikacije ne pomeni pomanjkanja združljivosti za nazaj s prejšnjimi različicami.

Izvzetje iz zahtev glede združljivosti za nazaj

Delovna skupina ali SG lahko predlagata izvzetje posebne funkcionalnosti iz zahteve glede združljivosti z nazaj, če je to utemeljeno. Za nprample, če se izkaže, da ima funkcionalnost nizko stopnjo uvajanja na trg ali je zaradi težav z interoperabilnostjo bolje odstraniti ali zamenjati funkcionalnost kot pa spremeniti funkcionalnost. WG ali SG mora v FRD vključiti vse izjeme glede združljivosti z nazaj, ki jih odobri BARB po odobritvi FRD. Vse izjeme, ki jih je odobril BARB, bodo predložene upravnemu odboru v odobritev na 0.9/CR Stage.

3.4 Listina delovne skupine

Ko BARB odobri FRD, za katerega se predlaga, da se dodeli obstoječi WG, mora ta WG pripraviti osnutek posodobitve svoje listine, da doda novo funkcionalnost v obseg (razen če je upravni odbor predhodno odobril analizo WG, da je posodobitev listine WG ni zahtevano). Ko pa BARB odobri FRD, ki je predlagan za novo delovno skupino, morajo BARB in člani, ki jih zanima razvoj funkcionalnosti, opisane v FRD, pripraviti osnutek listine za novo delovno skupino z novo funkcionalnostjo, vključeno v obseg listine. .

Ko je nova ali posodobljena listina delovne skupine pripravljena, jo je treba predložiti BARB-ju v popravekview in odobritev. Ko BARB odobri listino, bo osnutek nove ali posodobljene listine delovne skupine predložen upravnemu odboru v potrditev.

Ko BoD odobri listino, mora delovna skupina, ki ji je bila naloga za razvoj specifikacij dodeljena, tesno sodelovati s skupino, ki je pripravila FRD, če bodo potrebne morebitne posodobitve ali pojasnila te direktive. Če je med razvojno fazo potrebna posodobitev FRD, je treba upoštevati postopke, opisane v oddelku 3.3 in tem oddelku; razvoj specifikacij pa lahko poteka vzporedno s posodobitvami listin FRD in WG.

3.5 Zahteve Zahteve za izhod iz faze

Faza zahtev je končana, razvojna faza pa se začne, ko potrdilo ali odobritev listine delovne skupine s potrebnim obsegom za FRD potrdi ali odobri naslednje zahteve:

ND je bodisi odobril uprava bodisi se je strinjal, da NWP ni potreben.

FRD in ustrezna listina delovne skupine je odobril BARB.

4. Razvojna faza

V fazi razvoja dodeljene delovne skupine ustvarijo novo specifikacijo in / ali izboljšajo obstoječo specifikacijo. FRD opredeljuje zahteve nove ali izboljšane specifikacije Bluetooth. V specifikaciji ni dovoljena nobena funkcionalnost, ki ni razumno povezana z zahtevami v FRD. Cilj je ustvariti specifikacijo 0.9 / CR, ki je pripravljena za fazo validacije (opisana v poglavju 5) ob zaključku faze razvoja.
Med razvojno fazo specifikacija (ali izboljšava specifikacije) napreduje skozi tri sekundetages.

Za novo specifikacijo so trije stages so:

0.5 Stage
0.7 Stage

0.9 Stage

Za izboljšavo specifikacije so trije stages so:

Osnutek dokumenta predloga izboljšav (DIPD) Stage

Dokument o končnem predlogu izboljšave (FIPD) Stage
Zahteva za spremembo (CR) Stage

Vsak stage je podrobneje opisan v naslednjih pododdelkih. Slika 4.1 spodaj prikazuje različne dokumente, ki jih bo delovna skupina pripravila ob vsakem stage.

Slika 4.1: Konecview specifikacije stagki se pojavijo v fazi razvoja

Vloga urada BARB v celotnem postopku razvoja specifikacij je svetovanje in tehnično pomoč delovnim skupinam. Delovne skupine lahko kadar koli zaprosijo BARB za tehnični nasvet v zvezi z razvojem specifikacij in arhitekturnimi koncepti, ki se uporabljajo v specifikaciji. Delovne skupine se zlasti spodbuja, da od BARB zahtevajo zgodnje povratne informacije za funkcije, ki imajo kompleksnejše arhitekturne vidike.

4.1 0.5/DIPD Stage

Med 0.5/DIPD Stage, bo delovna skupina razvila naslednje z uporabo uradnih predlog iz [8]:

Za novo specifikacijo osnutek specifikacije 0.5, ki mora vsebovati vsaj informacije o naslednjem:

Arhitektura za kritje zahtev, kot je navedeno v FRD

Za protokole so določene dostopne točke za storitve
Za storitve, izpostavljeni podatki in vedenje
Za profiles, identificirani protokoli in določena funkcionalnost

2. Za izboljšanje specifikacij osnutek DIPD, ki mora vsebovati vsaj informacije o naslednjem:

Ozadje: Obseg dela, cilji, ki vodijo delo, in kako se ta posebni predlog prilega obsegu
konecview predloga: Povzetek razširjene funkcionalnosti (dodana prilagodljivost, izboljšana zmogljivost itd.), Ki jo ponuja DIPD, vključno z jasnim opisom, kako se nova funkcionalnost prilega trenutni različici specifikacije. Če je delovna skupina ocenila več predlogov, je treba te predloge vključiti, da se BARB omogoči, da ugotovi, ali je bila pri izbiri najprimernejšega predloga opravljena zadostna skrbnost.

Zajetje zahtev: Povzetek pokritosti funkcionalnih zahtev, podanih v predlogu, s sklicevanjem na ustrezne sistemske zahteve in scenarije uporabe, podane v povezani FRD
Opredelitev težave: Izjava o težavah, ki jih rešujejo predlogi
Merila za izbor: Izjava v zvezi z merili za izbiro / izvedbo iz povezanih meril ocenjevanja, ki so vodile izbirni postopek

Utemeljitev izbire: Pregled meritev vrednotenja, ki upravičujejo izbiro med predlogi in razkrivajo kompromise
Opis: Opis funkcionalnosti in razširjenih protokolov. Ta razdelek se lahko prilagodi različnim potrebam z dodajanjem ustreznih pododdelkov.

3. Testna strategija: Opis funkcionalnosti, ki naj bi bila preizkušena (ali ni bila preizkušena) kot del kvalifikacijskega programa Bluetooth in kako je predlagana preizkušanja funkcionalnosti (npr. pričakovanja glede nižjega(-ih) ali zgornjega(-ih) preizkuševalcev in če bodo preskusi pripisani kot preskusi skladnosti ali interoperabilnosti ali kombinacija obeh). To je lahko v ločenem dokumentu ali ločenem razdelku znotraj specifikacije 0.5/DIPD. Konvencije, ki se uporabljajo v testni strategiji, so opisane v Testni strategiji in terminologijiview dokument (TSTO) [5].

Primarno občinstvo dokumentov na tem stage so člani delovne skupine in BARB, ki review arhitekturne predloge in pokritost zahtev ter ZTI, ki reviews Testna strategija. V večini primerov so dokumenti pri tem stage ne smejo vsebovati besedila, ki je načrtovano za vključitev v končno specifikacijo.

BSTS mora ponovnoview vse dokumente za skladnost s smernicami za pripravo besedila Bluetooth [1] in opredelitev težav, ki jih mora obravnavati delovna skupina. BARB mora ponovnoview specifikacijo 0.5/DIPD. Za izboljšavo specifikacije mora BARB tudi review DIPD za skladnost z zahtevami glede združljivosti z nazaj, opisanimi v razdelku 3.3.2. ZTI mora ponovnoview testna strategija.

BARB mora bodisi odobriti ali zavrniti specifikacijo 0.5/DIPD na podlagi svoje inženirske presoje. Če ga odobri BARB, bo specifikacija 0.5/DIPD na voljo na Bluetooth SIG webstran vsem pridruženim in promotorskim članom, obvestilo o njeni razpoložljivosti pa bo izdal BSTS. Pri 0.5/DIPD Stage, odobritev testne strategije ni potrebna.
0.5/DIPD Stage ni potreben za izboljšave specifikacij CSS, GSS ali MDP

0.5/DIPD Stage zahteve za izstop

0.5/DIPD Stage je popoln in 0.7/FIPD Stage se začne, ko so izpolnjene naslednje zahteve za izstop:

BSTS je zaključil reviews specifikacijo 0.5/DIPD in testno strategijo.

BARB je odobril specifikacijo 0.5 / DIPD.
ZTI je zaključil svojo review testne strategije.
BSTS je odobril specifikacijo 0.5 / DIPD na voljo vsem pridruženim članom in promotorjem.

4.2 0.7/FIPD Stage

Med 0.7/FIPD Stage, bo delovna skupina razvila naslednje z uporabo uradnih predlog iz [8]:

Za novo specifikacijo osnutek specifikacije 0.7, ki mora vsebovati vsaj informacije o naslednjem:

Opis vseh sprememb, ki so bile narejene od 0.5, ki ga je odobril BARB, vključno z novimi ali spremenjenimi predlogi, merili za izbor in utemeljitvijo izbire. Spremembe morajo biti opisane na isti ravni podrobnosti, kot je zahtevano v 0.5 Stage.

Obravnavane vse funkcionalne zahteve FRD.

2. Za izboljšanje specifikacij osnutek FIPD, ki mora vsebovati vsaj informacije o naslednjem:

Opis vseh sprememb, ki so bile narejene po DIPD, ki ga je odobril BARB, vključno z novimi ali spremenjenimi predlogi, merili za izbor in utemeljitvijo izbire. Spremembe morajo biti opisane na isti ravni podrobnosti, kot je zahtevano v DIPD Stage.

Po potrebi nadaljnja razvita področja, ki so bila v zvezi z DIPD opisana v oddelku 4.1.
Izpolnjen opis izboljšave.
Posodobljen arhitekturni opis.
Obravnavane vse funkcionalne zahteve FRD.

3. 0.7 / FIPD testni dokumenti, ki morajo vsebovati vsaj informacije o naslednjem:

Testna zbirka, sestavljena iz seznama testnih namenov, kot je opisano v TSTO [5].
Izjava o skladnosti izvajanja (ICS), kot je opisano v TSTO [5].

Za izboljšave specifikacij lahko Test Suite in ICS dobite v obliki ločenih dokumentov ali kot dodatna poglavja v FIPD.

Primarno občinstvo dokumentov, izdelanih na tem stage so člani delovne skupine in BARB, ki review popoln opis funkcije ali izboljšave, vključno z nekaterim besedilom, načrtovanim za vključitev v končno specifikacijo. ZTI je občinstvo za review testnih dokumentov.

BSTS bo ponovnoview nove ali spremenjene dele specifikacije 0.7/FIPD in testne dokumente za skladnost s smernicami za pripravo besedila Bluetooth, vključno z jezikovnimi konvencijami, ki jih je določil Bluetooth SIG. BARB bo ponovnoview specifikacijo 0.7/FIPD.

BSTS bo delovni skupini pomagal pri pripravi preskusnih dokumentov 0.7 / FIPD v skladu s TSTO [5].

ZTI mora ponovnoview testne dokumente 0.7/FIPD. Delovna skupina mora ZTI posredovati specifikacijo 0.7/FIPD kot referenco, kadar review0.7/FIPD testnih dokumentov, ki jih bo ZTI ponovnoview v skladu s specifikacijo ZTI Review Kontrolni seznam postopka [6].

Potem ko je BARB dokončal svojo review specifikacije 0.7/FIPD in ZTI je dokončal svojo review testnih dokumentov 0.7/FIPD bo BSTS naredil reviewed 0.7/FIPD specifikacija, ki je na voljo vsem pridruženim in promotorskim članom.

0.7/FIPD Stage ni potreben za izboljšave specifikacij CSS, GSS ali MDP.

0.7/FIPD Stage zahteve za izstop

0.7/FIPD Stage je popoln in 0.9/CR Stage se začne, ko so izpolnjene naslednje zahteve za izstop:

BSTS je zaključil reviewspecifikacije 0.7/FIPD in testnih dokumentov.
BARB je zaključil reviewv skladu s specifikacijo 0.7/FIPD.
ZTI je zaključil reviewnabor testov 0.7/FIPD (Nameni testov) in 0.7/FIPD ICS.
BSTS je naredil ponovnoviewed 0.7/FIPD specifikacija, ki je na voljo vsem pridruženim in promotorskim članom.

4.3 0.9/CR Stage

Obstajata dve vrsti CR-jev: integrirani CR, ki je dokument s spremljanjem sprememb celotne sprejete specifikacije, ki prikazuje vse spremembe od prejšnje različice, in Skrajšani CR, ki vsebuje navodila za spreminjanje samo prizadetih delov različico specifikacije, na kateri temelji CR.

Med 0.9/CR Stage, bo delovna skupina razvila naslednje z uporabo uradnih predlog iz [8]:

Za novo specifikacijo osnutek vsebine 0.9 specifikacije, ki mora vsebovati vsaj informacije o naslednjem:

Opis vseh sprememb, ki so bile narejene od BARB-reviewed specifikacija 0.7 (ali od specifikacije 0.5, če je bila izdelava specifikacije 0.7 opuščena), vključno z novimi oz.
spremenjeni predlogi, merila za izbor in utemeljitev izbire. Spremembe morajo biti opisane na isti ravni podrobnosti, kot je zahtevano v 0.5 Stage in 0.7 Stage.

2. Za izboljšanje specifikacije:

Bodisi integrirani CR, ki mora vsebovati vsaj informacije o naslednjem:
Opis vseh sprememb, ki so bile narejene od BARB-reviewed FIPD (ali od DIPD, če je bil FIPD opuščen), vključno z novimi ali spremenjenimi predlogi, merili za izbor in utemeljitvijo izbire. Spremembe morajo biti opisane na isti ravni podrobnosti, kot je zahtevano v DIPD Stage in FIPD Stage.
Vse predlagane spremembe predhodno sprejete specifikacije z uporabo sledenja spremembam.
Vse odobrene tehnične napake (pri čemer je vsaka napaka navedena s številko napake), prikazane s sledenjem spremembam, ki jih še ni treba vključiti v predhodno sprejeto različico specifikacije, in besedilo o vplivu, povezano z izboljšanjem specifikacije; ali ki drugače vplivajo na testiranje IOP.

3. Ali okrajšani CR, ki mora vsebovati vsaj informacije o naslednjem:

Opis vseh sprememb, ki so bile narejene od BARB-reviewed FIPD (ali od DIPD, če je bil FIPD opuščen), vključno z novimi ali spremenjenimi predlogi, merili za izbor in utemeljitvijo izbire. Spremembe morajo biti opisane na isti ravni podrobnosti, kot je zahtevano v DIPD Stage in FIPD Stage.
Vse spremembe, predlagane za posamezni odsek in odstavek specifikacije, ki jih CR predlaga spremeniti.
Vse odobrene tehnične napake (pri čemer je vsaka napaka navedena s številko napake), prikazane z oznakami, ki še niso vključene v predhodno sprejeto različico specifikacije, in besedilo o vplivu, povezano z izboljšanjem specifikacije; ali ki drugače vplivajo na testiranje IOP.

4. CSS CR (če specifikacija zahteva nove vnose), ki je lahko vdelan v okrajšani CR specifikacije.
5. GSS CR (če specifikacija zahteva nove vnose), ki je lahko vdelan v okrajšani CR specifikacije.
6. MDP CR (če specifikacija zahteva nove vnose), ki je lahko vdelan v okrajšani CR specifikacije.
7. Testni dokumenti 0.9 / CR, ki morajo vključevati vsaj informacije o naslednjem z uporabo uradne predloge iz [8]:

Testni paket 0.9 / CR, ki vključuje vsebinsko popolne testne primere in s tem povezano tabelo preskusnih primerov (TCMT), kot je opisano v TSTO [5].
0.9 / CR ICS, kot je opisano v TSTO [5].
Če konfiguriranje testov zahteva posebne parametre za izvedbo pod preskusom (IUT), informacije o preizkušanju 0.9 / CR za preizkušanje (IXIT).
Referenčni seznam preskusnih primerov 0.9 / CR (TCRL) (neobvezno za posodobitve osnovnih specifikacij).

8. Analiza testne pokritosti, ki navaja, katere zahteve za specifikacije so bodisi preizkušene bodisi niso preizkušene v okviru paketa 0.9 / CR Test Suite (za izboljšave specifikacij mora analiza testne pokritosti vključevati le novo dodano in vplivno funkcionalnost, ne pa tudi neobdelana področja originalna specifikacija).
9. Načrt preskusa IOP.

Za izboljšave specifikacij lahko Test Suite, ICS in IXIT dobite bodisi kot ločene dokumente bodisi kot dodatne oddelke v okrajšanem CR.

V večini primerov mora integrirani ali okrajšani CR temeljiti na predhodno sprejeti različici specifikacije, lahko pa tudi na zadnjem vmesnem osnutku. Številka najnovejše vmesne različice osnutka specifikacije mora biti številka različice, povezana z različico dokumenta, ki je zamrznjena in se s časom ne bo spremenila. Sicer pa dodatne identifikacijske informacije (kot sta datum dokumenta in a URL na stalno lokacijo), je treba zagotoviti, da se določi posebna „osnovna“ različica. Če se uporablja vmesni osnutek, je treba vključiti vse spremembe, ki niso neposredno povezane s CR v določenem odseku, ki ga CR spreminja, vendar jih ni treba prikazati z oznakami. Če se ustrezni deli vmesnega osnutka pozneje posodobijo, je treba CR posodobiti, da odraža posodobitve vmesnega osnutka.

Skrajšani material CR je v idealnem primeru vključen v osnutek celotne specifikacije oziroma v celotni testni dokument pred fazo validacije, lahko pa je vključen tudi na začetku faze validacije. Če se za specifikacijo razvija več funkcij (npr. Osnovna specifikacija), bo morda zaželeno, da se funkcije po zaključku testiranja IOP integrirajo v en osnutek.

BSTS bo ponovnoview specifikacijo 0.9/CR in testne dokumente za skladnost s smernicami za pripravo besedila Bluetooth. Potem bo BARB ponovnoview specifikacija 0.9/CR, ki ji kasneje sledi načrt preskusa IOP (kot je opisano v razdelku 4.3.1). Ko delovna skupina BARB predloži specifikacijo 0.9/CR za ponovnoview, bo BSTS vsem članom omogočil dostop do review in obvesti vse člane o njegovi razpoložljivosti. Od te točke naprej v procesu razvoja specifikacije bo BSTS dal osnutke specifikacije, predložene BARB-u, na voljo vsem članom z rednimi obvestili, poslanimi vsem članom.

Za izboljšanje specifikacij bo delovna skupina predsedstvu uprave priporočila, ali je treba prejšnje različice specifikacije opustiti ali umakniti, vključno s tehničnimi razlogi za priporočila.

BARB bo ponovnoview analiza delovne skupine o skladnosti specifikacije 0.9/CR z zahtevami, navedenimi v FRD, morebitnih varnostnih težavah, kakršnih koli zakonodajnih vprašanjih, skladnosti z arhitekturo Bluetooth in, za izboljšanje specifikacije, skladnosti z zahtevami glede združljivosti za nazaj, opisanimi v razdelku 3.3.2 .XNUMX. Če BARB ugotovi morebitne varnostne težave, bo BARB obvestil BSTS za ponovnoview in usklajevanje s strokovno skupino za varnost; in če BARB ugotovi kakršne koli regulativne posledice, bo BARB obvestil BSTS, da review in usklajuje se z regulativnim odborom in pravnim svetovalcem Bluetooth SIG. BARB mora bodisi odobriti ali zavrniti specifikacijo 0.9/CR na podlagi svoje inženirske presoje in upoštevanja dejavnikov, opisanih v tem odstavku.

ZTI bo ponovnoview testne dokumente 0.9/CR ob upoštevanju analize pokritosti s testom. ZTI mora odobriti ali zavrniti testne dokumente 0.9/CR.

Potem ko BARB odobri specifikacijo 0.9/CR, delovna skupina predloži načrt testiranja IOP BARB za ponovnoview.

Specifikacija 0.9 / CR, ki jo je odobrila BARB, se predloži upravnemu odboru, da odobri začetek preskušanja IOP in objavo specifikacije 0.9 / CR vsem članom.

Za poudarjanje morebitnih pravnih vprašanj lahko delovne skupine zahtevajo specifikacijo review s strani pravnega svetovalca Bluetooth SIG (pravna review) pred obveznim pravnim review poteka med fazo sprejetja/odobritve. Vendar pa za izboljšave specifikacij pravni review je treba opraviti na integriranem CR (v nasprotju s skrajšanim CR) in to je treba vnaprej načrtovati, kolikor je mogoče vnaprej, tako da so na voljo viri.

Načrt preskusa IOP

Delovna skupina bo razvila pisni načrt testiranja IOP, ki mora izpolnjevati vse spodaj opredeljene zahteve za uporabo med fazo potrjevanja na preskusnih dogodkih IOP. Delovne skupine morajo BARB predložiti načrt testiranja IOP za ponovnoview preden se začne(i) preskusni dogodek(i) IOP. Za preproste izboljšave specifikacij (zlasti tiste, ki ne zahtevajo spreminjanja ali dodajanja nobenih testnih primerov v Test Suite) testiranje IOP morda ne bo potrebno, delovna skupina pa lahko BARB predloži zahtevo za opustitev testiranja IOP z uporabo definiranega procesa v razdelku 4.4.

Načrt preskusa IOP mora vključevati:

Preizkusite primere, da preverite vse nove obvezne, neobvezne in pogojne funkcije
Vsaj en testni primer za vsako operacijsko kodo
Vsaj en testni primer za vsak parameter
Vsaj en testni primer za vsako vrsto paketa
Primeri preizkusov združljivosti za nazaj za izboljšave specifikacij, tako da so za vso izboljšano funkcionalnost izpolnjene zahteve iz oddelka 3.3.2 (glej tudi oddelek 4.3.1.1).
Preizkusite primere, ko je IUT izpostavljen vrednostim zunaj določenih obsegov ali vedenjskim vidikom, ki veljajo za neveljavne ali nepričakovane (primeri neveljavnega vedenja). Upoštevajte, da naj bi bil tester, kot je PTS ali drugo preskusno orodje, pobudnik kakršnega koli neveljavnega vedenja.
Vse začasno dodeljene številke (izbrane v sodelovanju z BSTS, da se prepreči prekrivanje na prihajajočih preskusnih dogodkih IOP), ki se uporabljajo na preskusnem dogodku IOP, kot je opisano v oddelku 4.3.1.2.
Identifikacija potrebnega števila neodvisnih izvedb, ki morajo prestati vsak testni primer, ob upoštevanju zahtev glede pokritosti, opisanih v oddelku 4.3.1.3
Opredelitev morebitnih testnih primerov v testnem paketu, za katere delovna skupina meni, da bi jih bilo treba izključiti, in utemeljitev njihove izključitve. Ti ponavadi vključujejo: • Preskusne primere za preverjanje prihodnosti (npr. Skupne teste, da se lahko upoštevajo morebitni prihodnji dodatki, kot so dodatne značilnosti, razširitvene značilnosti ali uporaba bitov ali polj, rezerviranih za prihodnjo uporabo (RFU)).
• Testni primeri, ki so podmnožica drugih vključenih testov
• Splošni testni primeri, ki so skoraj enaki preskusom, ki se izvajajo za več drugih specifikacij (npr. Sprožanje pogostih kod napak)
• Testni primeri z enakim testnim namenom kot testni primeri, ki potujejo čez drug prevoz (npr. BR / EDR testni primer, ki je podoben LE testnemu primeru)
• Robustnost ali testiranje izjemnih situacij pri izvedbi

Načrt preskusa IOP lahko vključuje tudi teste, ki so edinstveni za preskušanje IOP, kot so primeri od konca do konca, ki nanizajo bolj zapletena zaporedja, ki so lahko podobna običajnemu uporabniškemu scenariju.

Čeprav odobritev načrta preskusa IOP s strani BARB ni potrebna (ob razumevanju, da se bo načrt preskusa IOP še naprej spreminjal in izboljševal z vsakim testnim dogodkom IOP), je potrebna odobritev poročila o preskusu IOP s strani BARB (glej oddelek 5.1.1). . Če preskusni načrt IOP ne izpolnjuje vseh zahtev, opredeljenih v oddelku 4.3.1, mora delovna skupina pred začetkom preskusnih dogodkov IOP predložiti BARB povzetek vseh znanih odstopanj in utemeljitev vsake variance.

Načrt preskusa IOP in testni primeri bi morali temeljiti predvsem na vsebini testnih dokumentov pripadajočih specifikacij.

Da bi bili preskusni dogodki IOP učinkoviti, bi morala imeti delovna skupina pripravljen načrt preskusa IOP in vse povezane preizkusne primere, ki bi jih morali imeti na voljo izvajalec v idealnem primeru vsaj en mesec pred prvim testnim dogodkom IOP.

Načrtovanje preskusov združljivosti z nazaj
Za izboljšave specifikacij je treba pri testiranju IOP združljivosti za nazaj upoštevati preverjanje glede na vse aktivne in zastarele različice specifikacije, ker imajo lahko specifikacije in funkcionalnost, ki jih običajno najdemo v izdelkih Bluetooth, zelo dolgo življenjsko dobo (npr. vozila). Delovna skupina mora analizirati ustrezno raven potrebnega testiranja združljivosti za nazaj (če obstaja), vključno s tem, katere različice naj testira in teste, ki jih je treba izvesti, ter to analizo posredovati BARB. BARB mora ponovnoview analizo in priporoča spremembe (če obstajajo), ki jih delovna skupina vključi v načrt testiranja IOP.

Člane, ki sodelujejo pri preizkusih združljivosti s prejšnjo različico, priporočamo, da s seboj prinesejo stare naprave, ki so bile kvalificirane glede na prejšnje različice specifikacije. Delovna skupina mora v poročilu o preskusu IOP prijaviti morebitne napake združljivosti za nazaj. Družbe članice tudi spodbujajo, da v lastnih laboratorijih izvajajo preskuse združljivosti za nazaj zunaj lokacije preskusnega dogodka IOP in da o kakršnih koli težavah, povezanih s specifikacijami, poročajo WG.

Začasne dodeljene številke, uporabljene pri testiranju IOP
Za usklajevanje začasne dodelitve dodeljenih številk, ki se bodo uporabljale na preskusnem dogodku IOP, se je treba posvetovati z BSTS in BARB, da ne bo prekrivanja ali sporov z drugimi specifikacijami. Te začasne vrednosti morajo biti vključene v preskusni načrt IOP in jih nobena sprejeta specifikacija ne bo dodelila za uporabo.

Za preskušanje IOP, kjer je predlagana ena ali več novih 16-bitnih vrednosti UUID, so vrednosti v območju od 0x7F00 do 0x7FFF rezervirane za preskušanje IOP.

Za preskušanje IOP, kjer je predlagana ena ali več vrednosti storitve multiplekserja s fiksnim protokolom (PSM), bodo uporabljene vrednosti, ki se začnejo od konca veljavnega obsega od 0x0000 do 0x007F, kot je določeno v specifikaciji jedra.

Zahteve glede pokritosti
Delovna skupina mora družbi BARB predložiti dokazilo, da je zahtevano število (kot je opisano v nadaljevanju) neodvisnih izvedb prestalo vsak testni primer. Vsaka zahteva delovne skupine za izjeme od zahtevanega števila neodvisnih izvedb mora biti navedena v preskusnem načrtu IOP, ki je predložen BARB.

Šteje se, da so izvedbe neodvisne druga od druge, če so vsi deli, ki so pomembni za validacijo, razviti neodvisno, tj. V različnih skupinah (ki niso nujno iz različnih podjetij). BSTS lahko pomaga pri oceni, ali je mogoče prototipe obravnavati neodvisno drug od drugega, da se ohrani anonimnost in zaupnost podrobnosti izvedbe.

Upoštevajte, da testna orodja, vključno s PTS, ne veljajo za neodvisne izvedbe.

Osnovne zahteve IOP pokritost zahteve
Funkcija specifikacije jedra običajno opredeli eno ali več vlog, pri čemer je vsaka vloga zasnovana tako, da je sposobna sodelovati z eno ali več drugimi vlogami ali morda samo s seboj.

Za vsak par vlog, ki so namenjeni medsebojni interakciji, je treba dokazati, da vsaj tri neodvisne izvedbe vsake vloge delujejo s tremi neodvisnimi izvedbami komplementarne vloge.

Za vsako vlogo, ki lahko deluje z drugo napravo v isti vlogi, morajo vsaj tri neodvisne izvedbe te vloge dokazati, da lahko med seboj sodelujejo v tej vlogi.

Zahteve za kritje IOP za specifikacijo storitve
Vsaj tri neodvisne izvedbe storitev morajo dokazati, da sodelujejo z vsaj eno odjemalsko izvedbo, ki je lahko PTS.

Profile in zahteve glede pokritosti IOP specifikacije protokola
Profile in specifikacije protokola običajno definirajo eno ali več vlog, pri čemer je vsaka vloga zasnovana tako, da deluje z eno ali več drugimi vlogami ali morda sama s seboj.

Za vsak par vlog, namenjenih medsebojni interakciji, morata vsaj dve neodvisni izvedbi vsake vloge dokazati, da medsebojno sodelujeta z dvema neodvisnima izvedbama komplementarne vloge.

Za vsako vlogo, ki lahko deluje z drugo napravo v isti vlogi, morajo vsaj tri neodvisne izvedbe te vloge dokazati, da v tej vlogi medsebojno sodelujejo.

Zahteve glede pokritosti IOP s specifikacijo modela
Vsaj tri neodvisne izvedbe strežniškega modela ali nadzornega modela morajo dokazati, da medsebojno delujejo z vsaj eno odjemalsko izvedbo (ki je lahko PTS), najmanj ena izvedba odjemalskega modela pa mora dokazovati, da deluje z vsaj eno izvedbo strežniškega modela in PTS.

Oštevilčenje različice specifikacije

Med 0.9/CR Stage, delovna skupina mora pripraviti priporočilo, ki ga bo predložila UO v zvezi s številko različice, ki se bo uporabila za specifikacijo, ko bo sprejeta.

Različice specifikacij se delijo na dve vrsti: različice s polno različico, ki vključujejo nove ali posodobljene funkcije, in različice izdaje za vzdrževanje (znane tudi kot "različice dot-Z"), ki vključujejo tehnične in uredniške napake, ne vključujejo pa novih ali posodobljenih Lastnosti. Različice s polno različico imajo dvodelne številke v obliki XY, na primer 2.1 ali 5.0, medtem ko imajo različice izdaje za vzdrževanje tridelne številke v obliki XYZ, na primer 2.1.2. Vrednost Z ne more biti 0.

Za kateri koli dve različici se ena imenuje "višja različica", druga pa "nižja različica". To se določi v skladu z naslednjimi pravili:

Če se komponente X razlikujejo, je tista z višjo vrednostjo X višja različica.
Če so komponente X enake, komponente Y pa se razlikujejo, je tista z višjo vrednostjo Y višja različica.
Če so komponente XY enake, komponente Z pa se razlikujejo, je tista z višjo vrednostjo Z višja različica. V ta namen se dvodelna številka XY obravnava kot tridelna številka XY0.

Na primerampnaslednje številke različic bi bile razvrščene od najnižje do najvišje različice: 1.4, 2.0, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.2. Za CSS vsaka posodobitev poveča samo X komponento številke različice.

Predpogoji za odobritev upravnega odbora
Na koncu faze razvoja specifikacij morajo biti izpolnjene naslednje zahteve, preden je zahteva za 0.9 / CR predložena upravi v odobritev:

Delovna skupina je zaključila analizo pokritosti preskusov.
BSTS je zaključil reviewspecifikacije 0.9/CR in testnih dokumentov.
BARB je odobril specifikacijo 0.9 / CR.
BARB je odobril CSS CR (če specifikacija zahteva nove vnose), ki je lahko vdelan v okrajšani CR specifikacije.
BARB je odobril GSS CR in MDP CR (če so v specifikaciji potrebni novi vnosi).
ZTI je odobril 0.9/CR Test Suite, ICS in TCRL, skupaj z IXIT (pod pogojem, da je IXIT potreben za izvajanje testov v Test Suite). TCRL je pri tem neobvezentage za posodobitve osnovne specifikacije.
Delovna skupina je BARB predložila načrt testiranja IOP za ponovnoview (če BARB ne odpove testiranja).

Dokumenti, ki se predložijo upravnemu odboru, morajo vsebovati specifikacijo 0.9 / CR, ki jo je odobrila BARB, in predstavitev upravnemu odboru, ki mora vključevati:

Vse znane zahteve za opustitev testiranja IOP ali katere koli zahteve, opredeljene v oddelku 4.3.1
Seznam prevozov, ki jih podpira specifikacija (npr. BR / EDR, LE itd.)
Za izboljšanje specifikacij veljajo kakršne koli izjeme od zahtev za združljivost za nazaj (opisane v oddelku 3.3.2), ki jih zahteva delovna skupina
Za izboljšanje specifikacije priporočilo delovne skupine za številko različice, ki velja za sprejeto specifikacijo
Za izboljšanje specifikacije priporočilo delovne skupine za prenehanje življenjske dobe za prejšnjo različico (-e) sprejete specifikacije, vključno s tehničnimi razlogi, zakaj odprava ali umik katere koli prejšnje različice specifikacije ni priporočljiva, in obrazložitev za priporočilo
Morebitne nerešene resne pomisleke članov BARB ali ZTI (npr. razlogi za morebitne glasove proti med odobritvami, pomisleki, ki izhajajo iz ponovnegaview testnih dokumentov ali skrbi, da je specifikacija 0.9/CR zunaj področja uporabe FRD ali listine)
Status priprave Profile Tuning Suite (PTS) ali druga potrebna orodja, povezana s sprejetjem, ki jih pripravi BSTS

Urad lahko odobri specifikacijo 0.9 / CR za preskušanje IOP, kot zahteva statut [2], preden ZTI odobri dokumente o preskusu 0.9 / CR in preden delovna skupina potrdi, da načrt preskusa IOP izpolnjuje zahteve, opredeljene v oddelku 4.3.1. 0.9. Uprava lahko odobri tudi specifikacijo 0.9 / CR za preskušanje IOP, potem ko BTI odobri preskusne dokumente XNUMX / CR.

0.9/CR Stage zahteve za izstop
0.9/CR Stage je končana in faza validacije se začne, ko upravni odbor odobri začetek testiranja IOP.

4.4 Opustitev postopka razvoja specifikacij

Delovna skupina lahko zahteva odpoved enemu ali več naslednjim korakom postopka:

0.5/DIPD Stage
0.7/FIPD Stage
Preskušanje IOP v fazi preverjanja

Za zahtevo za opustitev mora delovna skupina uporabiti predlogo za opustitev postopka, ki jo zagotavlja Bluetooth SIG [8], in predložiti zahtevo za opustitev vsakemu odboru (tj. BARB ali ZTI), ki mora ponovnoview ali odobri osnutek specifikacije ali pripadajoče testne dokumente na stage, da delovna skupina predlaga opustitev, in vsak od teh odborov mora odobriti zahtevo za opustitev.

Zahteva za opustitev mora vsebovati naslednje:

Identifikacija stage(-e), ki se jim želi delovna skupina odpovedati
Utemeljitev, zakaj stage(-e) je treba opustiti
Identifikacija vsakega odbora (tj. ZTI in/ali BARB), ki se zahteva ponovnoview in odobri zahtevo za opustitev

Odbor, ki obravnava opustitev, lahko zahteva, da predstavnik delovne skupine predstavi obrazložitev opustitve postopka SMPD, preden odloči o zahtevi za opustitev.

Če oprostitev zahteva odpoved več korakom in je del opustitve zavrnjen, del pa odobren, mora odgovor odbora navesti, kateri koraki v zahtevi za opustitev so bili odobreni in kateri zavrnjeni. Če je zahteva za opustitev zavrnjena, mora obvestilo o zavrnitvi vsebovati razloge za zavrnitev.

5. Faza potrjevanja

Med fazo potrjevanja bo delovna skupina izvedla testiranje IOP na specifikaciji 0.9/CR z namenom predložiti poročilo o preskusu IOP za BARB review in odobritev. Kadar koli je mogoče, je treba IOP testiranje izboljšav specifikacij opraviti glede na integrirani osnutek specifikacije. Poleg tega je članica Review, kot zahteva Statut [2], se začne v tej fazi.

Če specifikacija (ali izboljšava) ne zahteva testiranja IOP, se lahko testiranje IOP v fazi validacije opusti s postopkom, opisanim v oddelku 4.4.

Med potekom testiranja IOP (ki je lahko eden ali več dogodkov) mora delovna skupina slediti težavam z uporabo sistema za sledenje težavam Bluetooth SIG in ponavljati, da vključi posodobitve osnutka specifikacije, testnih dokumentov in načrta testiranja IOP. Ko se testiranje IOP zaključi, mora delovna skupina dokončati posodobitve osnutka specifikacije in testnih dokumentov, da bi obravnavala vsa vprašanja, ter pripraviti in predložiti poročilo o preskusu IOP BARB za ponovnoview in odobritev. To je prikazano na sliki 5.1.

Med fazo potrjevanja se lahko začne več dejavnosti. Te dejavnosti se lahko izvajajo vzporedno in vključujejo naslednje:

BSTS odobri specifikacijo 0.9/CR, ki jo je odobril OD, vsem članom z obvestilom o začetku Člana Review rok, ki ga zahteva statut.
Vse potrebne posodobitve so vključene v CSS (ki jih je mogoče vdelati v okrajšani CR specifikacije).
Definicije značilnosti ali deskriptorja so vključene v specifikacijo GSS in PTS za testiranje IOP.
Opredelitve lastnosti mrež so vključene v specifikacijo MDP in PTS za preskušanje IOP.
BSTS omogoča registracijo platforme IOP in orodje za vnos rezultatov v pripravi na testiranje IOP.
Testiranje IOP, če je potrebno (glejte poglavje 5.1).
Review pripombe in vprašanja, vključno s tistimi, ki so bili predloženi kot rezultat testiranja IOP, se obdelajo in spremembe vključijo v osnutek specifikacije.

5.1 Preskušanje IOP

Primarni cilj testiranja IOP je potrditi specifikacijo, nprample, preverjanje točnosti in dvoumnosti znotraj besedila, reviewugotavljanje morebitnih temeljnih napak pri načrtovanju in opustitev ter zagotavljanje validacije glede na predhodno uveljavljene zahteve, razvite prej v procesu razvoja specifikacije. Preskušanje IOP lahko povzroči spremembe osnutka specifikacije in za dokončanje vseh zahtevanih preskusov bo morda potrebnih več preskusnih dogodkov IOP.

Pomembno je, da se članom zunaj delovne skupine omogoči sodelovanje pri testiranju IOP, ker zagotavljajo neodvisnost view specifikacije in lahko odkrije področja nejasnosti v specifikaciji, ki morda niso očitna članom delovne skupine, ki je pripravila osnutek. Pred vsakim testnim dogodkom IOP bo BSTS dal na voljo podrobnosti o dogodku, najnovejši osnutek specifikacije, testno zbirko in načrt testiranja IOP ter o tem obvestil vse člane, najbolje en mesec pred vsakim dogodkom. Posodobljeni osnutek specifikacije, testna zbirka in načrt testiranja IOP, ki se uporabljajo na preskusnem dogodku IOP, morajo biti na voljo vsaj en teden pred vsakim dogodkom.

Med testiranjem IOP bodo posamične kombinacije platform poskusile izvesti teste, udeleženci testiranja IOP pa bodo zabeležili rezultate vsakega preizkusa in komentarje. Anonimizirani povzetek teh rezultatov (ki se nanaša na npr. „Platforma A“, „Platforma B“ itd.) In morebitne pripombe bodo zbrani med preskusnimi dogodki IOP in na voljo članom RG med in po IOP. testni dogodek. V primeru, da so za boljše razumevanje kakršnih koli pripomb ali napak, ki so se zgodile med testiranjem IOP, potrebne dodatne informacije, lahko BSTS deluje kot posrednik za zbiranje dodatnih informacij od člana, ki je predložil.

Če je mogoče, je treba posodobiti PTS, da podpira preskušanje IOP s platformami na vseh slojih nad vmesnikom nadzornika gostitelja (HCI) in biti prisoten na preskusnih dogodkih IOP za te sloje. Na preskusnih dogodkih IOP so lahko prisotna tudi druga orodja za testiranje. Povzetek rezultatov testiranja s PTS ali drugimi testnimi orodji (če obstajajo) mora biti vključen v poročilo o preskusu IOP.

Preskušanje IOP bo na voljo vsem članom, ki želijo zagotoviti prototip, vendar lahko Bluetooth SIG sodelovanje pogojuje s sprejetjem sporazumov z Bluetooth SIG (vključno s sporazumi o sodelovanju in zaupnosti). Delovna skupina je odgovorna za obdelavo in reševanje težav, odkritih med testiranjem IOP, in posodabljanje prizadetih dokumentov; Spremembe, ki jih je odobrila delovna skupina, je treba vključiti kot posodobitve osnutka specifikacije in preskusne dokumentacije za uporabo na vsakem preskusnem dogodku IOP.

Pred fazo potrjevanja lahko delovne skupine izvedejo predhodno testiranje IOP na dogodkih, ki so odprti samo za člane delovne skupine, vendar rezultati neformalnega testiranja morda ne bodo vključeni v rezultate preskusa IOP.

Lahko se zgodi, da se upoštevajo vsi koraki do prvega preskusnega dogodka IOP, vključno z napovedanim datumom in lokacijo IOP z namenom, da se začne testiranje IOP, vendar odobritev upravnega odbora pred začetkom testnega dogodka ni bila zagotovljena. V tem primeru lahko BoD dovoli vključitev rezultatov preskusov, ki so bili zbrani pred odobritvijo uprave za začetek preskušanja IOP, pod pogojem, da so zbrani rezultati temeljili na isti specifikaciji in da je odobril BoD.

Preskušanje IOP ni potrebno za izboljšave specifikacij CSS, GSS ali MDP.

Poročilo o preskusu IOP
Po končanem testiranju IOP mora delovna skupina BARB predložiti poročilo o preskusu IOP, da dokaže, da je zahtevano število neodvisnih platform opravilo zahtevane teste. BARB mora ponovnoview in odobri ali zavrne poročilo o preskusu IOP ter obvesti delovno skupino, če je potrebno dodatno testiranje IOP, preden se paket specifikacij za glasovanje predloži Upravnemu odboru. BSTS in delovna skupina morata zagotoviti, da se v poročilu o preskusu IOP ne pojavi nobena informacija, ki bi identificirala člana, preden poročilo predložita BARB.

Poročilo o preskusu IOP mora vsebovati:

Seznam vseh preskusnih dogodkov IOP, ki so se zgodili med fazo preverjanja, vključno z njihovimi datumi in lokacijami.
Število družb članic in neodvisnih platform, ki so sodelovale na vsakem dogodku IOP, vključno s tem, ali je bil uporabljen PTS.
Seznam različic specifikacij, preskusnega paketa in preskusnega načrta IOP, uporabljenih za posamezen dogodek
Povzetek, v katerem je navedeno, ali so vsi testni primeri ustrezali minimalnim pogojem.
Povzetek vseh odstopanj od zahtev načrta preskusa IOP, opredeljenih v oddelku 4.3.1, in utemeljitev vsake variance.
Povzetek PTS pokritosti za testne primere v Test Suite.
Seznam vseh testnih primerov (vključno s preskusi združljivosti nazaj) iz načrta preskusa IOP, število preizkusov, število neuspešnih preizkusov in ali so bili izpolnjeni minimalni kriteriji za posamezen test, vključno z obrazložitvijo, zakaj niso bile izpolnjene zahteve srečal.
Povzetek težav, komentarjev in vprašanj na vsakem dogodku (vključno s tistimi filed glede na specifikacijo med testiranjem IOP) in vpliv na specifikacijo in testne dokumente.

5.2 Zahteve za izhod iz faze validacije

Faza potrjevanja je končana in faza odobritve / sprejetja se začne, ko je BARB odobril poročilo o preskusu IOP (razen če je BARB opustil testiranje) in so bile izpolnjene vse naslednje zahteve:

BSTS je dal odobreno specifikacijo 0.9/CR na voljo vsem članom za Member Review kot zahteva statut in obvestil vse člane o njegovi razpoložljivosti.
Vse težave, ki so bile ugotovljene med testiranjem IOP in imajo preskusni učinek, so bile vključene in preizkušene.
WG je zaključila testiranje IOP (razen če se je BARB odpovedal testiranju).

6. Faza sprejetja / odobritve

Med fazo sprejetja/odobritve se specifikacija in z njimi povezani testni dokumenti dokončno izdelajo, prejme se odobritev BARB, BQRB in ZTI, izda se obvestilo o predlaganem datumu sprejetja skupaj s končno različico osnutka specifikacije, predložene upravnemu odboru v sprejetje ( Osnutek glasovanja), končni paket specifikacij pa se predloži Upravnemu odboru. Po minimalnem trajanju člana Review zahtevani s statutom [2]), bo Upravni odbor obravnaval specifikacijo za sprejetje na datum sprejetja. Po sprejetju se specifikacija objavi in omogoči kvalifikacijski sistem. Faza sprejetja/odobritve je prikazana na sliki 6.1.

6.1 Osnutek glasovanja

Osnutek za glasovanje se ustvari z vključitvijo posodobitev (na voljo v fazi preverjanja veljavnosti) v zahtevane specifikacijske dokumente in pripravo končnega osnutka nove specifikacije. Za izboljšave specifikacij bo BSTS ustvaril integrirano specifikacijo z vključitvijo enega ali več CR-jev v predhodno sprejeto višjo različico specifikacije (glej oddelek 4.3.2), če še ni končana pred fazo validacije.

Če se v tej fazi spremenijo specifikacije in WG, BARB ali BTI ugotovi, da kakršna koli sprememba zahteva dodatno preskušanje IOP, se bo specifikacija vrnila v del preskusa IOP v fazi preverjanja veljavnosti, da bo WG izvedla dodatne preskuse. Med fazo sprejetja / odobritve bodo do datuma sprejetja izpolnjeni in na voljo naslednjemu dokumentu:

Osnutek glasovanja
Vse podporne specifikacije (tj. CSS, GSS, MDP), kot jih zahteva ustrezna vrsta specifikacije (ali izboljšave), če niso bile prej sprejete
Za izboljšave specifikacij je bila sprejeta različica sprejete specifikacije s spremembami, ki prikazuje spremembe, predlagane v osnutku glasovanja
Opis delovne skupine vseh zahtev glede združljivosti za nazaj (kot je opisano v oddelku 3.3.2), ki niso bile izpolnjene, in utemeljitev kakršnih koli izjem
Opis iz delovne skupine vseh zahtev načrta testiranja IOP (kot je opisano v razdelku 4.3.1), ki niso izpolnjene, in utemeljitev kakršnih koli odstopanj skupaj s poročilom o preskusu IOP (ki se lahko zagotovi s povezavo do kopije na Bluetooth SIG webspletno mesto)
Priporočilo delovne skupine za opustitev ali umik katere koli prejšnje različice(-e) sprejete specifikacije skupaj z utemeljitvijo, ki poudarja spremembe od 0.9/CR Stage priporočilo ob koncu življenjske dobe
Povzetek, ki ga je pripravila delovna skupina, sprememb funkcij ali funkcionalnosti po specifikaciji 0.9 / CR (če obstaja)
Povzetek, ki ga je pripravil BARB, zaskrbljenosti članov BARB, da specifikacija, ki jo je pripravila delovna skupina, presega obseg listine, ki jo je odobrila uprava (če obstaja)
Seznam preostalih nerešenih pravnih vprašanj iz pravne review (če obstaja)
Testni paket, ki ga je odobrila ZTI, skupaj s povzetkom testne pokritosti specifikacije glasovnega osnutka s strani delovne skupine. V primeru novo dodane ali spremenjene funkcije brez preskusne pokritosti je potrebna pisna obrazložitev opustitve
ICS in IXIT, odobrena z ZTI (če to zahteva specifikacija)
TCRL, ki sta ga odobrila ZTI in BQRB
Poročilo, ki ga je BSTS skupaj z ZTI pripravil v zvezi s stanjem pripravljenosti orodij (npr. PTS in druga preskusna orodja, Bluetooth Launch Studio), vključno s tem, da testna orodja ne podpirajo testnih primerov v TCRL
Povzetek vseh potrebnih dodeljenih številk, ki ga pripravi delovna skupina
Kontrolni seznam za posvojitev, ki sta ga pripravila BSTS in delovna skupina, ki kaže, da so vsi rezultati v tem oddelku izpolnjeni
Vse druge informacije, ki jih zahteva uprava

Med fazo sprejetja / odobritve bi morala delovna skupina uporabiti sistem za sledenje izdajam Bluetooth SIG, da zajame težave in komentarje v zvezi z osnutkom specifikacije in preskusnimi dokumenti, tako da se upoštevajo pri dokončanju specifikacije osnutka glasovanja. Za izboljšanje specifikacije morajo biti vključene vse ustrezne odobrene napake (tj. Tiste odobrene napake, ki še niso integrirane) in jih je treba identificirati s sledenimi spremembami.

Delovna skupina mora končni osnutek specifikacije predložiti BSTS v pravno revizijoview. Za nove specifikacije velja zakonska review bo vseboval celotno specifikacijo. Za izboljšave specifikacij, review se bo osredotočil predvsem na spremenjene dele specifikacije. Namen pravne review je predvsem ugotavljanje pravnih tveganj, ki bi jih delovna skupina morala upoštevati in jih poskušati rešiti. Pravne povratne informacije bodo kategorizirane glede na resnost. Če je neobvezna pravna review je bila izvedena pri 0.9/CR Stage, različica, ki je predložena v pravni review mora kot spremljane spremembe prikazati vse spremembe, ki so bile narejene od te različice (ustvarjene s strani WG ali BSTS). Po zaključku pravne review, se bosta delovna skupina in BSTS dogovorila o povratnih informacijah, ki bodo vključene v osnutek specifikacije. Če obstajajo nerešeni pravni komentarji pravne review o osnutku specifikacije lahko predsednik delovne skupine zahteva čas na dnevnem redu upravnega odbora za dogovor o sklepu.

Vzporedno s pravnim review, mora delovna skupina osnutek specifikacije predložiti BARB za ponovnoview. Po prvi predložitvi BARB bo BSTS obvestil vse člane, da je bil osnutek specifikacije predložen BARB za ponovnoview in da je na voljo tudi za člana Review. Če delovna skupina predloži posodobitve osnutka specifikacije za BARB re-review, bo BSTS redno pošiljal dodatna obvestila vsem članom.

Po zaključku BARB review, se bosta delovna skupina in BARB dogovorila o povratnih informacijah, ki bodo vključene v osnutek specifikacije.

Če pravni review povzroči morebitne vsebinske spremembe, dodatne review BARB bo morda potreben. Podobno, če BARB review povzroči kakršne koli vsebinske spremembe, bo BSTS ugotovil, ali bo dodatna pravna review teh sprememb je potrebna. Po zaključku pravne review in BARB review, mora BARB sprejeti ali zavrniti osnutek glasovanja.

Če kateri koli testni dokumenti zahtevajo posodobitev, bo BSTS pomagal WG pri posodabljanju testnih dokumentov. ZTI mora bodisi odobriti bodisi zavrniti testne dokumente. Če jo odobri ZTI, bo BTI pomagal pri dokončanju TCRL in ta dokument poslal BQRB skupaj s pripadajočimi ICS, IXIT in Test Suite. BSTS bo ocenil datum seje odbora, ko namerava odbor glasovati o sprejetju osnutka glasovanja (datum sprejetja), in ga zagotovil za uporabo v TCRL. Odobritev specifikacije s strani BARB, odobritev ZTI vseh testnih dokumentov (vključno s testnim paketom, TCRL, ICS in IXIT) ter odobritev TCRL s strani BQRB mora biti opravljena na ali pred datumom sprejetja.

BSTS bo obvestil vse člane o dokončanju in razpoložljivosti osnutka za glasovanje ter datumu sprejetja. Datum sprejetja ne bo določen prej kot 60 dni po tem, ko so bili člani obveščeni o specifikaciji 0.9/CR, ki jo je odobril UO, razen če član Review rok skrajša Upravni odbor v skladu s statutom in članom v skladu s statutom posreduje najmanj 14 dni po obvestilu o datumu sprejetja. Za primere, ko je bilo v osnutek glasovanja vključenih več CR, se začetek Člana Review je datum, ko so bili člani obveščeni o zadnjem CR, ki ga je odobril UO.

Potem ko so člani obveščeni o datumu sprejetja, so dovoljeni popravki tipografskih napak v osnutku glasovanja, ki jih odobri upravni odbor. Časovnica sprejetja specifikacije je prikazana na sliki 6.2.

6.2 Dodeljene številke

Bluetooth SIG vzdržuje javno dostopen niz dodeljenih številk na dodeljenih številkah Bluetooth SIG webspletno mesto [7]. Te dodeljene številke so združene v različne številske prostore (povezan niz številk brez dvojnikov). Dodeljene številke se lahko prekrivajo z drugimi dodeljenimi številkami v različnih številskih prostorih, vendar nobene številke znotraj številskega prostora ni dovoljena ponovna uporaba. Različni številski presledki so opredeljeni v specifikaciji, ki opredeljuje uporabo dodeljenih številk.

Potem ko BARB odobri poročilo o preskusu IOP, bo delovna skupina BARB predložila zahtevo za dodelitev novih številk znotraj številskega prostora(-ov), ki ga zahteva končna specifikacija. BARB bo ponovnoview zahtevo in delo z BSTS za določitev dodeljenih številk. Po odobritvi BARB bo BSTS načrtoval objavo dodeljenih številk, ki bodo javno dostopne na dodeljenih številkah Bluetooth SIG webstrani [7] v enem tednu po sprejetju specifikacije.

Ko je objava dodeljenih številk na Bluetooth SIG dodeljene številke webna mestu ali znotraj sprejete specifikacije, je predvideno, da so dodeljene številke nespremenljive (da se ne spremenijo v vrednosti ali pomenu). Če iz nekega razloga postanejo neuporabne, postanejo rezervirane vrednosti in jih ni dovoljeno ponovno uporabiti.

6.3 Zahteve za izhod iz faze sprejetja / odobritve

Faza odobritve / sprejetja je končana, ko je upravni odbor sprejel specifikacijo in zaključili naslednje dejavnosti po sprejetju:

BSTS je dal končne dodeljene številke javno dostopne na Bluetooth SIG webmesto.
BSTS je sprejeto specifikacijo dal na voljo javnosti na Bluetooth SIG webmesto
BSTS je dal vse spremne dokumente (npr. CSS, GSS, MDP), potrebne za ustrezno specifikacijo, javno dostopne na Bluetooth SIG webmesto.
BSTS je vsem članom na Bluetooth SIG omogočil dostop do povezanih testnih dokumentov webmesto.
Za izboljšave specifikacij je BSTS izdelal informativno različico predhodno sprejete različice specifikacije, ki sledi spremembam, z vsemi spremembami, ki jih je naredila na novo sprejeta različica, in jo dal na voljo vsem članom na Bluetooth SIG webmesto.
BSTS je omogočil sistem kvalifikacij.
BSTS je vse člane obvestil o razpoložljivosti sprejete specifikacije in vseh spremnih dokumentov.

Bluetooth SIG načrtuje, da bo te dejavnosti po sprejetju zaključil v enem tednu po sprejetju specifikacije.

7. Faza vzdrževanja specifikacije

Faza vzdrževanja specifikacije se začne po končani fazi sprejetja / odobritve. Če se najdejo težave (npr. Nejasnosti besedila ali tehnične napake) s specifikacijo ali pripadajočimi testnimi dokumenti, jih je treba dokumentirati z ustvarjanjem predlogov za napake z orodjem Bluetooth SIG Errata. Predlogi za naročila specifikacij bodo obdelani, kategorizirani in odobreni v skladu z EPD [3]. Erratum Test Suite se obdeluje in razvršča v skladu s TSTO [5]. Če med SMPD in EPD ali TSTO pride do konfliktov, ima prednost SMPD.

Napake v specifikacijah se smejo uporabljati samo za odpravljanje tehničnih ali uredniških napak v končno sprejetih specifikacijah Bluetooth. Dodajanje, spreminjanje in odstranjevanje funkcionalnosti je mogoče samo s postopkom izboljšanja specifikacij, opredeljenim prej v tem dokumentu.

7.1 Pospešeni postopek popravila

Ko je napaka odobrena po postopku, opredeljenem v EPD [3], lahko delovna skupina, BARB ali BSTS priporoči, da se šteje za nujno in ga je treba pospešiti. Ko se to zgodi, bo BSTS skupaj z delovno skupino ali BARB predstavil priporočilo upravnemu odboru. Upravni odbor se bo odločil, ali bo priporočilo sprejel ali zavrnil. Če je priporočilo sprejeto, bo BSTS nemudoma vključil odobreno napako v predlogo napake [8] in sodeloval z odgovorno delovno skupino, da bi dokončal hitri popravek napak, ki bo predložen delovni skupini za ponovnoview in odobritev.

Večview pospešenega postopka erratum je prikazan na sliki 7.1.

Pred datumom sprejetja je treba izpolniti in dati na voljo naslednje dokumente:

Osnutek, ki ga je odobril BARB, pospešeni popravek napak.
Opis delovne skupine o kakršnih koli zahtevah glede združljivosti za nazaj (kot je opisano v oddelku 3.3.2), ki niso bile izpolnjene, in utemeljitev kakršnih koli izjem.
Seznam preostalih nerešenih pravnih vprašanj iz pravne review (če obstaja).
Test Suite, odobren z ZTI, ICS in IXIT (če to zahteva napaka).
TCRL, odobrena z BTI in BQRB (če to zahteva napaka).
Poročilo, ki ga je BSTS skupaj z ZTI izpolnil v zvezi s stanjem pripravljenosti orodij (npr. PTS in druga preskusna orodja, Bluetooth Launch Studio), vključno s tem, da testna orodja ne podpirajo testnih primerov v TCRL, in obrazložitev (če zahteva napaka ).
Kontrolni seznam za posvojitev, ki sta ga izpolnila BSTS in delovna skupina, ki kaže, da so vsi rezultati v tem poglavju izpolnjeni.
Vse druge informacije, ki jih zahteva uprava.

BSTS bo sodeloval z odgovorno delovno skupino, da bi dokončal osnutek hitrega popravka napak in ustvaril različico, ki jo bo predložila odgovorni delovni skupini za ponovnoview in odobritev.

Delovna skupina mora hitri popravek napak predložiti BSTS v pravno revizijoview. Po zaključku pravne review, se bosta delovna skupina in BSTS dogovorila o povratnih informacijah, ki bodo vključene v hitri popravek napak. Če obstajajo nerešeni pravni komentarji pravne review v zvezi s hitrim popravkom napak lahko predsednik delovne skupine zahteva čas na dnevnem redu upravnega odbora za pridobitev prispevkov odbora za rešitev.

Vzporedno s pravnim review, mora delovna skupina BARB predložiti hitri popravek napak za review. Ko bo hitri popravek napake predložen BARB, bo BSTS omogočil dostop vsem članom za ponovnoview in obvesti vse člane o njegovi razpoložljivosti. Po zaključku BARB review, se bosta delovna skupina in BARB dogovorila o povratnih informacijah, ki bodo vključene v hitri popravek napak.

Če kateri koli testni dokumenti zahtevajo posodobitev, bo BSTS pomagal WG pri posodabljanju testnih dokumentov. Po odobritvi BTI testnih dokumentov bo BTI pomagal pri dokončanju TCRL in ga poslal BQRB skupaj z ustreznimi ICS, IXIT in Test Suite. BSTS bo ocenil datum sprejetja in ga poslal ZTI za uporabo v TCRL. Odobritev pospešenega popravka napak s strani BARB, odobritev ZTI vseh testnih dokumentov (vključno s testnim paketom, TCRL, ICS in IXIT, kot je primerno) in odobritev TCLB s strani BQRB morajo biti na datum sprejetja ali pred njim.

BSTS bo vse člane obvestil o dokončanju in razpoložljivosti hitrega popravka napak ter predlaganem datumu sprejetja. Datum sprejetja bo določen in o njem obveščen vsem članom v skladu s statutom [2], datum sprejetja pa bo potekal vsaj 14 dni po tem, ko bodo člani prejeli obvestilo. Potem ko je članom poslano obvestilo o predlaganem datumu sprejetja, lahko odbor odobri popravke tipografskih napak v popravku pospešenih napak, ne da bi dodatno obvestil o predlaganem datumu sprejetja in čakal potrebnih 14 dni.

Bluetooth SIG bo sprejel Popravek hitrih napak javno dostopen in to načrtuje v enem tednu po sprejetju. Obvestilo o njegovi razpoložljivosti bo BSTS poslal vsem članom.

Pospešeni postopek napake je končan, ko je upravni odbor sprejel popravek hitrih napak in so bile zaključene naslednje dejavnosti po sprejetju:

BSTS je dal sprejeti hitri popravek napak in povezane testne dokumente (če to zahteva napaka) javno dostopen na Bluetooth SIG webmesto.
BSTS je omogočil sistem kvalifikacij (če to zahteva napaka).
BSTS je vse člane obvestil o razpoložljivosti sprejetega popravka hitrih napak.

Po zaključku teh dejavnosti bo popravek napak predviden za vključitev v prizadete specifikacije bodisi kot del načrtovane izboljšave specifikacije bodisi v prihodnji izdaji vzdrževanja, kot je opisano v oddelku 7.2.

7.2 Postopek sprostitve vzdrževanja (specifikacije .Z)

Približno letno bo BSTS ugotovil, ali obstajajo odobrene napake (imenovane popravki napak), ki so razvrščene kot tehnične / visoke ali tehnične / kritične in jih še ni treba vključiti v besedilo katere koli aktivne specifikacije (tj. sprejeta specifikacija, ki ni bila opuščena ali umaknjena). Glej Dodatek A za opredelitve razvrstitev napak. Lastnik specifikacije (bodisi WG, ki je pooblaščena za vzdrževanje specifikacije, bodisi BARB, če nobena WG ni zakupljena za vzdrževanje specifikacije) lahko zahteva tudi predhodno izdajo aktivne specifikacije vzdrževanja, v katero bo vključena kakršna koli odobrena napaka. Na podlagi določitve BSTS ali zahteve lastnika specifikacije se bo začel postopek sprostitve vzdrževanja.

Večview postopka izdaje vzdrževanja je prikazano v Napaka! Referenčni vir ni bil najden.

Na začetku postopka izdaje vzdrževanja bo BSTS skupaj z lastnikom specifikacije, BARB in BTI razvil in predstavil načrt za vključitev popravkov napak v objavljeno različico specifikacije. Predlagani načrt mora navajati, ali bodo popravki napak vključeni v izdajo specifikacije o vzdrževanju (tj. Različica .Z) ali izboljšava specifikacije, ki že poteka (tj. Različica XY). Predlagani načrt bi moral upoštevati, ali so bile med različicami sprejetih specifikacij dodane nove obvezne značilnosti, predvideni čas, ko je predvidena naslednja izboljšava specifikacije, in drugi dejavniki.

Po odobritvi načrta s strani uprave bo BSTS skupaj z lastnikom specifikacije nadaljeval z vključevanjem vseh popravkov tehničnih / srednjih, tehničnih / visokih in tehničnih / kritičnih napak v osnutek specifikacije, ki se imenuje „Osnutek izdaje vzdrževanja“. Če se popravek uredništva ali tehničnih / nizkih napak nanaša na več različic specifikacije, bo BSTS, razen če BoD ne navede drugače, te napake vključil v samo najnovejšo različico višjih specifikacij ob naslednji posodobitvi te različice. . V osnutek izdaje vzdrževanja ne sme biti vključenih nobenih sprememb, razen vključitve popravkov napak. Vsak osnutek izdaje vzdrževanja mora z uporabo sledenja sprememb identificirati vse vključene popravke napak, da se prikažejo predlagane spremembe predhodno sprejete različice objavljene specifikacije.

Čas predlagane vključitve za vsak popravek napak v osnutku izdaje vzdrževanja bo odvisen od vpliva preskusne zbirke: vsi popravki napak, ki nimajo učinka preizkusne zbirke, bodo morda vključeni takoj, vendar bodo popravki napak, ki vplivajo na preskusno različico, obdela tako, da časovni razpored sovpada s posodobitvijo TCRL.

ZTI in BSTS bosta določila rok za vključitev popravkov napak z vplivom Test Suite v osnutek izdaje vzdrževanja. Ta rok je običajno 3 do 6 mesecev pred načrtovanim datumom odobritve naslednje večje izdaje TCRL. Popravki napak z učinkom Test Suite, ki zamudijo rok za vključitev, bodo obdelani kot del naslednje letne izdaje TCRL. Torej, razen če se zahteva predhodna izdaja, je najdaljši čas za popravke tehničnih / visokih ali tehničnih / kritičnih napak v posodobitvi specifikacij približno 15 do 18 mesecev.

Lastnik specifikacije mora predložiti osnutek izdaje za vzdrževanje, ki ga je odobril kot dokončnega za pravno revizijoview. Pravni review se bo osredotočil predvsem na spremenjene dele specifikacije. Po zaključku pravne review, se bosta lastnik specifikacije in BSTS dogovorila o povratnih informacijah, ki bodo vključene v osnutek izdaje za vzdrževanje. Če obstajajo nerešeni pravni komentarji pravne review na osnutku izdaje za vzdrževanje lahko lastnik specifikacije zahteva čas na dnevnem redu upravnega odbora, da poišče prispevek Upravnega odbora za rešitev.

Vzporedno s pravnim review, mora lastnik specifikacije BARB-u predložiti osnutek izdaje za vzdrževanje za ponovnoview. Ko bo osnutek izdaje za vzdrževanje predložen BARB, bo BSTS omogočil dostop vsem članom za ponovnoview in obvesti vse člane o njegovi razpoložljivosti. Po zaključku BARB review, se bosta lastnik specifikacije in BARB dogovorila o povratnih informacijah, ki bodo vključene v osnutek specifikacije.

Za popravke napak, ki vplivajo na testne dokumente, in kjer bodo ustrezne testne napake pravočasno obdelane za prihajajočo izdajo TCRL, bo BSTS sodeloval z lastnikom specifikacije in ZTI, da bo posodobil testne dokumente. Po odobritvi testnih dokumentov ZTI bo BSTS ocenil datum sprejetja in predlagani datum sprejetja poslal ZTI za uporabo v TCRL. ZTI bo TCRL dostavil BQRB skupaj s pripadajočimi ICS, IXIT in Test Suite, kot je primerno. Odobritev specifikacije s strani BARB, odobritev ZTI vseh testnih dokumentov (vključno s testnim paketom, TCRL, ICS in IXIT, kot je primerno) in odobritev TCRL s strani BQRB morajo potekati na ali pred datumom sprejetja.

BSTS bo vse člane obvestil o zaključku in razpoložljivosti osnutka glasovanja ter predlaganem datumu sprejetja. Datum sprejetja bo določen in o njem obveščen vsem članom v skladu s statutom, datum sprejetja pa bo potekal najmanj 14 dni po prejemu obvestila članom. Potem ko je članom poslano obvestilo o predlaganem datumu sprejetja, lahko odbor odobri popravke tiskarskih napak v osnutku glasovanja, ne da bi dodatno obvestilo o predlaganem datumu sprejetja počakal potrebnih 14 dni.

Pred datumom sprejetja je treba izpolniti in dati na voljo naslednje dokumente:

Osnutek glasovanja
Različica osnutka glasovanja s spremembami, ki prikazuje vse spremembe sprejete različice specifikacije, ki ima enako vrednost XY (npr. Če je glasovalni osnutek predlagan kot različica 1.4.2, bodo spremembe sledile 1.4.1. različica specifikacije)
Priporočilo lastnika specifikacije za opustitev ali umik katere koli prejšnje različice sprejete specifikacije skupaj z utemeljitvijo
Seznam preostalih nerešenih pravnih vprašanj iz pravne review (če obstaja)
Testni paket, ICS in IXIT, odobren z ZTI (če to zahteva izjava o vzdrževanju)
TCRL, odobrena z BTI in BQRB (če to zahteva izjava o vzdrževanju)
Poročilo, ki ga je BSTS skupaj z ZTI izpolnil v zvezi s stanjem pripravljenosti orodij (npr. PTS in druga preskusna orodja, Bluetooth Launch Studio), vključno z vsemi testnimi primeri v TCRL, ki jih testna orodja ne podpirajo, in razlaga (če to zahteva vzdrževanje sprostitev)
Kontrolni seznam za posvojitev, ki sta ga izpolnila BSTS in lastnik specifikacije, ki kaže, da so vsi zaključki v tem oddelku izpolnjeni
Vse druge informacije, ki jih zahteva uprava

Postopek sprostitve vzdrževanja je končan, ko je upravni odbor sprejel osnutek glasovanja in so bile zaključene naslednje dejavnosti po sprejetju:

BSTS je dal sprejeto specifikacijo in povezane testne dokumente (če to zahteva izdaja za vzdrževanje) javno dostopne na Bluetooth SIG webmesto.
BSTS je naredil informativno različico predhodno sprejete različice specifikacije, ki spremlja spremembe, z vsemi spremembami, vključenimi v novo sprejeto različico, na voljo vsem članom na Bluetooth SIG webmesto.
BSTS je omogočil sistem kvalifikacij.
BSTS je vse člane obvestil o razpoložljivosti sprejetih specifikacij in dokazil.

Bluetooth SIG načrtuje, da bo te dejavnosti po sprejetju zaključil v enem tednu po sprejetju specifikacije.

Po zaključku teh dejavnosti ostane specifikacija v fazi vzdrževanja specifikacije, dokler specifikacija ne zastare ali umakne, kot je določeno v oddelku 8.

8. Specifikacija Faza izteka življenjske dobe

Specifikacije bodo morda opuščene ali umaknjene, če bodo nadomeščene z novejšimi različicami, za katere se ugotovi, da so tehnično nezadostne, ali iz drugih razlogov. Zastarele in umaknjene specifikacije se arhivirajo in se ne posodabljajo več. Zastarele in umaknjene specifikacije so v programu za usposobljenost Bluetooth različno obravnavane.

Vsak član, skupina ali odbor lahko BSTS predloži priporočila za opustitev ali umik specifikacije skupaj s pripadajočim časovnim načrtom (po e-pošti

specification.manager@bluetooth.com) kadar koli. BSTS lahko priporoči tudi opustitev ali umik specifikacije in povezane časovnice. BSTS bo priporočilo posredoval BARB in skupini ali odboru, ki je odgovoren za vzdrževanje specifikacije za ponovnoview in povratne informacije.

BARB in pristojna skupina ali odbor bodo ocenili priporočila za opustitev ali umik specifikacije in upoštevali naslednja (neizčrpna) merila:

Ali obstaja v prejšnji različici specifikacije funkcionalnost, ki je zastarela ali je ne bi smeli uporabljati?
Ali je bila poznejšim različicam dodana nova obvezna funkcionalnost?
Ali obstajajo pomanjkljivosti v prejšnjih različicah, ki poslabšujejo delovanje ali interoperabilnost, ki so bile popravljene v poznejših različicah in so potrebne za napredovanje obstoječih uporabniških scenarijev?
Ali so v poznejših različicah potrebne dodatne funkcije za napredovanje novih uporabniških scenarijev?
Ali je v poznejših različicah izboljšana uporabnost in interoperabilnost?
Ali obstajajo varnostne izboljšave v poznejših različicah?

BARB in odgovorna skupina ali odbor lahko predlagajo drugo priporočilo.

Po prejemu povratnih informacij od BARB ali skupine ali odbora, odgovorne za vzdrževanje specifikacije, bo BSTS priporočila in povratne informacije posredoval upravnemu odboru v obravnavo. Upravni odbor lahko povabi skupino ali odbor, ki je odgovoren za vzdrževanje zadevnih specifikacij, da se sestane in razpravlja o priporočilih. Upravni odbor bo upošteval priporočila in povratne informacije ter se lahko strinja s predlogom ali ga spremeni. Upravni odbor bo zahteval, da BSTS obvesti vse člane o predlogih, da opustijo ali umaknejo specifikacijo(e) in povezane časovnice(-e) za 30-dnevno ponovnoview obdobje, ki omogoča vsem članom, da predložijo dodatne povratne informacije, preden sprejmejo končno odločitev.

UO bo upošteval povratne informacije, prejete od članov. Ko BoD odobri razveljavitev ali umik specifikacije, bo BSTS obvestil vse člane o odločitvi in s tem povezani časovni premici.

8.1 Opustitev

Ko je specifikacija opuščena, se bo zgodilo naslednje:

Specifikacija ne bo več posodobljena.
Odgovorna delovna skupina bo ponovnoview vse neporavnane napake, napisane proti zastareli specifikaciji, da se ugotovi, ali veljajo za druge specifikacije. Napake se lahko v sistemu napak zavrnejo in prepišejo v skladu z veljavnimi specifikacijami.
WG ali BSTS bo ustvaril napako za posodobitev vseh potrebnih sklicev na zastarele specifikacije v drugih specifikacijah.
ZTI bo posodobil veljavne preskusne dokumente, da bo označil opustitev specifikacije.
BSTS bo posodobil Bluetooth SIG webspletno mesto z navodili glede alternativnih specifikacij za uporabo.
Nove napake ni mogoče več predložiti zaradi zastarele specifikacije.
Specifikacija ne bo navedena v prihodnjih specifikacijah.
BSTS bo arhiviral različico specifikacije, označeno kot zastarelo za dostop članov v pretekle namene.

8.2 Umik

Ko je specifikacija umaknjena, se poleg korakov, ki veljajo za zastaranje, zgodi naslednje:

ZTI bo posodobil veljavne preskusne dokumente, da bo označil umik specifikacije.
BSTS bo posodobil Bluetooth SIG webspletno mesto z navodili glede alternativnih specifikacij za uporabo.
BSTS bo arhiviral različico specifikacije, označeno kot umaknjeno, za dostop članov v pretekle namene.

Uprava lahko odloči, da bo specifikacijo takoj umaknila, ne da bi jo predhodno razveljavila.

9. Postopek bele knjige

Bele knjige so ustvarjene samo v informativne namene. Naslednji postopek v beli knjigi velja za vse delovne skupine, skupine za upravljanje, odbore za proračun in odbore za Bluetooth. Ta razdelek se ne nanaša na informativne dokumente, ki se uporabljajo samo znotraj Bluetooth SIG.

Ta postopek je prikazan na sliki 9.1 spodaj.

Preden katera koli skupina ali odbor začne delati na beli knjigi, ki jo namerava objaviti s strani Bluetooth SIG, bo skupina ali odbor pripravila predlagano posodobitev listine, ki bo jasno opredelila predlagano vsebino bele knjige in predstavitev predloga bele knjige.

Predstavitev predloga bele knjige mora vsebovati vsaj:

Potreba po belem papirju
Povzetek predlagane vsebine bele knjige
Pojasnilo, zakaj vsebine ni priporočljivo vključiti kot del specifikacije
Predvideno občinstvo
Vsi načrti vzdrževanja (tj. Predvideni čas pred naslednjo izdajo te bele knjige)
Priporočila za ravnanje s prejšnjimi različicami bele knjige, če obstajajo (npr. Arhiviranje)

Posodobitev listine in predstavitev predloga bele knjige je treba predložiti za BARB review. Ob review in odobritev posodobitve listine s strani BARB, bo BSTS posodobitev listine predložil upravnemu odboru v odobritev skupaj s podporno predstavitvijo predloga bele knjige.

Če bo odbor odobril posodobitev listine, lahko skupina ali odbor nadaljuje z izdelavo bele knjige.

Ko skupina ali odbor dokonča razvoj bele knjige, bo BSTS izvedel uredniško ponovnoview za skladnost s smernicami za pripravo besedila Bluetooth.

Po razrešitvi pripomb BSTS mora skupina predložiti belo knjigo BSTS v pravno revizijoview. Po zaključku pravne review, se bosta skupina in BSTS dogovorila o povratnih informacijah, ki bodo vključene v belo knjigo. Če obstajajo nerešeni pravni komentarji pravne review na beli knjigi lahko predsednik skupine zahteva čas na dnevnem redu upravnega odbora, da zaprosi Upravni odbor za mnenje o sklepu.

Vzporedno s pravnim review, mora skupina belo knjigo BARB oddati za review. V okviru njihovega reviewBARB lahko priporoči, ali je treba kateri koli del bele knjige odstraniti iz bele knjige in vključiti v specifikacijo po postopku iz oddelka 3. BARB se lahko tudi odloči, da bo belo knjigo predložil drugim skupinam ali odborom za ponovnoview. Po zaključku BARB review, se bosta skupina in BARB dogovorila o povratnih informacijah, ki bodo vključene v belo knjigo.

Ko BARB odobri belo knjigo, bo avtorjeva skupina ali odbor predložila belo knjigo, ki jo odobri BARB, v odobritev upravnemu odboru.

Postopek izdaje bele knjige je končan, ko je upravni odbor odobril belo knjigo in so bile zaključene naslednje dejavnosti po odobritvi:

BSTS je dal odobreno belo knjigo javno dostopno na Bluetooth SIG webmesto.
BSTS obvesti vse člane o odobreni beli knjigi.
Če je bela knjiga izboljšava obstoječe bele knjige, bo BSTS arhiviral različico bele knjige, s katero bodo člani lahko dostopali v pretekle namene.

Bluetooth SIG načrtuje, da bo dejavnosti po odobritvi zaključil v enem tednu po odobritvi bele knjige.

10. Reference

Referenčni dokumenti Bluetooth so na voljo prek povezave Bluetooth webmesto http://www.bluetooth.com.

Smernice za pripravo besedila Bluetooth (na voljo na strani Predloge in dokumenti delovne skupine na naslovu https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Podzakonski akti Bluetooth SIG, Inc. (na voljo na strani Upravni dokumenti na naslovu https://www.bluetooth.com/membership-working-groups/membership-types-levels/membership-agreements)
Dokument o postopku napake pri specifikaciji Bluetooth (na voljo na strani Predloge in dokumenti delovne skupine na naslovu https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Dokument delovne skupine (na voljo na strani Predloge in dokumenti delovne skupine na naslovu https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Testna strategija in terminologija končanaview dokument (na voljo na strani Zahteve za kvalifikacijski preizkus, na https://www.bluetooth.com/specifications/qualification-test-requirements)
Specifikacija ZTI Review Kontrolni seznam postopka (na voljo na strani Predloge in dokumenti delovne skupine, na https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Dodeljene številke Bluetooth SIG (https://www.bluetooth.com/specifications/assigned-numbers)
Predloge in dokumenti delovne skupine (na voljo na strani Predloge in dokumenti delovne skupine na naslovu https://www.bluetooth.com/membership-working-groups/working-groups/working-group-templates-documents)
Dodatek k specifikaciji GATT (GSS) (na voljo na strani s specifikacijami GATT na naslovu https://www.bluetooth.com/specifications/gatt)
Predložite idejo za novo specifikacijo https://www.bluetooth.com/specifications/submit-an-idea-for-a-specification

11. Kratice in okrajšave

Tabela A: Kratice in okrajšave

Dodatek A - Razvrstitev glede na stopnjo resnosti

Ta dodatek povzema smernice za klasifikacijo resnosti za naročilo specifikacije. Ta tabela bo dodana prihodnji reviziji EPD, nato pa bo ta odstavek izbrisan.

Preberite več o tem priročniku in prenesite PDF:

Dokument o procesu upravljanja specifikacij (SMPD) - Optimiziran PDF
Dokument o procesu upravljanja specifikacij (SMPD) - Izvirnik PDF

Imate vprašanja o vašem priročniku? Objavite v komentarjih!

Reference

Uporabniški priročnik