Dokument o procesu upravljanja specifikacijama (SMPD)

Ovaj dokument, bez obzira na njegov naslov ili sadržaj, nije Bluetooth specifikacija koja podliježe licencama koje dodjeljuje Bluetooth SIG Inc. (“Bluetooth SIG”) i njegovi članovi prema Ugovoru o licenci za Bluetooth patent/autorska prava i Ugovoru o licenci za Bluetooth zaštitni znak.

OVAJ DOKUMENT SE DAJE „KAKV JESTE“ I BLUETOOTH SIG, NJEGOVI ČLANOVI, I NJIHOVA POVEZANOST NE DAJU NIKAKVE IZJAVE ILI GARANCIJE I ODRICU SE SVIH GARANCIJA, IZRIČITIH ILI PODRAZUMEVANIH, UKLJUČUJUĆI BILO KOJU GARANCIJU, NEZGODINU BILO KOJE ODREĐENE NAMENE, DA JE SADRŽAJ OVOG DOKUMENTA BEZ GREŠKA.

U MJERI KOJI NIJE ZABRANJENO ZAKONOM, BLUETOOTH SIG, NJEGOVI ČLANOVI I NJIHOVA POVEZANOST SE ODRIČU SVAKE ODGOVORNOSTI KOJA PROISTIČA IZ ILI KOJA SE ODNOSI NA KORIŠĆENJE OVOG DOKUMENTA I BILO KAKVE INFORMACIJE SADRŽANE U OVOM DOKUMENTU BIZNIS PREKIDA, ILI ZA POSEBNE, INDIREKTNE, POSLEDIČNE, SLUČAJNE ILI KAZNENE ŠTETE, BILO KOJI BISTE PROUZROKOVANI I BEZ OBZIRA NA TEORIJU ODGOVORNOSTI, ČAK I AKO JE BLUETOOTH SIG, MOGUĆNOST NJEGOVIH ČLANOVA, ILI CH DAMAGES.

Ovaj dokument je vlasništvo Bluetooth SIG-a. Ovaj dokument može sadržavati ili pokrivati predmet koji je intelektualno vlasništvo Bluetooth SIG-a i njegovih članova. Dostavljanje ovog dokumenta ne daje nikakvu licencu za bilo kakvo intelektualno vlasništvo Bluetooth SIG-a ili njegovih članova.

Ovaj dokument je podložan promjenama bez prethodne najave.

1. Uvod

Dokument procesa upravljanja specifikacijama (SMPD) opisuje procese koje autori specifikacije i reviewoni moraju slijediti razvoj novih specifikacija i poboljšanje postojećih specifikacija (tj. dodavanje ili uklanjanje funkcionalnosti ili promjenu specifične funkcionalnosti u usvojenoj specifikaciji), održavanje usvojenih specifikacija i upravljanje krajem životnog vijeka usvojenih specifikacija. Osim toga, ovaj dokument opisuje proces kreiranja, reviewing, i odobravanje bijelih knjiga.

Postoje razlike u procesu razvoja specifikacija između razvoja novih specifikacija i poboljšanja postojećih specifikacija zbog inherentnih razlika u obimu tih zadataka; te razlike su istaknute u ovom dokumentu.

Proces razvoja specifikacije uključuje:

Faza zahtjeva (opisana u Odjeljku 3) za definiranje funkcionalnih zahtjeva
Faza razvoja (opisana u Odjeljku 4) za razvoj i review specifikacije

Faza validacije (opisana u odjeljku 5) za validaciju specifikacija pomoću testiranja interoperabilnog prototipa (IOP)
Faza usvajanja/odobrenja (opisana u Odjeljku 6) za predstavljanje specifikacija Upravnom odboru Bluetooth SIG-a (BoD) na usvajanje/odobrenje

Dokument Proces Specification Errata Process (EPD) [3] opisuje proces predlaganja i reviewunošenje grešaka u specifikaciji i njihovo odobravanje kao ispravke grešaka (kako je definisano u Statutu [2]) usvojenim specifikacijama. Osim ako nije drugačije naznačeno, sve reference na greške u ovom SMPD-u znače greške u specifikaciji.

1.1 Prednost

Statut Bluetooth SIG, Inc. (Uslovi) i ugovori o članstvu [2] imaju prednost nad bilo kojim konfliktnim sadržajem u tim dokumentima i SMPD-u. Bez obzira na bilo šta u ovom dokumentu, Upravni odbor zadržava krajnje diskreciono pravo i ovlašćenje da preduzme radnje i donese odluke čak i ako te radnje i odluke ne prate ili su u suprotnosti sa bilo čim u ovom dokumentu, i ništa u ovom dokumentu ne ograničava ili ograničava nezavisna ovlašćenja Upravnog odbora i diskreciju.

Ako postoje sukobi između teksta u SMPD-u i slika, tekst ima prednost.

1.2 Referentne grupe i komiteti

Sljedeće vrste grupa su navedene u ovom dokumentu: Studijske grupe (SG), Stručne grupe (EG) i Radne grupe (WG). Radna grupa također može imati podgrupu koja podnosi izvještaje RG. Slično, u ovom dokumentu se pominju sljedeće vrste odbora: Bluetooth Architectural Review Board (BARB), Bluetooth test i interoperabilnost (BTI) i Bluetooth Qualification Review Ploča (BQRB). Ovaj dokument se takođe odnosi na Bluetooth SIG tehničko osoblje (BSTS) i BoD.

1.3 Komisija reviewi odobrenja

Komisija review je suview koju sprovode članovi odbora (obično 3 člana) kako bi dali povratne informacije u određenom vremenu (obično 2-3 sedmice), međutimview vrijeme može varirati u zavisnosti od dužine i složenosti materijala i drugih prioriteta unutar komisije. Grupa koja traži review i komisija koja sprovodi review svaki se dogovara o trajanju review. Članovi grupe i komiteta koriste Bluetooth SIG alate da obaveste i zabeleže početak i kraj review. Grupa će općenito obrađivati povratne informacije odbora kada ih primi. Kada je komisija review vrijeme ističe, grupa završava obraćanje povratnih informacija odbora, a također treba uzeti u obzir sve kasneview povratne informacije imajući na umu da materijal može biti predmet naknadnog odobrenja komisije.

Odobrenje komisije se dobija glasanjem članova odbora u skladu sa Procesnim dokumentom radne grupe [4].

1.4 Obavještenja za članove i dostupnost materijala

Sva obavještenja koja se dostavljaju članovima u skladu sa ovim dokumentom mogu biti dostavljena putem e-pošte, kao što je periodično tehničko ažuriranje. Obavještenja koja se dostavljaju svim članovima bit će poslana svim aktivnim članovima (tj. tamo gdje članstvo nije suspendirano, prekinuto ili povučeno). Kada se obavještenja pošalju e-poštom, bit će poslana na posljednju poznatu adresu e-pošte (kao što je prikazano u tadašnjim trenutnim zapisima Bluetooth SIG-a) svakog pojedinca koji se registrovao pod članskim računom kompanije člana i koji nije odustao od primanja obavještenja putem e-pošte. Ništa u ovom dokumentu ne mijenja Bluetooth SIG obaveze ili zahtjeve u vezi sa davanjem obavještenja prema Statutu ili bilo kojem drugom sporazumu između Bluetooth SIG-a i bilo kojeg člana.

Gdje god se ovaj dokument poziva na a webstranica koja je dostupna svim članovima, to se odnosi na dostupnost pojedincima koji imaju aktivan Bluetooth SIG nalog. Članovi koji nemaju aktivan nalog mogu kreirati nalog putem Bluetooth SIG-a website.

1.5 Šabloni

Za svaki tip dokumenta (npr. specifikacije, bijele knjige, dokumenti za testiranje) koji se spominju u ovom SMPD-u, Bluetooth SIG obezbjeđuje predložak. Obrazac se mora koristiti kao osnova za svaki dokument izrađen u skladu sa ovim SMPD. Neupotreba ispravnog predloška može dovesti do toga da dokument ne bude odobren. Šabloni su dostupni na Bluetooth SIG-u weblokacija [8].

1.6 Tipovi specifikacija

Postoji nekoliko vrsta Bluetooth SIG specifikacija. Hijerarhijski, sve specifikacije zavise od Bluetooth Core Specifikacije. Specifikacije kao što su tradicionalni profiles; tradicionalni protokoli; i GATT-based profiles, usluge zasnovane na GATT-u i protokoli zasnovani na GATT-u svi zavise od karakteristika unutar osnovne specifikacije. Ostale specifikacije, kao što su specifikacije modela mreže, zavise od Mesh Pro-afile specifikacija koja zauzvrat zavisi od osnovne specifikacije.

Specifikacija Core Specification Supplement (CSS) definira tipove podataka, formate podataka i uobičajene profile i šifre grešaka usluge koje koriste Osnovna specifikacija i druge specifikacije i same po sebi ne definiraju nikakva ponašanja.

GATT Specification Supplement (GSS) specifikacija definira karakteristike i formate deskriptora koje koristi Profiles i usluge i sam ne definira nikakva ponašanja.
Specifikacija Mesh Device Properties (MDP) definiše svojstva mreže koja koristi Mesh Profile i specifikacije modela mreže i sam po sebi ne definira nikakva ponašanja.

2. prekoview

Ovaj odeljak pruža prekoview procesa i nije namijenjen da uključi sve detalje.

Slika 2.1 prikazuje šest glavnih faza koje čine Proces upravljanja specifikacijama.

Prve četiri faze se javljaju tokom procesa razvoja specifikacije i sastoje se od faze zahtjeva (odjeljak 3), faze razvoja (odjeljak 4), faze validacije (odjeljak 5) i faze usvajanja/odobrenja (odjeljak 6). Nakon toga slijede dvije faze nakon usvajanja: faza održavanja specifikacije (odjeljak 7) i faza završetka specifikacije (odjeljak 8).

Slika 2.2 ilustruje detalje četiri faze u procesu razvoja specifikacije. Sivi okviri označavaju glavne rezultate za svaku fazu. Narandžaste kutije sumiraju prekretnice procesa.

U fazi zahtjeva (opisano u Odjeljku 3), prijedlog za početak novog posla (Novi prijedlog rada (NWP)) pokreće proces razvoja specifikacije definiranjem korisničkih scenarija koji će biti omogućeni ako se novi posao nastavi. Ako je NWP odobren, dodijeljena grupa kreira Dokument funkcionalnih zahtjeva (FRD). Nakon što je FRD odobren i dodijeljen grupi, počinje faza razvoja.

Tokom faze razvoja (opisane u Odjeljku 4), razvoj specifikacije napreduje kroz niz stages (0.5/DIPD do 0.9/CR) što je kulminiralo kompletnim nacrtom specifikacije. Specifikacija 0.9/CR je dostupna svim članovima, a zatim se dostavlja Upravnom odboru koji razmatra specifikaciju na odobrenje. Nakon odobrenja, počinje faza validacije.

Tokom faze validacije razvoja specifikacije (opisane u odjeljku 5), specifikacija 0.9/CR koju je odobrio UO je dostupna svim članovima da ponovoview i validirati, a član Review je pokrenut. Validacija se postiže testiranjem interoperabilnosti (IOP) između prototipova koje su izradili članovi. Kada se završi testiranje IOP-a (ako je potrebno za specifikaciju) i BARB odobri izvještaj o IOP testu, tada počinje faza usvajanja/odobravanja.

Tokom faze usvajanja/odobrenja (opisane u Odjeljku 6), specifikacija i povezani dokumenti za ispitivanje su finalizirani; Primljena su odobrenja BARB, BQRB i BTI; a konačni paket specifikacija se dostavlja Upravnom odboru koji razmatra specifikaciju za usvajanje (tj. konačno odobrenje).

Specifikacija će se možda morati vratiti na prethodnu fazu ili stage ako su napravljene značajne promjene. U nekim slučajevima može biti moguće i odustajanje od dijela faze kao što je opisano u Odjeljku 4.4.

Faza održavanja specifikacije (opisana u Odjeljku 7) počinje nakon što Upravni odbor usvoji specifikaciju. Tokom ove faze se prijavljuju i procjenjuju potencijalne greške pronađene u usvojenoj specifikaciji i (ako je potrebno) ispravke grešaka se vrše u specifikaciji. Faza održavanja specifikacije se nastavlja sve dok specifikacija ne bude zastarjela ili povučena (pogledajte Fazu kraja životnog vijeka specifikacije u sljedećem paragrafu).

Faza završetka specifikacije (opisana u Odjeljku 8) opisuje proces odbacivanja i povlačenja usvojenih specifikacija.

3. Faza zahtjeva

Faza zahtjeva počinje ili sa NWP-om (koji navodi želju da se započne rad na jednom ili više korisničkih scenarija) ili nakon utvrđivanja da je željeni novi posao već pokriven njihovom poveljom WG. Ako radna grupa želi da započne novi posao za koji veruje da je već u okviru statuta radne grupe, radna grupa mora da prati proces definisan u odjeljku 3.1 kako bi prešla direktno na razvoj FRD. Za sve ostale stavke rada, RG mora slijediti proces definiran u Odjeljku 3.2. FRD definira opseg funkcionalnih zahtjeva koji se koriste za izradu specifikacija u fazi razvoja. Faza zahtjeva je ilustrovana na slici 3.1.

3.1 Novi rad pokriven poveljom radne grupe

Kada radna grupa želi da započne novi rad i razumno veruje da je funkcionalnost koju želi da doda već u okviru statuta njene radne grupe, radna grupa može započeti rad na FRD, pod uslovom da odmah obavesti BARB. Radna grupa će u svoje obavještenje BARB-u uključiti opis predloženog novog rada i kopiju povelje RG sa istaknutim jezikom koji ih ovlašćuje da započnu novi rad.

Ako BARB odbije analizu WG, WG mora prekinuti rad na FRD-u i nastaviti s NWP procesom navedenim u Odjeljku 3.2. Ako BARB odobri analizu RG, RG će odmah obavijestiti BSTS (putem e-pošte na specification.manager@bluetooth.com) i BSTS će dodati tačku na sljedeći dnevni red Upravnog odbora.

Radna grupa će u svoje obavještenje BSTS-u uključiti iste informacije koje je dostavila BARB-u. Ako UO odbije analizu RG, RG mora prekinuti rad na FRD-u i nastaviti s NWP procesom navedenim u Odjeljku 3.2. Ako UO odobri analizu RG, RG može nastaviti da radi na FRD-u kao što je navedeno u Odjeljku 3.3.

3.2 Predlog novog rada (NWP)

Svaki član, WG, SG ili EG može kreirati i podnijeti NWP (preko Bluetooth SIG-a webstranica [10]). NWP mora uključiti, u najmanju ruku, informacije o sljedećem koristeći službeni obrazac dat u [8]:

Korisnički scenariji
Posvećenost članova razvoju FRD-a iu kojoj oblasti(ima) (npr. Saradnik, Autor, Reviewovaj, izrada prototipa)

Predloženo rukovođenje radom FRD-a
Predloženi grupni zadatak za rad FRD
Adresa e-pošte primarnog(ih) autora

Napomena: Smjernice o NWP procesu su dostupne na Bluetooth SIG weblokacija [10].

BSTS će tokom izrade NWP-a obavljati sljedeće zadatke:

Dajte autoru(ima) potvrdu o prijemu (obično u roku od sedam kalendarskih dana od prijema) i navedite sljedeće korake.

Ako je potrebno, radite sa autorom(ima) tako da NWP bude jasan i potpun. Ovo može zahtijevati nekoliko iteracija NWP-a.
Ako NWP sadrži izjave o greškama u usvojenim Bluetooth specifikacijama, radite sa autorom(ima) da file unosi u sistem grešaka.
Ako se primijeti da NWP potencijalno duplira rad koji je već u toku ili je već završen, obavijestite autora(e) drugog rada radi njihove ocjene.

Objavite NWP u NWP webstranica dostupna svim članovima.
Obavijestite sve članove da je NWP dostupan za review i da li je potrebna dodatna posvećenost članica razvoju FRD-a.

Članovi mogu kontaktirati autora(e) kako bi postavili pitanja ili dali povratne informacije o NWP-u.

Najmanje tri kompanije članice moraju se obavezati da će učestvovati u završetku rezultirajućeg FRD-a da bi NWP postao kandidat za odobrenje UO, a najmanje jedna kompanija članica mora biti pridruženi ili promotorski član. Nakon što UO odobri NWP, UO će dodijeliti NWP postojećoj podgrupi svih članova WG ili SG za rad na FRD-u (opisano u Odjeljku 3.3). Ako odgovarajuća WG podgrupa ili SG ne postoji, može se stvoriti.

Za NWP-ove koji imaju dovoljno članstva, BSTS će obaviti sljedeće dodatne zadatke:

Najmanje 13 dana prije nego što NWP bude predložen za odobrenje od strane Upravnog odbora, obavijestiti BARB i grupu kojoj se NWP preporučuje za dodjelu, o čekanju na odobrenje NWP. Ovo se radi kako bi se pružila prilika za povratne informacije u oblastima kao što je predložena grupa, da li je NWP već pokriven postojećim radom, itd.

Popunjeni NWP dostavite Upravnom odboru.

Ako NWP podnose članovi koji nisu povezani sa grupom, dogovorite da jedan od članova predstavi NWP Upravnom odboru.
Ako NWP podnese grupa, dogovorite da predsjedavajući grupe predstavi NWP Upravnom odboru.

Pozovite predsjedavajućeg BARB-a i predsjednike grupe, kojoj se NWP preporučuje za dodjelu, na sastanak UO.
Ako je NWP odobren i dodijeljen od strane UO, obavijestiti grupu kojoj je dodijeljen; autor(i); članovi identifikovani u NWP-u kao posvećeni razvoju odgovarajućeg FRD-a; i ako NWP predlaže grupa, grupa ishoda i sljedeći koraci.

Nakon što Upravni odbor odobri NWP, ažurirajte status NWP-a website.

Upravni odbor može odbiti bilo koji NWP po svom nahođenju, nprampda, zbog ograničenja resursa, ako je posao već u potpunosti završen, posao je izvan opsega mjerodavnih dokumenata Bluetooth SIG-a (npr. Application Programming Interface (API)) [2], ili ako bi predloženi posao trebao biti filed kao greška. Ako NWP bude odbijen, BSTS će obavijestiti autora(e), članove identificirane u NWP-u kao obavezu da će razviti odgovarajući FRD, i, ako NWP predloži grupa, grupu. Obavijest će sadržavati sve razloge za odbijanje. Autor(i), posvećeni članovi ili grupa mogu zatražiti vreme na dnevnom redu Upravnog odbora za žalbu na odbijanje.

Ako član ili grupa želi da predloži uklanjanje neke karakteristike iz usvojene specifikacije, grupa ili član moraju pripremiti NWP. NWP mora uključiti analizu uticaja koji će uklanjanje imati na kompatibilnost i interoperabilnost unatrag, uključujući analizu uticaja na testne slučajeve.

NWP-ovi nisu potrebni za poboljšanja CSS, GSS ili MDP specifikacija: obično, ažuriranja CSS, GSS ili MDP specifikacija rezultat su ažuriranja drugih specifikacija koje imaju svoje NWP-ove.

3.3 Dokument funkcionalnih zahtjeva (FRD)

FRD-ovi definiraju funkcionalne zahtjeve za omogućavanje korisničkih scenarija. FRD mora uključiti, u najmanju ruku, informacije o sljedećem koristeći službeni obrazac koji je dat u [8]:

Korisnički scenariji
Funkcionalni zahtjevi zasnovani na scenarijima korisnika

Predanost članova da razviju rezultirajuću(e) specifikaciju(e)
Opciona podrška prototipa od strane članova za predviđene uloge
Preporučena radna grupa da razvije rezultujuću specifikaciju(e)

FRD razvoj

FRD-ove kreiraju dodijeljeni svi članovi podgrupe WG ili članovi SG uz uređivačku podršku BSTS-a. Svaki član zainteresovan za učešće u razvoju FRD može se pridružiti grupi.

FRD-ovi moraju naznačiti opredijeljenost od najmanje dvije (iako se ohrabruju tri) kompanije članice na nivou saradnika ili promotera da učestvuju u razvoju rezultirajuće specifikacije. Radne grupe ili SG koje podnesu FRD treba da pokušaju da postignu široku podršku kompanija članica grupe koje predstavljaju ciljani segment industrije identifikovan u FRD.

Nova funkcionalnost koja je predložena u FRD-u trebala bi biti podržana na što većem broju transporta i postojećih uređaja. Ovo uključuje, nprample, podržava GATT bazirane profilei usluge na transportu sa osnovnom brzinom/proširenom brzinom prenosa podataka (BR/EDR) i prenosom sa niskom potrošnjom energije (LE) Bluetooth. Ako novoj funkcionalnosti nedostaje dovoljna podrška članova za transport, nprampZbog nedostatka posvećenosti članova definiranju korištenja transporta ili potencijalno nedovoljnog broja IOP testnih platformi za jednu ili više uloga, podrška za taj transport može biti isključena iz FRD-a.

Osim ako nije drugačije opravdano, nova funkcionalnost, profiles, a usluge moraju biti usklađene sa zahtjevima kompatibilnosti unatrag opisanim u Odjeljku 3.3.2.

Radna grupa ili SG moraju dostaviti FRD BARB-u za review i odobrenje. BARB mora ili odobriti ili odbiti FRD na osnovu svoje inženjerske procjene. Ako odobri BARB, FRD će biti stavljen na raspolaganje svim članovima, a obavještenje o njegovoj dostupnosti će izdati BSTS.

FRD-ovi nisu potrebni za poboljšanja CSS, GSS ili MDP specifikacija: obično, ažuriranja CSS, GSS ili MDP specifikacija rezultat su ažuriranja drugih specifikacija koje imaju svoje FRD-ove.

Zahtjevi kompatibilnosti unatrag

Kompatibilnost unatrag za BR/EDR

Za BR/EDR rad, zahtjev kompatibilnosti unatrag definiran je kao međuoperacija s BR/EDR dijelom specifikacije Bluetooth Core v1.1 i novijim.

Povratna kompatibilnost za Bluetooth Low Energy

Za LE rad, zahtjev kompatibilnosti unatrag definiran je kao interoperacija s LE dijelom specifikacije Bluetooth Core v4.0 i novijim.

Kompatibilnost unatrag za specifikacije koje nisu osnovne specifikacije

Za specifikacije koje nisu Bluetooth Core Specification, kompatibilnost unatrag date verzije mora se održavati sa svim ranijim verzijama koje imaju isti glavni broj verzije. Za nprampda, verzija 1.3 mora biti kompatibilna sa verzijama 1.2, 1.1 i 1.0, ali verzija 2.0 možda neće biti kompatibilna sa verzijama 1.0, 1.1, 1.2 i 1.3. Imajte na umu da povećanje broja glavne verzije Osnovne specifikacije ne implicira nedostatak kompatibilnosti unatrag s prethodnim verzijama.

Izuzeće od zahtjeva za kompatibilnost unatrag

Radna grupa ili SG mogu predložiti da se određene funkcionalnosti izuzmu iz zahtjeva kompatibilnosti unatrag ako se pruži opravdanje. Za nprampda, ako se pokaže da funkcionalnost ima niske stope usvajanja na tržištu ili je, zbog problema interoperabilnosti, bolje ukloniti ili zamijeniti funkcionalnost nego mijenjati funkcionalnost. WG ili SG moraju uključiti sva izuzeća za kompatibilnost unatrag u FRD, koje odobrava BARB nakon odobrenja FRD-a. Sva izuzeća odobrena od strane BARB-a će biti predstavljena UO na odobrenje na 0.9/CR Stage.

3.4 Statut radne grupe

Kada BARB odobri FRD koji se predlaže da se dodijeli postojećoj RG, ta radna grupa mora pripremiti nacrt ažuriranja svog statuta kako bi dodala novu funkcionalnost u djelokrug (osim ako je Upravni odbor prethodno odobrio analizu RG da je ažuriranje statuta RG nije potrebno). Međutim, kada BARB odobri FRD koji se predlaže da se dodijeli novoj WG, BARB i članovi koji su zainteresirani za razvoj funkcionalnosti navedenih u FRD-u moraju pripremiti nacrt povelje za novu WG s novom funkcionalnošću uključenom u djelokrug povelje. .

Kada se pripremi nova ili ažurirana povelja RG, ona se mora dostaviti BARB-u na ponovno razmatranjeview i odobrenje. Kada BARB odobri povelju, nacrt nove ili ažurirane povelje RG biće dostavljen Upravnom odboru na odobrenje.

Kada Upravni odbor odobri povelju, radna grupa kojoj je UO dodijelio rad na razvoju specifikacije mora blisko sarađivati sa grupom koja je pripremila FRD u slučaju da su potrebna bilo kakva potrebna ažuriranja ili pojašnjenja tog FRD-a. Ako je potrebno ažuriranje FRD-a tokom faze razvoja, moraju se slijediti procesi navedeni u odjeljku 3.3 i ovom odjeljku; međutim, razvoj specifikacije može se odvijati paralelno sa ažuriranjem povelje FRD i WG.

3.5 Zahtjevi Zahtjevi za izlaz iz faze

Faza zahtjeva je završena, a faza razvoja počinje kada Upravni odbor potvrdi ili odobri povelju WG sa potrebnim djelokrugom za FRD i kada su ispunjeni sljedeći zahtjevi:

NWP je ili odobren od strane Odbora direktora, ili se Upravni odbor složio da je NWP nepotreban.

BARB je odobrio FRD i odgovarajuću povelju WG.

4. Faza razvoja

Tokom faze razvoja, dodijeljene radne grupe kreiraju novu specifikaciju i/ili poboljšavaju postojeću specifikaciju. FRD definira zahtjeve nove ili poboljšane Bluetooth specifikacije. U specifikaciji nije dozvoljena nikakva funkcionalnost koja nije razumno povezana sa zahtjevima u FRD-u. Cilj je stvoriti 0.9/CR specifikaciju koja je spremna za fazu validacije (opisanu u odjeljku 5) na kraju faze razvoja.
Tokom faze razvoja, specifikacija (ili poboljšanje specifikacije) napreduje kroz tri stages.

Za novu specifikaciju, tri stages su:

0.5 Stage
0.7 Stage

0.9 Stage

Za poboljšanje specifikacije, tri stages su:

Nacrt dokumenta prijedloga poboljšanja (DIPD) Stage

Dokument s konačnim prijedlogom poboljšanja (FIPD) Stage
Zahtjev za promjenu (CR) Stage

Svaka stage je dalje opisano u pododjeljcima koji slijede. Slika 4.1 u nastavku ilustruje različite dokumente koje će radna grupa pripremati u svakom trenutkutage.

Slika 4.1: Gotovoview specifikacije stages koji se javljaju tokom faze razvoja

Uloga BARB-a kroz proces razvoja specifikacije je da pruži radnim grupama savjete i tehničku pomoć. Radne grupe mogu, u bilo koje vrijeme, zatražiti od BARB-a tehnički savjet u vezi sa razvojem specifikacije i arhitektonskim konceptima koji će se koristiti u specifikaciji. Radne grupe se posebno ohrabruju da zatraže ranu povratnu informaciju od BARB-a za karakteristike koje imaju složenije arhitektonske aspekte.

4.1 0.5/DIPD Stage

Tokom 0.5/DIPD Stage, RG će razviti sljedeće koristeći zvanične šablone date u [8]:

Za novu specifikaciju, nacrt specifikacije 0.5, koji mora uključivati, u najmanju ruku, informacije o sljedećem:

Arhitektura koja pokriva zahtjeve kako je navedeno u FRD-u

Za protokole, definisane pristupne tačke servisa
Za usluge, izložene podatke i ponašanje
Za profesionalcefiles, identificirani protokoli i specificirana funkcionalnost

2. Za poboljšanje specifikacije, nacrt DIPD-a, koji mora uključivati, u najmanju ruku, informacije o sljedećem:

Pozadina: Obim posla, ciljevi koji usmjeravaju rad i kako se ovaj konkretni prijedlog uklapa u djelokrug
Gotovoview prijedloga: Sažetak proširene funkcionalnosti (dodata fleksibilnost, poboljšane performanse, itd.) koju pruža DIPD uključujući jasan opis u vezi s tim kako se nova funkcionalnost uklapa u trenutnu verziju specifikacije. Ako je radna grupa ocijenila više prijedloga, ovi prijedlozi bi trebali biti uključeni kako bi se BARB-u omogućila da utvrdi da li je učinjena dovoljna pažnja prilikom odabira željenog prijedloga.

Pokrivenost zahtjeva: Sažetak pokrivenosti funkcionalnih zahtjeva datih u prijedlogu, s referencom na odgovarajuće sistemske zahtjeve i scenarije upotrebe date u povezanom FRD-u
Definicija problema: Izjava o problemima riješenim prijedlogom(ima)
Kriterijumi odabira: Izjava u vezi sa kriterijumima odabira/izvođenja iz povezanih metrika evaluacije koje su vodile proces odabira

Opravdanje izbora: Ispitivanje metrike evaluacije koja opravdava izbor između prijedloga i otkriva kompromise
Opis: Opis funkcionalnosti i proširenih protokola. Ovaj odjeljak se može prilagoditi različitim potrebama dodavanjem relevantnih pododjeljaka.

3. Strategija testiranja: Opis funkcionalnosti koja se predlaže da se testira (ili nije testirana) kao dio Bluetooth kvalifikacionog programa i kako se funkcionalnost predlaže za testiranje (npr. očekivanja od nižeg ili višeg testera) i ako će se testovi pripisati kao testovi usklađenosti ili interoperabilnosti ili kao kombinacija oboje). Ovo može biti u posebnom dokumentu ili zasebnom odeljku unutar 0.5/DIPD specifikacije. Konvencije koje se koriste u strategiji testiranja opisane su u Strategiji testiranja i terminologijiview dokument (TSTO) [5].

Primarna publika dokumenata na ovom stage su članovi radne grupe i BARB koji review arhitektonske prijedloge i pokrivenost zahtjeva, te BTI koji reviews Strategija testiranja. U većini slučajeva, dokumenti kod ovog stage nisu namijenjeni da sadrže tekst koji je planiran za uključivanje u konačnu specifikaciju.

BSTS mora review sve dokumente radi konzistentnosti sa Bluetooth smjernicama za izradu nacrta [1] i identificirati probleme koje treba riješiti RG. BARB mora review specifikacija 0.5/DIPD. Za poboljšanje specifikacije, BARB također mora review DIPD za usklađenost sa zahtjevima kompatibilnosti unatrag opisanim u Odjeljku 3.3.2. BTI mora review strategija testiranja.

BARB mora ili odobriti ili odbiti specifikaciju 0.5/DIPD na osnovu svoje inženjerske procjene. Ako odobri BARB, specifikacija 0.5/DIPD će biti dostupna na Bluetooth SIG-u websajt svim pridruženim i promoterskim članovima, a obavještenje o njegovoj dostupnosti će biti izdato od strane BSTS-a. Na 0.5/DIPD Stage, nije potrebno odobrenje strategije testiranja.
0.5/DIPD Stage nije potrebno za poboljšanja CSS, GSS ili MDP specifikacija

0.5/DIPD Stage zahtjevi za izlaskom

0.5/DIPD Stage je kompletan i 0.7/FIPD Stage počinje kada su ispunjeni sljedeći uvjeti za izlazak:

BSTS je završio reviewu skladu sa specifikacijom 0.5/DIPD i strategijom testiranja.

BARB je odobrio specifikaciju 0.5/DIPD.
BTI je završio svoju review strategije testiranja.
BSTS je odobrio 0.5/DIPD specifikaciju učinio dostupnom svim pridruženim i promotorskim članovima.

4.2 0.7/FIPD Stage

Tokom 0.7/FIPD Stage, RG će razviti sljedeće koristeći zvanične šablone date u [8]:

Za novu specifikaciju, nacrt specifikacije 0.7, koji mora uključivati, u najmanju ruku, informacije o sljedećem:

Opis svih promjena koje su napravljene nakon što je BARB odobrio 0.5, uključujući nove ili izmijenjene prijedloge, kriterije odabira i opravdanje izbora. Promjene moraju biti opisane na istom nivou detalja kao što se zahtijeva u 0.5 Stage.

Svi funkcionalni zahtjevi iz FRD-a su adresirani.

2. Za poboljšanje specifikacije, nacrt FIPD-a, koji mora uključivati, u najmanju ruku, informacije o sljedećem:

Opis svih promjena koje su napravljene od DIPD-a koji je odobrio BARB, uključujući nove ili izmijenjene prijedloge, kriterije odabira i opravdanje izbora. Promjene moraju biti opisane na istom nivou detalja kao što se zahtijeva u DIPD Stage.

Po potrebi, dalje razvijene oblasti koje su opisane u Odjeljku 4.1 u vezi sa DIPD-om.
Završen opis poboljšanja.
Ažurirani arhitektonski opis.
Svi funkcionalni zahtjevi iz FRD-a su adresirani.

3. 0.7/FIPD ispitni dokumenti, koji moraju uključivati, u najmanju ruku, informacije o sljedećem:

Komplet za testiranje, koji se sastoji od liste svrha testiranja kako je opisano u TSTO [5].
Izjava o usklađenosti implementacije (ICS), kako je opisano u TSTO [5].

Za poboljšanja specifikacije, Test Suite i ICS se mogu isporučiti ili kao zasebni dokumenti ili kao dodatni odeljci u FIPD-u.

Primarna publika dokumenata proizvedenih na ovom stage su članovi radne grupe i BARB koji review potpuni opis funkcije ili poboljšanja uključujući neki tekst planiran za uključivanje u konačnu specifikaciju. BTI je publika za review ispitnih dokumenata.

BSTS će ponovoview nove ili promijenjene dijelove specifikacije 0.7/FIPD i ispitne dokumente za konzistentnost sa Bluetooth smjernicama za izradu nacrta, uključujući jezične konvencije koje je uspostavio Bluetooth SIG. BARB će ponovoview specifikacija 0.7/FIPD.

BSTS će pomoći radnoj grupi u pripremi dokumenata za testiranje 0.7/FIPD u skladu sa TSTO [5].

BTI mora review 0.7/FIPD test dokumenti. Radna grupa mora dostaviti specifikaciju 0.7/FIPD BTI-u kao referencu kada se review0.7/FIPD test dokumenata, koje će BTI review u skladu sa BTI specifikacijom Review Kontrolna lista procesa [6].

Nakon što je BARB završio svoj review specifikacije 0.7/FIPD i BTI je završio svoju review od 0.7/FIPD test dokumenata, BSTS će napraviti reviewed 0.7/FIPD specifikacija dostupna svim pridruženim i promotorskim članovima.

0.7/FIPD Stage nije potrebno za poboljšanja CSS, GSS ili MDP specifikacija.

0.7/FIPD Stage zahtjevi za izlaskom

0.7/FIPD Stage je kompletan i 0.9/CR Stage počinje kada su ispunjeni sljedeći uvjeti za izlazak:

BSTS je završio reviewu skladu sa specifikacijom 0.7/FIPD i dokumentima o ispitivanju.
BARB je završio reviewu skladu sa specifikacijom 0.7/FIPD.
BTI je završio reviewu 0.7/FIPD Test Suite (Svrha testa) i 0.7/FIPD ICS.
BSTS je napravio reviewed 0.7/FIPD specifikacija dostupna svim pridruženim i promotorskim članovima.

4.3 0.9/CR Stage

Postoje dvije vrste CR-a: Integrirani CR, koji je dokument praćen promjenama cijele usvojene specifikacije koji pokazuje sve promjene od prethodne verzije, i Skraćeni CR, koji je dokument koji pruža upute za modifikaciju samo pogođenih dijelova verzija specifikacije na kojoj se zasniva CR.

Tokom 0.9/CR Stage, RG će razviti sljedeće koristeći zvanične šablone date u [8]:

Za novu specifikaciju, kompletan nacrt specifikacije 0.9, koji mora uključivati, u najmanju ruku, informacije o sljedećem:

Opis svih promjena koje su napravljene od BARB-reviewed 0.7 specifikacija (ili od specifikacije 0.5 ako je proizvodnja specifikacije 0.7 odustala), uključujući nove ili
izmijenjeni prijedlozi, kriteriji odabira i opravdanost izbora. Promjene moraju biti opisane na istom nivou detalja kao što se zahtijeva u 0.5 Stage i 0.7 Stage.

2. Za poboljšanje specifikacije:

Ili Integrirani CR, koji mora uključivati, u najmanju ruku, informacije o sljedećem:
Opis svih promjena koje su napravljene od BARB-reviewizd. FIPD (ili od DIPD-a ako je FIPD ukinut) uključujući nove ili izmijenjene prijedloge, kriterije odabira i opravdanje izbora. Promjene moraju biti opisane na istom nivou detalja kao što se zahtijeva u DIPD Stage i FIPD Stage.
Sve promjene predložene u prethodno usvojenoj specifikaciji koristeći praćenje promjena.
Sve odobrene tehničke greške (sa svakim erratom referenciranim brojem greške), prikazane pomoću praćenja promjena, koje tek treba da budu ugrađene u prethodno usvojenu verziju specifikacije, i taj utjecajni tekst koji je povezan s poboljšanjem specifikacije; ili koji na drugi način utiču na IOP testiranje.

3. Ili skraćeni CR, koji mora uključivati, u najmanju ruku, informacije o sljedećem:

Opis svih promjena koje su napravljene od BARB-reviewizd. FIPD (ili od DIPD-a ako je FIPD ukinut) uključujući nove ili izmijenjene prijedloge, kriterije odabira i opravdanje izbora. Promjene moraju biti opisane na istom nivou detalja kao što se zahtijeva u DIPD Stage i FIPD Stage.
Sve izmjene predložene za svaki pogođeni odjeljak i paragraf specifikacije koji CR predlaže da se promijeni.
Sve odobrene tehničke greške (sa svakim erratom referenciranim brojem greške), prikazane korišćenjem oznaka, koje tek treba da budu ugrađene u prethodno usvojenu verziju specifikacije, i taj uticajni tekst koji je povezan sa poboljšanjem specifikacije; ili koji na drugi način utiču na IOP testiranje.

4. CSS CR (ako su novi unosi potrebni specifikacijom), koji može biti ugrađen u skraćeni CR specifikacije.
5. GSS CR (ako su novi unosi potrebni specifikacijom), koji može biti ugrađen u skraćeni CR specifikacije.
6. MDP CR (ako su novi unosi potrebni specifikacijom), koji može biti ugrađen u skraćeni CR specifikacije.
7. 0.9/CR ispitni dokumenti, koji moraju uključivati, u najmanju ruku, informacije o sljedećem koristeći službeni obrazac dat u [8]:

0.9/CR Test Suite, koji uključuje kompletne test slučajeve i pridruženu tabelu mapiranja test slučajeva (TCMT), kako je opisano u TSTO [5].
0.9/CR ICS, kako je opisano u TSTO [5].
Ako konfiguriranje testova zahtijeva specifične parametre za Implementation Under Test (IUT), 0.9/CR Implementation Extra Information for Testing (IXIT).
Referentna lista 0.9/CR test slučajeva (TCRL) (opcionalno za ažuriranja osnovnih specifikacija).

8. Analiza pokrivenosti testom koja pokazuje koji su zahtjevi specifikacije testirani ili nisu testirani u okviru 0.9/CR Test Suite (za poboljšanja specifikacija, analiza pokrivenosti testom treba uključiti samo nove dodane i ugrožene funkcionalnosti, a ne područja koja nisu pogođena originalnu specifikaciju).
9. Plan IOP testa.

Za poboljšanja specifikacije, Test Suite, ICS i IXIT se mogu dostaviti ili kao zasebni dokumenti ili kao dodatni odeljci u skraćenom CR-u.

U većini slučajeva, integrisani ili skraćeni CR bi trebalo da se zasniva na prethodno usvojenoj verziji specifikacije, ali takođe može biti zasnovan na poslednjem međunacrtu. Najnovija verzija srednjeg nacrta specifikacije mora biti broj verzije povezan s verzijom dokumenta koja je zamrznuta i koja se neće mijenjati tokom vremena. U suprotnom, dodatne identifikacione informacije (kao što su datum dokumenta i a URL na stalnu lokaciju) moraju biti dostavljeni kako bi se identificirala specifična "osnovna" verzija. Ako se koristi međunacrt, sve promjene koje se ne odnose direktno na CR unutar datog odjeljka koji CR mijenja moraju biti uključene, ali se ne zahtijevaju da budu prikazane pomoću oznaka. Ako se relevantni dijelovi međunacrta kasnije ažuriraju, CR se mora ažurirati kako bi odražavao ažuriranja međunacrta.

U idealnom slučaju, skraćeni CR materijal se integriše u nacrt kompletne specifikacije i kompletne ispitne dokumente pre faze validacije, ali se takođe mogu integrisati na početku faze validacije. Ako se više funkcija razvija za specifikaciju (npr. jezgra specifikacija), možda bi bilo poželjno integrirati karakteristike u jedan nacrt nakon što je IOP testiranje završeno.

BSTS će ponovoview specifikacija 0.9/CR i dokumenti za testiranje u skladu sa Bluetooth smjernicama za izradu nacrta. Onda će BARB ponovoview specifikacija 0.9/CR, a kasnije je slijedi plan IOP testa (kao što je opisano u odjeljku 4.3.1). Nakon što WG dostavi specifikaciju 0.9/CR BARB-u za review, BSTS će ga učiniti dostupnim svim članovima za review i obavijestiti sve članove o njegovoj dostupnosti. Od ove tačke nadalje u procesu razvoja specifikacije, BSTS će učiniti nacrte specifikacije dostavljenim BARB-u dostupnim svim članovima uz periodične obavijesti svim članovima.

Za poboljšanje specifikacije, RG će preporučiti Upravnom odboru da li prethodne verzije specifikacije treba da budu zastarele ili povučene, uključujući tehničke razloge za preporuku(e).

BARB će ponovoview analiza WG-a o usklađenosti specifikacije 0.9/CR sa zahtjevima datim u FRD-u, svim potencijalnim sigurnosnim problemima, svim regulatornim problemima, usklađenosti s Bluetooth arhitekturom i, radi poboljšanja specifikacije, usklađenosti sa zahtjevima kompatibilnosti unatrag opisanim u odjeljku 3.3.2. .XNUMX. Ako BARB identificira potencijalne sigurnosne probleme, BARB će obavijestiti BSTS za review i koordinacija sa Stručnom grupom za sigurnost; i ako BARB identifikuje bilo kakve regulatorne implikacije, BARB će obavijestiti BSTS da review i koordinira sa Regulatornim komitetom i pravnim savetnikom Bluetooth SIG-a. BARB mora ili odobriti ili odbiti specifikaciju 0.9/CR na osnovu svog inženjerskog prosuđivanja i razmatranja faktora opisanih u ovom paragrafu.

BTI će ponovoview 0.9/CR test dokumenti uzimajući u obzir analizu pokrivenosti testom. BTI mora ili odobriti ili odbiti 0.9/CR dokumente o testiranju.

Nakon što BARB odobri specifikaciju 0.9/CR, radna grupa dostavlja plan IOP testa BARB-u na ponovnuview.

Specifikacija 0.9/CR koju je odobrila BARB predstavlja se Upravnom odboru kako bi odobrio početak IOP testiranja i objavljivanje specifikacije 0.9/CR svim članovima.

Da bi istakle potencijalna pravna pitanja, radne grupe mogu zatražiti specifikaciju review od strane pravnog zastupnika Bluetooth SIG-a (pravni review) prije obaveznog pravnog review odvija se tokom faze usvajanja/odobrenja. Međutim, za poboljšanja specifikacija, zakonski review treba uraditi na Integrisanom CR-u (za razliku od skraćenog CR-a) i to treba unaprijed zakazati što je više moguće kako bi resursi bili dostupni.

Plan IOP testa

Radna grupa će razviti pisani plan IOP testa koji mora zadovoljiti sve dolje definirane zahtjeve za korištenje tokom faze validacije na događajima IOP testa. Radne grupe moraju dostaviti plan IOP testa BARB-u za review prije početka IOP test događaja. Za jednostavna poboljšanja specifikacije (posebno ona koja ne zahtijevaju modifikaciju ili dodavanje testnih slučajeva u Test Suite), IOP testiranje možda neće biti potrebno, a WG može podnijeti zahtjev BARB-u za odustajanje od IOP testiranja korištenjem definiranog procesa u odjeljku 4.4.

Plan IOP testa mora uključivati:

Testirajte slučajeve da provjerite sve nove obavezne, opcione i uslovne karakteristike
Najmanje jedan test slučaj za svaki operacijski kod
Najmanje jedan test slučaj za svaki parametar
Najmanje jedan test slučaj za svaki tip paketa
Slučajevi za testiranje kompatibilnosti unatrag za poboljšanja specifikacije tako da su ispunjeni zahtjevi navedeni u Odjeljku 3.3.2 za svu poboljšanu funkcionalnost (takođe pogledajte odjeljak 4.3.1.1).
Testni slučajevi u kojima je IUT izložen vrijednostima izvan definiranih raspona ili aspektima ponašanja koji se smatraju nevažećim ili neočekivanim (testni slučajevi nevažećih ponašanja). Imajte na umu da se očekuje da će tester kao što je PTS ili drugi alat za testiranje biti inicijator nevaljanog ponašanja.
Bilo koji privremeni dodijeljeni brojevi (odabrani u koordinaciji sa BSTS-om kako bi se izbjeglo preklapanje u nadolazećim događajima IOP testa) koji će se koristiti u događaju IOP testa, kao što je opisano u Odjeljku 4.3.1.2.
Identifikacija potrebnog broja nezavisnih implementacija koje moraju proći svaki test slučaj, uzimajući u obzir zahtjeve pokrivenosti opisane u odjeljku 4.3.1.3
Identifikacija svih test slučajeva u Test Suiteu za koje RG smatra da treba da budu isključeni i opravdanje za njihovo isključenje. Oni obično uključuju: • Test slučajeve budućeg provjere (npr. uobičajeni testovi tako da se mogu smjestiti mogući budući dodaci, kao što su dodatne karakteristike, proširene karakteristike ili korištenje bitova ili polja rezerviranih za buduću upotrebu (RFU))
• Test slučajevi koji su podskup drugih uključenih testova
• Generički testni slučajevi koji su praktički identični testovima koji se izvode za nekoliko drugih specifikacija (npr. pokretanje uobičajenih kodova grešaka)
• Testni slučajevi sa istom svrhom testiranja kao i testni slučajevi koji prolaze preko drugog transporta (npr. BR/EDR test slučaj koji je sličan LE test slučaju)
• Robustnost ili testiranje na stres implementacije

Plan IOP testa također može uključivati testove koji su jedinstveni za IOP testiranje, kao što su end-to-end testni slučajevi koji spajaju složenije sekvence koje mogu nalikovati tipičnom korisničkom scenariju.

Iako BARB odobrenje plana IOP testa nije potrebno (pod razumijevanjem da će plan IOP testa nastaviti da se mijenja i poboljšava sa svakim događajem IOP testa), potrebno je odobrenje BARB izvještaja o IOP testu (pogledajte odjeljak 5.1.1) . Ako plan IOP testa ne zadovoljava sve zahtjeve definirane u Odjeljku 4.3.1, WG bi trebala BARB-u predstaviti sažetak svih poznatih varijansi i obrazloženje za svaku varijansu prije početka događaja IOP testa.

Plan testiranja IOP-a i testni slučajevi bi se prvenstveno trebali zasnivati na sadržaju u dokumentima za testiranje pridružene specifikacije.

Da bi događaji testiranja IOP-a bili efikasni, RG bi trebala imati plan IOP testa i sve povezane testne slučajeve dovršene i dostupne implementatorima, idealno najmanje mjesec dana prije prvog IOP testnog događaja.

Planiranje testiranja kompatibilnosti unatrag
Za poboljšanja specifikacije, IOP testiranje kompatibilnosti unatrag mora uzeti u obzir verifikaciju u odnosu na sve aktivne i zastarjele verzije specifikacije jer one specifikacije i funkcionalnost koje se obično nalaze u Bluetooth proizvodima mogu imati vrlo dug životni vijek (npr. vozila). Radna grupa mora analizirati odgovarajući nivo potrebnog testiranja kompatibilnosti unatrag (ako postoji) uključujući koje verzije treba testirati i testove koje treba izvesti, te dostaviti ovu analizu BARB-u. BARB mora review analizu i preporučiti izmjene (ako ih ima) za radnu grupu da ih ugradi u plan IOP testa.

Članovi koji učestvuju u testiranju kompatibilnosti unatrag ohrabruju se da donesu stare uređaje koji su bili kvalifikovani prema prethodnim verzijama specifikacije. Radna grupa mora prijaviti sve greške u kompatibilnosti unatrag u izvještaju o IOP testu. Kompanije članice se također ohrabruju da izvedu testiranje kompatibilnosti unatrag u vlastitim laboratorijama izvan lokacije događaja IOP testa i da prijave bilo kakve probleme vezane za specifikaciju RG.

Privremeni dodijeljeni brojevi koji se koriste u IOP testiranju
BSTS i BARB se moraju konsultovati kako bi koordinirali privremenu dodjelu dodijeljenih brojeva koji će se koristiti na IOP test događaju tako da nema preklapanja ili sukoba s drugim specifikacijama. Ove privremene vrijednosti moraju biti uključene u plan testiranja IOP-a i neće biti dodijeljene za upotrebu u bilo kojoj usvojenoj specifikaciji.

Za IOP testiranje gdje se predlaže jedna ili više novih 16-bitnih UUID vrijednosti, vrijednosti unutar raspona od 0x7F00 do 0x7FFF su rezervirane za IOP testiranje.

Za IOP testiranje gdje se predlaže jedna ili više novih vrijednosti multipleksera usluge fiksnog protokola (PSM), koristit će se vrijednosti koje počinju od kraja važećeg raspona od 0x0000 do 0x007F, kako je navedeno u specifikaciji jezgre.

Zahtjevi za pokrivenost
Radna grupa mora pružiti dokaz BARB-u da je potreban broj (kao što je opisano u odjeljcima koji slijede) nezavisnih implementacija prošao svaki test slučaj. Svaki zahtjev WG za iznimke od potrebnog broja nezavisnih implementacija mora biti naveden u planu testiranja IOP-a koji se dostavlja BARB-u.

Implementacije se smatraju nezavisnim jedna od druge sve dok su svi dijelovi koji su relevantni za validaciju razvijeni nezavisno, tj. od strane različitih timova (koji ne dolaze nužno iz različitih kompanija). BSTS može pomoći u procjeni da li se prototipovi mogu smatrati nezavisnim jedan od drugog kako bi se očuvala anonimnost i povjerljivost detalja implementacije.

Imajte na umu da se alati za testiranje, uključujući PTS, ne smatraju nezavisnim implementacijama.

Zahtjevi za pokrivenost IOP-a osnovne specifikacije
Funkcija osnovne specifikacije obično definira jednu ili više uloga gdje je svaka uloga dizajnirana da radi s jednom ili više drugih uloga ili eventualno sa samom sobom.

Za svaki par uloga koje su dizajnirane da međusobno djeluju, najmanje tri nezavisne implementacije svake uloge moraju biti prikazane da interoperiraju s tri nezavisne implementacije komplementarne uloge.

Za svaku ulogu koja može interoperirati s drugim uređajem u istoj ulozi, najmanje tri nezavisne implementacije te uloge moraju pokazati da mogu komunicirati jedna s drugom u toj ulozi.

Zahtjevi za pokrivenost IOP specifikacije usluge
Najmanje tri nezavisne implementacije usluge moraju pokazati da interoperiraju s najmanje jednom implementacijom klijenta, što može biti PTS.

Profile i specifikacija protokola IOP zahtjevi pokrivenosti
Profile i specifikacije protokola obično definiraju jednu ili više uloga gdje je svaka uloga dizajnirana da interoperira s jednom ili više drugih uloga, ili eventualno sa samom sobom.

Za svaki par uloga koje su dizajnirane da međusobno djeluju, najmanje dvije nezavisne implementacije svake uloge moraju pokazati da interoperiraju s dvije nezavisne implementacije komplementarne uloge.

Za svaku ulogu koja može interoperirati s drugim uređajem u istoj ulozi, najmanje tri nezavisne implementacije te uloge moraju pokazati da međusobno djeluju u toj ulozi.

Zahtjevi za IOP pokrivenošću specifikacije modela
Najmanje tri nezavisne implementacije modela servera ili kontrolnog modela moraju pokazati da interoperiraju s najmanje jednom implementacijom klijenta (koja može biti PTS), a najmanje jedna implementacija klijentskog modela mora pokazati da interoperira s najmanje jednom implementacijom modela servera i PTS-om.

Numeracija verzija specifikacije

Tokom 0.9/CR Stage, RG mora pripremiti preporuku koju treba predstaviti Upravnom odboru u vezi sa brojem verzije koja će se primijeniti na specifikaciju kada bude usvojena.

Verzije specifikacija dijele se na dvije vrste: pune verzije izdanja, koje uključuju nove ili ažurirane značajke, i verzije izdanja za održavanje (također poznate kao "dot-Z verzije"), koje integriraju tehničke i uredničke greške, ali ne uključuju nove ili ažurirane karakteristike. Pune verzije izdanja imaju dvodijelne brojeve u obliku XY, kao što su 2.1 ili 5.0, dok verzije izdanja za održavanje imaju trodijelne brojeve u obliku XYZ, kao što je 2.1.2. Vrijednost Z ne može biti 0.

Za bilo koje dvije verzije, jedna se naziva “viša verzija”, a druga je “niža verzija”. Ovo se određuje prema sljedećim pravilima:

Ako se X komponente razlikuju, ona s višom X vrijednošću je “viša verzija”.
Ako su X komponente iste, ali se Y komponente razlikuju, ona s višom Y vrijednošću je “viša verzija”.
Ako su XY komponente iste, ali se Z komponente razlikuju, ona sa višom Z vrijednošću je “viša verzija”. Dvodijelni broj XY se, u tu svrhu, tretira kao trodijelni broj XY0.

Za nprampSledeći brojevi verzija bi bili redom od najniže do najviše verzije: 1.4, 2.0, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.2. Za CSS, svako ažuriranje povećava samo X komponentu broja verzije.

Preduslovi za odobrenje OD
Na kraju faze razvoja specifikacije, sljedeći zahtjevi moraju biti ispunjeni prije nego što se specifikacija 0.9/CR dostavi Upravnom odboru na odobrenje:

Radna grupa je završila analizu pokrivenosti testom.
BSTS je završio reviewu skladu sa specifikacijom 0.9/CR i dokumentima o ispitivanju.
BARB je odobrio specifikaciju 0.9/CR.
BARB je odobrio CSS CR (ako su novi unosi potrebni specifikacijom) koji se može ugraditi u Skraćeni CR specifikacije.
BARB je odobrio GSS CR i MDP CR (ako su novi unosi potrebni prema specifikaciji).
BTI je odobrio 0.9/CR Test Suite, ICS i TCRL, zajedno sa IXIT (pod uslovom da je IXIT potreban za izvođenje testova u Test Suite). TCRL je opciona u ovom stage za ažuriranja osnovne specifikacije.
Radna grupa je BARB-u dostavila plan ispitivanja IOP-a za review (ako BARB ne odustane od testiranja).

Dokumenti koji se podnose Upravnom odboru moraju uključivati specifikaciju 0.9/CR koju je odobrila BARB i prezentaciju UO koja mora uključivati:

Svi poznati zahtjevi za odustajanje od IOP testiranja ili bilo koji od zahtjeva definiranih u Odjeljku 4.3.1
Spisak transporta koje specifikacija podržava (npr. BR/EDR, LE itd.)
Za poboljšanje specifikacije, sva izuzeća od zahtjeva za kompatibilnost unatrag (opisanih u Odjeljku 3.3.2) koje zahtijeva RG
Za poboljšanje specifikacije, preporuka radne grupe da se broj verzije primjenjuje na usvojenu specifikaciju
Za poboljšanje specifikacije, preporuka WG-a na kraju životnog vijeka za prethodnu verziju(e) usvojene specifikacije, uključujući sve tehničke razloge zbog kojih se preporučuje ili ne preporučuje odbacivanje ili povlačenje bilo koje prethodne verzije specifikacije, i opravdanje za preporuku
Sve neriješene ozbiljne zabrinutosti članova BARB-a ili BTI-ja (npr. razlozi za bilo koje glasove protiv tokom odobrenja, zabrinutosti koje proizlaze iz ponovnogview ispitnih dokumenata ili zabrinutost da je specifikacija 0.9/CR izvan opsega FRD-a ili povelje)
Status pripreme Profile Tuning Suite (PTS) ili drugi neophodni alati povezani sa usvajanjem koje priprema BSTS

Upravni odbor može odlučiti da odobri specifikaciju 0.9/CR za ispitivanje IOP-a kako se zahtijeva Statutom [2], prije nego što BTI odobri dokumente o testiranju 0.9/CR i prije nego što WG potvrdi da plan testiranja IOP-a ispunjava zahtjeve definisane u Odjeljku 4.3.1. 0.9. Upravni odbor također može uslovljavati svoje odobrenje specifikacije 0.9/CR za ispitivanje IOP-a odobrenjem BTI dokumenata o testu XNUMX/CR.

0.9/CR Stage zahtjevi za izlaskom
0.9/CR Stage je završena i faza validacije počinje kada Upravni odbor odobri početak IOP testiranja.

4.4 Odricanja od procesa razvoja specifikacije

Radna grupa može zatražiti odustajanje od jednog ili više od sljedećih koraka procesa:

0.5/DIPD Stage
0.7/FIPD Stage
IOP testiranje u fazi validacije

Da bi zatražila odricanje, radna grupa mora koristiti obrazac za odricanje od procesa koji pruža Bluetooth SIG [8] i podnijeti zahtjev za odricanje svakom odboru (tj. BARB ili BTI) koji je dužan daview ili odobriti nacrt specifikacije ili povezane ispitne dokumente na stage da RG predlaže da se odustane, a svaki od tih odbora mora odobriti zahtjev za izuzeće.

Zahtjev za odricanje mora sadržavati sljedeće:

Identifikacija stage(e) kojih se RG želi odreći
Obrazloženje zašto stage(e) treba odustati
Identifikacija svake komisije (tj. BTI i/ili BARB) koja je potrebna da se review i odobri zahtjev za odustajanje

Komisija koja razmatra izuzeće može zahtijevati da predstavnik radne grupe napravi prezentaciju kako bi opravdao odustajanje od procesa SMPD prije odlučivanja o zahtjevu za izuzeće.

Ako odustajanje zahtijeva odricanje od više koraka i dio odricanja bude odbijen, a dio odobren, odgovor komisije mora naznačiti koji koraci u zahtjevu za izuzeće su odobreni, a koji odbijeni. Ako je zahtjev za odricanje odbijen, obavještenje o odbijanju mora sadržavati razloge za odbijanje.

5. Faza validacije

Tokom faze validacije, RG će izvršiti IOP testiranje na specifikaciji 0.9/CR sa ciljem da dostavi izvještaj o IOP testu za BARB review i odobrenje. Kad god je to moguće, IOP testiranje poboljšanja specifikacije trebalo bi se provesti u odnosu na integrirani nacrt specifikacije. Osim toga, član Review, kako je propisano Statutom [2], počinje u ovoj fazi.

Ako specifikacija (ili poboljšanje) ne zahtijeva IOP testiranje, tada se IOP testiranje unutar faze provjere može odustati korištenjem procesa opisanog u odjeljku 4.4.

Tokom trajanja IOP testiranja (što može biti jedan ili više događaja), radna grupa bi trebala pratiti probleme koristeći Bluetooth SIG sistem za praćenje problema i ponavljati kako bi uključila ažuriranja u nacrt specifikacije, dokumente za testiranje i plan testiranja IOP-a. Kada se IOP testiranje završi, radna grupa mora dovršiti ažuriranje nacrta specifikacije i dokumentacije o ispitivanju kako bi riješila sva pitanja, te pripremiti i podnijeti izvještaj o IOP testu BARB-u za ponovnuview i odobrenje. Ovo je ilustrovano na slici 5.1.

Tokom faze validacije postoji nekoliko aktivnosti koje mogu započeti. Ove aktivnosti se mogu odvijati paralelno i uključuju sljedeće:

Odobrenu 0.9/CR specifikaciju BSTS stavlja na raspolaganje svim članovima uz obavještenje o početku Člana Review period propisan Statutom.
Sva potrebna ažuriranja su ugrađena u CSS (koji može biti ugrađen u skraćeni CR specifikacije).
Definicije karakteristika ili deskriptora su ugrađene u GSS specifikaciju, kao i PTS za IOP testiranje.
Definicije svojstava mreže su ugrađene u MDP specifikaciju kao i PTS za IOP testiranje.
BSTS omogućava registraciju IOP platforme i alat za unos rezultata u pripremi za IOP testiranje.
Ispitivanje IOP-a, ako je potrebno (pogledajte odjeljak 5.1).
Review komentari i problemi, uključujući i one dostavljene kao rezultat IOP testiranja, se obrađuju i promjene su uključene u nacrt specifikacije.

5.1 IOP testiranje

Primarni cilj IOP testiranja je validacija specifikacije, nprample, provjera tačnosti i dvosmislenosti u tekstu, reviewotkrivanje bilo kakvih fundamentalnih grešaka i propusta u dizajnu i pružanje validacije u odnosu na prethodno utvrđene zahtjeve razvijene ranije u procesu razvoja specifikacije. IOP testiranje može rezultirati promjenama u nacrtu specifikacije i višestruki događaji IOP testa mogu biti potrebni da se dovrše sva potrebna testiranja.

Važno je dati članovima izvan radne grupe priliku da učestvuju u testiranju IOP-a jer oni pružaju nezavisno view specifikacije i može otkriti područja nejasnoća u specifikaciji koja možda neće biti očigledna članovima radne grupe koji su izradili nacrt. Prije svakog IOP testnog događaja, BSTS će staviti na raspolaganje detalje događaja, najnoviji nacrt specifikacije, Test Suite i IOP plan testiranja i obavijestit će sve članove idealno mjesec dana prije svakog događaja. Ažurirani nacrt specifikacije, Test Suite i IOP plan testiranja koji se koriste na IOP test događaju trebaju biti dostupni najmanje jednu sedmicu prije svakog događaja.

Tokom IOP testiranja, kombinacije platformi u paru će pokušati da izvrše testove, a učesnici IOP testiranja će zabilježiti prolaz/neuspjeh rezultata svakog testa i komentare. Anonimizirani sažetak ovih rezultata (koji se odnosi na npr. „Platforma A“, „Platforma B“ itd.) i svi komentari biće prikupljeni tokom IOP testnih događaja i dostupni članovima Radne grupe tokom i nakon IOP-a test događaj. U slučaju da su potrebne dodatne informacije za bolje razumijevanje bilo kakvih komentara ili grešaka koji su se dogodili tokom IOP testiranja, BSTS može djelovati kao posrednik u prikupljanju dodatnih informacija od člana koji podnosi.

Ako je moguće, PTS bi trebao biti ažuriran kako bi podržao IOP testiranje sa platformama na svim slojevima iznad Host Controller Interface (HCI) i bio prisutan na IOP test događajima za te slojeve. Drugi alati za testiranje također mogu biti prisutni na IOP test događajima. Sažetak rezultata testiranja sa PTS-om ili drugim alatima za testiranje (ako ih ima) treba uključiti u izvještaj o IOP testu.

IOP testiranje će biti otvoreno za sve članove koji žele da pruže implementaciju prototipa, međutim, Bluetooth SIG može uslovljavati učešće prihvatanjem ugovora sa Bluetooth SIG (uključujući ugovore o učešću i poverljivosti). Radna grupa je odgovorna za obradu i rješavanje problema otkrivenih tokom IOP testiranja i ažuriranje zahvaćenih dokumenata; Promjene koje je odobrila WG moraju biti uključene kao ažuriranja nacrta specifikacije i testnih dokumenata za korištenje na svakom IOP test događaju.

Prije faze validacije, radne grupe mogu izvršiti preliminarno testiranje IOP-a na događajima koji su otvoreni samo za članove RG, međutim rezultati neformalnog testiranja možda neće biti uključeni u rezultate IOP testa.

Može se dogoditi da se prate svi koraci koji vode do prvog IOP testnog događaja, uključujući najavljeni IOP datum i lokaciju s namjerom da se započne IOP testiranje, ali odobrenje BO nije osigurano prije početka testnog događaja. U ovom slučaju, UO može ovlastiti uključivanje rezultata testa koji su prikupljeni prije odobrenja Odbora direktora za početak IOP testiranja, pod uslovom da su prikupljeni rezultati zasnovani na istoj specifikaciji i test paketu koji je odobrio UO.

IOP testiranje nije potrebno za poboljšanja CSS, GSS ili MDP specifikacija.

Izvještaj o IOP testu
Nakon što je IOP testiranje završeno, RG mora dostaviti izvještaj o IOP testu BARB-u s ciljem da pokaže da je potreban broj nezavisnih platformi prošao potrebne testove. BARB mora review i odobri ili odbije izvještaj o testiranju IOP-a i obavijestiće RG ako je potrebno dodatno testiranje IOP-a prije podnošenja paketa specifikacije za glasanje Upravnom odboru. BSTS i WG moraju osigurati da se u izvještaju o testiranju IOP-a ne pojavi nikakva informacija koja identifikuje članove prije podnošenja izvještaja BARB-u.

Izvještaj o IOP testu mora uključivati:

Lista svih IOP test događaja koji su se dogodili tijekom faze provjere uključujući njihove datume i lokacije.
Broj kompanija članica i nezavisnih platformi koje su učestvovale na svakom IOP događaju uključujući i da li je PTS korišten.
Lista verzija specifikacije, testnog paketa i plana IOP testa korištenih na svakom događaju.
Izvršni sažetak u kojem se navodi da li su svi testni slučajevi ispunili minimalne kriterije za prolaz.
Sažetak svih odstupanja od zahtjeva IOP plana testiranja definiranih u odjeljku 4.3.1 i obrazloženje za svaku varijaciju.
Sažetak pokrivenosti PTS-a za testne slučajeve u Test Suiteu.
Spisak svih test slučajeva (uključujući testove kompatibilnosti unatrag) iz IOP plana testiranja, broj prolaznih testova, broj neuspjeha testa i da li su ispunjeni minimalni kriteriji po testnom slučaju, uključujući objašnjenje zašto neki zahtjevi nisu ispunjeni met.
Sažetak problema, komentara i pitanja na svakom događaju (uključujući one filed u odnosu na specifikaciju tokom IOP testiranja) i uticaj na specifikaciju i ispitne dokumente.

5.2 Zahtjevi za izlaz iz faze validacije

Faza validacije je završena i faza odobrenja/usvajanja počinje kada BARB odobri izvještaj o IOP testu (osim ako BARB nije odustao od testiranja) i svi sljedeći zahtjevi su ispunjeni:

BSTS je stavio odobrenu 0.9/CR specifikaciju na raspolaganje svim članovima za Member Review kako je propisano Statutom i obavijestio sve članove o njegovoj dostupnosti.
Svi problemi koji su identifikovani tokom IOP testiranja, a koji imaju uticaj na testiranje, uključeni su i testirani.
WG je završio IOP testiranje (osim ako BARB nije odustao od testiranja).

6. Faza usvajanja/odobrenja

Tokom faze usvajanja/odobravanja, specifikacija i povezani dokumenti za ispitivanje su finalizirani, BARB, BQRB i BTI odobrenje je primljeno, obavještenje o predloženom datumu usvajanja se izdaje zajedno sa konačnom verzijom nacrta specifikacije koja se dostavlja Upravnom odboru na usvajanje ( Nacrt za glasanje), a konačni paket specifikacija se dostavlja UO. Nakon minimalnog trajanja člana Review zahtevana Statutom [2]) je zadovoljen, Upravni odbor će razmotriti specifikaciju za usvajanje na Datum usvajanja. Nakon usvajanja, objavljuje se specifikacija i omogućava kvalifikacioni sistem. Faza usvajanja/odobravanja je ilustrovana na slici 6.1.

6.1 Nacrt glasanja

Nacrt za glasanje se kreira uključivanjem ažuriranja (dostavljenih u fazi validacije) u potrebne dokumente specifikacije i pripremom konačnog nacrta nove specifikacije. Za poboljšanja specifikacije, BSTS će kreirati integrisanu specifikaciju integracijom jednog ili više CR-a u prethodno usvojenu višu verziju specifikacije (pogledajte odeljak 4.3.2) ako već nije završena pre Faze validacije.

Ako se tijekom ove faze naprave promjene u specifikaciji i WG, BARB ili BTI utvrdi da bilo koja promjena zahtijeva dodatno testiranje IOP-a, specifikacija će se vratiti na dio testiranja IOP-a u fazi validacije za WG da izvrši dodatne testove. Tokom faze usvajanja/odobrenja, sljedeća dokumenta će biti kompletirana i stavljena na raspolaganje Upravnom odboru prije Datuma usvajanja:

Nacrt za glasanje
Sve prateće specifikacije (tj. CSS, GSS, MDP) prema potrebi za relevantni tip specifikacije (ili poboljšanja), ako nisu prethodno usvojene
Za poboljšanja specifikacije, verzija usvojene verzije specifikacije praćena promjenama koja pokazuje promjene predložene u nacrtu za glasanje
Opis svih zahtjeva za kompatibilnost unatrag (kao što je opisano u odjeljku 3.3.2) koji nisu ispunjeni od strane WG i opravdanje za bilo kakva izuzeća
Opis od strane radne grupe svih zahtjeva plana IOP testa (kao što je opisano u Odjeljku 4.3.1) koji nisu ispunjeni i opravdanje za sva odstupanja zajedno sa izvještajem o IOP testu (koji se može obezbijediti pružanjem veze do kopije na Bluetooth SIG websajt)
Preporuka radne grupe za ukidanje ili povlačenje bilo koje prethodne verzije usvojene specifikacije zajedno s obrazloženjem, naglašavajući promjene od 0.9/CR Stage preporuka na kraju životnog vijeka
Sažetak, koji je pripremila WG, promjena karakteristika ili funkcionalnosti od 0.9/CR specifikacije (ako postoji)
Sažetak, koji je pripremio BARB, zabrinutosti članova BARB-a da je specifikacija koju je izradila radna grupa izvan opsega povelje koju je odobrio UO (ako postoji)
Spisak preostalih neriješenih pravnih pitanja iz pravnog review (ako postoji)
Testni paket koji je odobrio BTI, zajedno sa rezimeom pokrivenosti testom specifikacije nacrta za glasanje koji je odobrila WG. U slučaju novododate ili izmijenjene funkcionalnosti bez pokrivenosti testom, potrebno je pismeno obrazloženje za propust
ICS i IXIT odobren od BTI (ako se zahtijeva specifikacijom)
TCRL su odobrili i BTI i BQRB
Izvještaj koji je pripremio BSTS zajedno sa BTI-om u vezi sa statusom spremnosti alata (npr. PTS i drugi alati za testiranje, Bluetooth Launch Studio) uključujući slučajeve ako neki testni slučajevi u TCRL-u nisu podržani od strane testnih alata
Sažetak, koji je pripremila RG, svih potrebnih dodijeljenih brojeva
Kontrolna lista za usvajanje koju su pripremili BSTS i RG koja pokazuje da su svi rezultati u ovom dijelu završeni
Sve ostale informacije koje zahteva OD

Tokom faze usvajanja/odobravanja, radna grupa treba da koristi Bluetooth SIG-ov sistem za praćenje problema kako bi uhvatila probleme i komentare u odnosu na nacrt specifikacije i testne dokumente tako da se oni uzmu u obzir u finalizaciji Nacrta specifikacije za glasanje. Za poboljšanje specifikacije, sve relevantne odobrene greške (tj. one odobrene greške koje još nisu integrisane) moraju biti ugrađene i moraju biti identifikovane korišćenjem praćenih promena.

Radna grupa mora dostaviti konačni nacrt specifikacije BSTS-u na pravnu revizijuview. Za nove specifikacije, pravni review sadržavat će cijelu specifikaciju. Za poboljšanja specifikacija, review će se prvenstveno fokusirati na izmijenjene dijelove specifikacije. Svrha pravnog review je prvenstveno da se identifikuju pravni rizici koje bi radna grupa trebala razmotriti i nastojati da ih riješi. Pravne povratne informacije bit će kategorizirane na osnovu ozbiljnosti. Ako fakultativni pravni review izvedena je na 0.9/CR Stage, verzija koja se podnosi na pravnu review mora prikazati, kao praćene promjene, sve promjene koje su napravljene od te verzije (generirane od strane WG ili BSTS). Po završetku pravnog review, WG i BSTS će se dogovoriti oko povratnih informacija koje će biti uključene u nacrt specifikacije. Ako postoje neriješeni pravni komentari iz pravnog review u vezi sa nacrtom specifikacije, predsedavajući RG može zatražiti vreme na dnevnom redu OD da bi se dogovorili oko rezolucije.

Paralelno sa pravnim review, RG mora dostaviti nacrt specifikacije BARB-u za review. Nakon početnog podnošenja BARB-u, BSTS će obavijestiti sve članove da je nacrt specifikacije dostavljen BARB-u na ponovnuview i da je dostupan i za člana Review. Ako radna grupa podnese ažuriranja nacrta specifikacije za BARB re-review, BSTS će slati dodatna obavještenja svim članovima na periodičnoj osnovi.

Po završetku BARB review, RG i BARB će se dogovoriti oko povratnih informacija koje će biti uključene u nacrt specifikacije.

Ako zakonski review rezultira bilo kakvim suštinskim promjenama, dodatnim review od strane BARB-a može biti potrebno. Slično, ako BARB review rezultira bilo kakvim suštinskim promjenama, BSTS će utvrditi da li postoji dodatni pravni review tih promjena je potrebno. Po završetku pravnog review i BARB review, BARB mora ili odobriti ili odbiti Nacrt za glasanje.

Ako bilo koji dokument za testiranje zahtijeva ažuriranje, BSTS će pomoći radnoj grupi u ažuriranju testnih dokumenata. BTI mora ili odobriti ili odbiti ispitne dokumente. Ako ga BTI odobri, BTI će pomoći u finalizaciji TCRL-a i dostaviti ovaj dokument BQRB-u zajedno sa povezanim ICS-om, IXIT-om i paketom za testiranje. BSTS će procijeniti datum sastanka Odbora direktora kada UO namjerava da glasa o usvajanju Nacrta za glasanje (Datum usvajanja) i dostaviti ga BTI za korištenje u TCRL. BARB odobrenje specifikacije, BTI odobrenje svih testnih dokumenata (uključujući Test Suite, TCRL, ICS i IXIT) i BQRB odobrenje TCRL-a moraju se desiti na ili prije Datuma usvajanja.

BSTS će obavijestiti sve članove o finalizaciji i dostupnosti nacrta za glasanje i datuma usvajanja. Datum usvajanja neće biti određen prije 60 dana nakon što su članovi obaviješteni o specifikaciji 0.9/CR koju je odobrio UO, osim ako član neview period skraćuje Upravni odbor u skladu sa Statutom, a najmanje 14 dana nakon obavještenja o Datumu usvajanja dostavlja se članovima u skladu sa Statutom. Za slučajeve u kojima je više CR integrisano u nacrt za glasanje, početak Review je datum kada su članovi bili obaviješteni o najnovijoj CR koju je odobrio UO.

Nakon što se članovima dostavi obavještenje o Datumu usvajanja, dozvoljene su ispravke tipografskih grešaka u Nacrtu za glasanje koje je odobrio UO. Vremenski okvir usvajanja specifikacije ilustrovan je na slici 6.2.

6.2 Dodijeljeni brojevi

Bluetooth SIG održava javno dostupan skup dodeljenih brojeva na Bluetooth SIG dodeljenim brojevima weblokacija [7]. Ovi dodijeljeni brojevi su grupirani u različitim brojčanim prostorima (povezani skup brojeva bez duplikata). Dodijeljeni brojevi mogu se preklapati s drugim dodijeljenim brojevima u različitim brojčanim prostorima, ali nije dozvoljeno ponovno korištenje broja unutar brojčanog prostora. Različiti razmaci brojeva definirani su u specifikaciji koja definira upotrebu dodijeljenih brojeva.

Nakon što BARB odobri izvještaj o ispitivanju IOP-a, RG će podnijeti zahtjev BARB-u za dodjelu novih brojeva unutar brojevnog prostora(a) koji se zahtijevaju prema konačnoj specifikaciji. BARB će ponovoview zahtjev i rad sa BSTS-om na određivanju dodijeljenih brojeva. Nakon odobrenja BARB-a, BSTS će zakazati objavljivanje dodijeljenih brojeva koje će biti javno dostupno na Bluetooth SIG dodijeljenim brojevima weblokacija [7] u roku od jedne sedmice od usvajanja specifikacije.

Nakon objave dodijeljenih brojeva na Bluetooth SIG-u dodijeljeni brojevi webna lokaciji ili unutar usvojene specifikacije, dodijeljeni brojevi su namijenjeni da budu nepromjenjivi (da se ne mijenjaju ni u vrijednosti ni značenju). Ako iz nekog razloga postanu neupotrebljivi, postaju rezervirane vrijednosti i nije ih dozvoljeno ponovno koristiti.

6.3 Zahtjevi za izlazak iz faze usvajanja/odobrenja

Faza odobrenja/usvajanja je završena kada Upravni odbor usvoji specifikaciju i kada se završe sljedeće aktivnosti nakon usvajanja:

BSTS je konačno dodijeljene brojeve učinio javno dostupnim na Bluetooth SIG-u website.
BSTS je usvojenu specifikaciju učinio javno dostupnom na Bluetooth SIG-u website
BSTS je svu prateću dokumentaciju (npr. CSS, GSS, MDP) potrebnu za relevantnu specifikaciju učinio javno dostupnim na Bluetooth SIG website.
BSTS je stavio pridružene testne dokumente na raspolaganje svim članovima na Bluetooth SIG-u website.
Za poboljšanja specifikacija, BSTS je napravio informativnu verziju prethodno usvojene verzije specifikacije s praćenjem promjena sa svim promjenama koje je unela novousvojena verzija i učinio je dostupnom svim članovima na Bluetooth SIG-u. website.
BSTS je omogućio sistem kvalifikacija.
BSTS je obavijestio sve članove o dostupnosti usvojene specifikacije i svih pratećih dokumenata.

Bluetooth SIG planira da završi ove aktivnosti nakon usvajanja u roku od nedelju dana nakon usvajanja specifikacije.

7. Faza održavanja specifikacije

Faza održavanja specifikacije počinje nakon što se završi faza usvajanja/odobrenja. Ako se pronađu problemi (npr. nejasnoće u tekstu ili tehničke greške) sa specifikacijom ili povezanim dokumentima za testiranje, oni moraju biti dokumentirani kreiranjem prijedloga grešaka pomoću alata Bluetooth SIG Errata. Prijedlozi s greškom u specifikaciji bit će obrađeni, kategorizirani i odobreni prema EPD [3]. Greške testnog paketa se obrađuju i kategoriziraju prema TSTO [5]. Ako postoje sukobi između SMPD-a i EPD-a ili TSTO-a, SMPD ima prednost.

Greška u specifikaciji se mora koristiti samo za ispravljanje tehničkih ili urednički grešaka u konačno usvojenim Bluetooth specifikacijama. Dodavanje, promjene i uklanjanje funkcionalnosti mogu se izvršiti samo putem procesa poboljšanja specifikacije definiranog ranije u ovom dokumentu.

7.1 Ubrzani proces ispravke

Kada se greška odobri u skladu sa procesom definisanim u EPD [3], WG, BARB ili BSTS mogu preporučiti da se smatra hitnim i treba ga ubrzati. Kada se to dogodi, BSTS zajedno sa WG ili BARB će predstaviti preporuku Upravnom odboru. Upravni odbor će odlučiti da li da prihvati ili odbije preporuku. Ako se preporuka prihvati, BSTS će odmah uključiti odobrenu grešku u obrazac greške [8] i raditi sa odgovornom WG na finalizaciji ubrzane ispravke grešaka koja će se dostaviti RG na ponovnuview i odobrenje.

Gotovoview ubrzanog procesa erratum ilustrovan je na slici 7.1.

Sljedeći dokumenti moraju biti popunjeni i stavljeni na raspolaganje Upravnom odboru prije Datuma usvajanja:

Nacrt Ubrzane ispravke grešaka koji je odobrio BARB.
Opis svih zahtjeva za kompatibilnost unatrag (kao što je opisano u Odjeljku 3.3.2) koji nisu ispunjeni od strane WG i opravdanje za bilo kakva izuzeća.
Spisak preostalih neriješenih pravnih pitanja iz pravnog review (ako ih ima).
Test Suite, ICS i IXIT koji je odobrio BTI (ako to zahtijeva greška).
TCRL odobren od BTI-a i BQRB-a (ako se zahtijeva greškom).
Izvještaj koji je kompletirao BSTS zajedno sa BTI-om u vezi sa statusom spremnosti alata (npr. PTS i drugi alati za testiranje, Bluetooth Launch Studio) uključujući i to ako neki testni slučajevi u TCRL-u nisu podržani od alata za testiranje i objašnjenje (ako to zahtijeva greška ).
Kontrolna lista usvajanja koju su popunili BSTS i RG koja pokazuje da su svi rezultati u ovom odeljku završeni.
Sve ostale informacije koje zahteva OD.

BSTS će raditi sa odgovornom RG na finalizaciji nacrta ubrzane ispravke grešaka i kreiranju verzije koju će dostaviti nadležnoj RG za ponovnoview i odobrenje.

Radna grupa mora dostaviti Ubrzanu ispravku grešaka BSTS-u na pravni postupakview. Po završetku pravnog review, WG i BSTS će se složiti oko povratnih informacija koje će biti uključene u Ubrzanu ispravku grešaka. Ako postoje neriješeni pravni komentari iz pravnog review u vezi sa ubrzanom ispravkom grešaka, predsjedavajući RG može zatražiti vrijeme na dnevnom redu OD kako bi zatražio doprinos OD za rješavanje.

Paralelno sa pravnim review, RG mora dostaviti ubrzanu ispravku grešaka BARB-u za review. Kada se ubrzana ispravka grešaka dostavi BARB-u, BSTS će je učiniti dostupnim svim članovima da ponovoview i obavijestiti sve članove o njegovoj dostupnosti. Po završetku BARB review, WG i BARB će se složiti oko povratnih informacija koje će biti uključene u Ubrzanu ispravku grešaka.

Ako bilo koji dokument za testiranje zahtijeva ažuriranje, BSTS će pomoći radnoj grupi u ažuriranju testnih dokumenata. Nakon što BTI odobri testne dokumente, BTI će pomoći u finaliziranju TCRL-a i dostaviti dokument BQRB-u zajedno sa pripadajućim ICS-om, IXIT-om i test paketom prema potrebi. BSTS će procijeniti datum usvajanja i dostaviti ga BTI za korištenje u TCRL-u. BARB odobrenje za ubrzanu ispravku grešaka, BTI odobrenje svih testnih dokumenata (uključujući Test Suite, TCRL, ICS i IXIT prema potrebi) i BQRB odobrenje TCRL-a mora se desiti na ili prije Datuma usvajanja.

BSTS će obavijestiti sve članove o finalizaciji i dostupnosti ubrzane ispravke grešaka i predloženog datuma usvajanja. Datum usvajanja će biti određen i obavješten svim članovima u skladu sa Statutom [2], a datum usvajanja će biti najmanje 14 dana nakon što je obavještenje dostavljeno članovima. Nakon što se članovima dostavi obavještenje o predloženom datumu usvajanja, UO može odobriti ispravke tipografskih grešaka u ubrzanoj ispravci grešaka bez davanja dodatnog obavještenja o predloženom datumu usvajanja i čekanja potrebnih 14 dana.

Bluetooth SIG će usvojenu ubrzanu ispravku grešaka učiniti javno dostupnim i planira to učiniti u roku od jedne sedmice nakon usvajanja. Obavijest o njenoj dostupnosti će BSTS izdati svim članovima.

Proces ubrzane ispravke grešaka je završen kada Upravni odbor usvoji ubrzanu ispravku grešaka i kada su završene sljedeće aktivnosti nakon usvajanja:

BSTS je učinio usvojenu Ubrzanu ispravku grešaka i povezane dokumente o testiranju (ako to zahtijeva erratum) javno dostupnim na Bluetooth SIG-u website.
BSTS je omogućio kvalifikacioni sistem (ako to zahteva greška).
BSTS je obavijestio sve članove o dostupnosti usvojene ubrzane ispravke grešaka.

Po završetku ovih aktivnosti, ispravka greške će biti planirana za integraciju u pogođene specifikacije ili kao dio planiranog poboljšanja specifikacije ili u nadolazećem izdanju za održavanje kao što je opisano u Odjeljku 7.2.

7.2 Proces oslobađanja za održavanje (.Z specifikacije)

Na približno godišnjem nivou, BSTS će utvrditi da li postoje odobrene greške (koje se nazivaju ispravci grešaka) koje su klasifikovane kao tehničke/visoke ili tehničke/kritične i koje tek treba da budu uključene u tekst bilo koje aktivne specifikacije (tj. usvojena specifikacija koja nije zastarjela ili povučena). Vidi Dodatak A za definicije klasifikacije grešaka. Vlasnik specifikacije (ili WG ovlašten za održavanje specifikacije, ili BARB ako nijedna WG nije ovlaštena za održavanje specifikacije) također može zatražiti ranije izdanje za održavanje aktivne specifikacije u koju će uključiti sve odobrene greške. Nakon određivanja BSTS-a ili zahtjeva vlasnika specifikacije, proces izdavanja održavanja će započeti.

Gotovoview procesa oslobađanja za održavanje ilustrovan je u Error! Izvor reference nije pronađen.

Na početku procesa objavljivanja održavanja, BSTS zajedno sa vlasnikom specifikacije, BARB-om i BTI-om će razviti i predstaviti plan Odboru direktora za uključivanje ispravki grešaka u objavljenu verziju specifikacije. Predloženi plan mora naznačiti da li će ispravke grešaka biti uključene u izdanje za održavanje specifikacije (tj. .Z verzija) ili poboljšanje specifikacije koje je već u toku (tj. XY verzija). Predloženi plan treba da uzme u obzir da li su dodane nove obavezne karakteristike između verzija usvojenih specifikacija, procijenjeno vrijeme kada se sljedeće poboljšanje specifikacije planira za usvajanje i druge faktore.

Nakon odobrenja plana od strane Odbora direktora, BSTS zajedno sa Vlasnikom specifikacije će nastaviti da inkorporira sve tehničke/srednje, tehničke/visoke i tehničke/kritične ispravke grešaka u nacrt specifikacije koji se naziva “Nacrt izdanja za održavanje”. Za uredničke ili tehničke/niske ispravke grešaka, ako se ispravka greške odnosi na više od jedne verzije specifikacije, BSTS će, osim ako Upravni odbor ne naznači drugačije, integrirati te greške samo u najnoviju višu verziju specifikacije pri sljedećem ažuriranju te verzije . Nikakve promjene ne mogu biti uključene u nacrt izdanja za održavanje osim uključivanja ispravki grešaka. Svaki nacrt izdanja za održavanje mora identificirati sve ugrađene ispravke grešaka koristeći praćenje promjena kako bi se prikazale predložene izmjene prethodno usvojene verzije objavljene specifikacije.

Vrijeme predloženog uključivanja za svaku ispravku greške u nacrtu izdanja za održavanje ovisit će o utjecaju testnog paketa: sve ispravke grešaka koje nemaju utjecaj testnog paketa mogu se odmah uključiti, ali ispravke grešaka koje utiču na test paket će biti obrađeno tako da se vrijeme poklopi s ažuriranjem TCRL-a.

BTI i BSTS će odrediti rok za uključivanje ispravki grešaka sa uticajem testnog paketa u nacrt izdanja za održavanje. Ovaj rok je obično 3 do 6 mjeseci prije planiranog datuma odobrenja sljedećeg većeg TCRL izdanja. Ispravke grešaka sa uticajem testnog paketa koje propuste rok za uključivanje bit će obrađene kao dio sljedećeg godišnjeg TCRL izdanja. Stoga, osim ako se ne zatraži ranije izdanje, maksimalno vrijeme za uključivanje tehničkih/visokih ili tehničkih/kritičnih ispravki grešaka u ažuriranje specifikacije je otprilike 15 do 18 mjeseci.

Vlasnik specifikacije mora dostaviti nacrt izdanja za održavanje koji je odobrio kao konačan za pravnu revizijuview. Pravni review će se prvenstveno fokusirati na izmijenjene dijelove specifikacije. Po završetku pravnog review, Vlasnik specifikacije i BSTS će se složiti oko povratnih informacija koje će biti uključene u nacrt izdanja za održavanje. Ako postoje neriješeni pravni komentari iz pravnog review na nacrtu izdanja za održavanje, Vlasnik specifikacije može zatražiti vrijeme na dnevnom redu Odbora direktora kako bi zatražio doprinos OD za rješavanje.

Paralelno sa pravnim review, vlasnik specifikacije mora dostaviti nacrt izdanja za održavanje BARB-u na ponovnoview. Kada se nacrt izdanja za održavanje podnese BARB-u, BSTS će ga učiniti dostupnim svim članovima da ponovoview i obavijestiti sve članove o njegovoj dostupnosti. Po završetku BARB review, Vlasnik specifikacije i BARB će se dogovoriti oko povratnih informacija koje će biti uključene u nacrt specifikacije.

Za ispravke grešaka koje utiču na testne dokumente i gde će odgovarajuće greške testa biti obrađene na vreme za nadolazeće TCRL izdanje, BSTS će raditi sa vlasnikom specifikacije i BTI na ažuriranju testnih dokumenata. Nakon što BTI odobri ispitne dokumente, BSTS će procijeniti datum usvajanja i dati predloženi datum usvajanja BTI-ju za korištenje u TCRL-u. BTI će isporučiti TCRL BQRB-u zajedno sa povezanim ICS-om, IXIT-om i paketom za testiranje prema potrebi. BARB odobrenje specifikacije, BTI odobrenje svih testnih dokumenata (uključujući Test Suite, TCRL, ICS i IXIT prema potrebi) i BQRB odobrenje TCRL-a moraju se desiti na ili prije Datuma usvajanja.

BSTS će obavijestiti sve članove o finalizaciji i dostupnosti nacrta za glasanje i predloženog datuma usvajanja. Datum usvajanja će biti određen i obavješten svim članovima u skladu sa Statutom, a datum usvajanja će biti najmanje 14 dana nakon što je obavještenje dostavljeno članovima. Nakon što se članovima dostavi obavještenje o predloženom Datumu usvajanja, UO može odobriti ispravke štamparskih grešaka u Nacrtu za glasanje bez davanja dodatnog obavještenja o predloženom Datumu usvajanja i čekanja potrebnih 14 dana.

Sljedeći dokumenti moraju biti popunjeni i stavljeni na raspolaganje Upravnom odboru prije Datuma usvajanja:

Nacrt za glasanje
Verzija nacrta za glasanje praćena promjenama koja prikazuje sve promjene usvojene verzije specifikacije koja ima istu XY vrijednost (npr. ako je nacrt za glasanje predložen kao verzija 1.4.2, promjene će se pratiti u odnosu na 1.4.1 verzija specifikacije)
Preporuku vlasnika specifikacije za zastarelost ili povlačenje bilo koje prethodne verzije usvojene specifikacije zajedno sa obrazloženjem
Spisak preostalih neriješenih pravnih pitanja iz pravnog review (ako postoji)
Test Suite, ICS i IXIT odobren od BTI-a (ako se zahtijeva izdanjem za održavanje)
TCRL odobren od BTI i BQRB (ako se zahtijeva izdanjem za održavanje)
Izvještaj koji je kompletirao BSTS zajedno sa BTI-om u vezi sa statusom spremnosti alata (npr. PTS i drugi alati za testiranje, Bluetooth Launch Studio) uključujući sve testne slučajeve u TCRL-u koji nisu podržani od alata za testiranje, i objašnjenje (ako to zahtijeva održavanje pustiti)
Kontrolna lista za usvajanje koju su popunili BSTS i vlasnik specifikacije koja pokazuje da su svi rezultati u ovom odjeljku završeni
Sve ostale informacije koje zahteva OD

Proces oslobađanja od održavanja je završen kada Upravni odbor usvoji Nacrt za glasanje i kada se završe sljedeće aktivnosti nakon usvajanja:

BSTS je učinio usvojenu specifikaciju i povezane dokumente o testiranju (ako je to zahtijevano izdanjem za održavanje) javno dostupnim na Bluetooth SIG website.
BSTS je napravio informativnu verziju prethodno usvojene verzije specifikacije sa praćenjem promjena sa svim promjenama uključenim u novousvojenu verziju dostupne svim članovima na Bluetooth SIG-u website.
BSTS je omogućio sistem kvalifikacija.
BSTS je obavijestio sve članove o dostupnosti usvojene specifikacije i prateće dokumentacije.

Bluetooth SIG planira da završi ove aktivnosti nakon usvajanja u roku od nedelju dana nakon usvajanja specifikacije.

Po završetku ovih aktivnosti, specifikacija ostaje u fazi održavanja specifikacije sve dok specifikacija ne bude zastarjela ili povučena, kako je definirano u Odjeljku 8.

8. Faza završetka specifikacije

Specifikacije mogu biti zastarjele ili povučene kada su zamijenjene novijim verzijama, ako se utvrdi da su tehnički nedovoljne ili iz drugih razloga. Zastarjele i povučene specifikacije se arhiviraju i više se ne ažuriraju. Zastarjele i povučene specifikacije se različito tretiraju u Bluetooth kvalifikacionom programu.

Svaki član, grupa ili komitet može BSTS-u dostaviti preporuke za odbacivanje ili povlačenje specifikacije zajedno sa pridruženim vremenskim okvirom (putem e-pošte na

specification.manager@bluetooth.com) u bilo koje vrijeme. BSTS takođe može preporučiti zastarelost ili povlačenje specifikacije i povezanog vremenskog okvira. BSTS će uputiti preporuku BARB-u i grupi ili komisiji odgovornoj za održavanje specifikacije za review i povratne informacije.

BARB i odgovorna grupa ili komisija će procijeniti preporuke za odbacivanje ili povlačenje specifikacije i razmotriti sljedeće (nepotpune) kriterije:

Postoji li funkcionalnost u prethodnoj verziji specifikacije koja je zastarjela ili se ne bi trebala koristiti?
Je li nova obavezna funkcionalnost dodana kasnijim verzijama?
Postoje li nedostaci u ranijim verzijama koji narušavaju rad ili interoperabilnost koji su ispravljeni u kasnijim verzijama i koji su potrebni za unapređenje postojećih korisničkih scenarija?
Da li je u kasnijim verzijama potrebna dodatna funkcionalnost za unapređenje novih korisničkih scenarija?
Postoji li poboljšana upotrebljivost i interoperabilnost u kasnijim verzijama?
Postoje li sigurnosna poboljšanja u kasnijim verzijama?

BARB i odgovorna grupa ili komisija mogu predložiti alternativnu preporuku.

Nakon što dobije povratnu informaciju od BARB-a ili grupe ili komisije odgovorne za održavanje specifikacije, BSTS će dostaviti preporuku(e) i povratne informacije Upravnom odboru na razmatranje. Upravni odbor može pozvati grupu ili komisiju koja je odgovorna za održavanje navedenih specifikacija da se sastanu i razgovaraju o preporukama. Upravni odbor će razmotriti preporuke i povratne informacije i može se složiti sa ili izmijeniti prijedlog. Upravni odbor će zahtijevati da BSTS obavijesti sve članove o prijedlozima za odbacivanje ili povlačenje specifikacije i povezanih vremenskih rokova za ponovno od 30 dana.view period da omogući svim članovima da daju dodatne povratne informacije prije donošenja konačne odluke.

Upravni odbor će razmotriti povratne informacije primljene od članova. Kada Upravni odbor odobri zastarelost ili povlačenje specifikacije, BSTS će obavijestiti sve članove o odluci i povezanom vremenskom okviru.

8.1 Zastarjelost

Kada se specifikacija zastari, dogodit će se sljedeće:

Specifikacija se više neće ažurirati.
Odgovorna radna grupa će review sve izvanredne greške napisane protiv zastarjele specifikacije kako bi se utvrdilo da li se primjenjuju na druge specifikacije. Greške mogu biti odbijene u sistemu grešaka i prepisane u odnosu na primenljivu(e) specifikaciju(e).
WG ili BSTS će kreirati greške da ažuriraju sve potrebne reference na zastarjele specifikacije u drugim specifikacijama.
BTI će ažurirati primjenjive ispitne dokumente kako bi ukazao na zastarjelost specifikacije.
BSTS će ažurirati Bluetooth SIG websajt sa uputstvima u vezi sa alternativnim specifikacijama za upotrebu.
Nove greške se više ne mogu podnijeti u odnosu na zastarjelu specifikaciju.
Specifikacija se neće spominjati u budućim specifikacijama.
BSTS će arhivirati verziju specifikacije označenu kao zastarjelu kako bi joj članovi mogli pristupiti u historijske svrhe.

8.2 Povlačenje

Kada se specifikacija povuče, pored koraka koji se primjenjuju na zastarjelost, dogodit će se sljedeće:

BTI će ažurirati primjenjive ispitne dokumente kako bi ukazao na povlačenje specifikacije.
BSTS će ažurirati Bluetooth SIG websajt sa uputstvima u vezi sa alternativnim specifikacijama za upotrebu.
BSTS će arhivirati verziju specifikacije označenu kao povučenu kako bi joj članovi mogli pristupiti u istorijske svrhe.

Upravni odbor može odlučiti da odmah povuče specifikaciju bez prethodnog odbacivanja specifikacije.

9. Proces bijelog papira

Bijele knjige su kreirane samo u informativne svrhe. Sljedeći proces bijele knjige primjenjuje se na sve Bluetooth radne grupe, EG, SG i komitete. Ovaj odjeljak se ne odnosi na informativne dokumente koji se koriste samo unutar Bluetooth SIG-a.

Ovaj proces je ilustrovan na slici 9.1 ispod.

Prije nego što bilo koja grupa ili komitet započne rad na bijeloj knjizi koju namjerava objaviti Bluetooth SIG, grupa ili komitet će pripremiti i predloženo ažuriranje povelje koje jasno definiše predloženi sadržaj bijele knjige i prezentaciju prijedloga bijele knjige.

Prezentacija prijedloga bijele knjige mora sadržavati najmanje:

Potreba za bijelim papirom
Sažetak predloženog sadržaja bijele knjige
Objašnjenje zašto se sadržaj ne preporučuje da bude uključen kao dio specifikacije
Predviđena publika
Svi planovi održavanja (tj. procijenjeno vrijeme prije sljedećeg izdanja ove bijele knjige može biti potrebno)
Preporuke za rukovanje prethodnim verzijama bijelog papira, ako ih ima (npr. arhiviranje)

Ažuriranje povelje i prezentacija prijedloga bijele knjige moraju se podnijeti za BARB review. Nakon review i odobrenje ažuriranja povelje od strane BARB-a, BSTS će dostaviti ažuriranu povelju Upravnom odboru na odobrenje zajedno sa pratećom prezentacijom predloga bele knjige.

Ako Upravni odbor odobri ažuriranje povelje, grupa ili komisija mogu nastaviti sa izradom bijele knjige.

Kada grupa ili komitet završi izradu bele knjige, BSTS će izvršiti uredničkiview radi usklađenosti sa Bluetooth smjernicama za izradu nacrta.

Nakon rješavanja komentara BSTS-a, grupa mora podnijeti bijelu knjigu BSTS-u na pravnu revizijuview. Po završetku pravnog review, grupa i BSTS će se dogovoriti oko povratnih informacija koje će biti uključene u bijelu knjigu. Ako postoje neriješeni pravni komentari iz pravnog review na bijelom papiru, predsjedavajući grupe može zatražiti vrijeme na dnevnom redu Odbora direktora kako bi zatražio doprinos UO o rješavanju.

Paralelno sa pravnim review, grupa mora dostaviti bijelu knjigu BARB-u za review. Kao dio njihovog review, BARB može preporučiti da li bilo koji dio bijelog papira treba ukloniti iz bijelog papira i uključiti ga u specifikaciju slijedeći proces u Odjeljku 3. BARB također može odlučiti da podnese bijelu knjigu drugim grupama ili odborima za ponovnoview. Po završetku BARB review, grupa i BARB će se dogovoriti oko povratnih informacija koje će biti uključene u bijelu knjigu.

Nakon što BARB odobri bijelu knjigu, autorska grupa ili komisija će predstaviti bijelu knjigu koju je BARB odobrio Upravnom odboru na odobrenje.

Proces bijele knjige je završen kada Upravni odbor odobri bijelu knjigu i kada se završe sljedeće aktivnosti nakon odobrenja:

BSTS je odobreni bijeli papir učinio javno dostupnim na Bluetooth SIG-u website.
BSTS obavještava sve članove o odobrenoj bijeloj knjizi.
Ako je bela knjiga poboljšanje postojeće bele knjige, BSTS će arhivirati verziju bele knjige kojoj članovi mogu da pristupe u istorijske svrhe.

Bluetooth SIG planira da završi aktivnosti nakon odobrenja u roku od nedelju dana nakon odobrenja bele knjige.

10. Reference

Referentni Bluetooth dokumenti dostupni su preko Bluetooth-a website http://www.bluetooth.com.

Bluetooth smjernice za izradu (dostupno na stranici Predlošci i dokumenti radne grupe, na https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Statut Bluetooth SIG, Inc. (dostupan na stranici Upravljački dokumenti, na https://www.bluetooth.com/membership-working-groups/membership-types-levels/membership-agreements)
Dokument o grešci u Bluetooth specifikaciji (dostupan na stranici Predlošci i dokumenti radne grupe, na https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Dokument procesa radne grupe (dostupan na stranici Predlošci i dokumenti radne grupe, na https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Testna strategija i terminologija gotoviview dokument (dostupan na stranici Zahtevi za kvalifikacioni test, na https://www.bluetooth.com/specifications/qualification-test-requirements)
BTI specifikacija Review Kontrolna lista procesa (dostupna na stranici Predlošci i dokumenti radne grupe, na https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Bluetooth SIG dodijeljeni brojevi (https://www.bluetooth.com/specifications/assigned-numbers)
Predlošci i dokumenti radne grupe (dostupni na stranici Šabloni i dokumenti radne grupe, na https://www.bluetooth.com/membership-working-groups/working-groups/working-group-templates-documents)
Dodatak GATT specifikaciji (GSS) (dostupno na stranici sa GATT specifikacijama, na https://www.bluetooth.com/specifications/gatt)
Pošaljite ideju za novu specifikaciju https://www.bluetooth.com/specifications/submit-an-idea-for-a-specification

11. Akronimi i kratice

Tabela A: Akronimi i kratice

Dodatak A – Klasifikacija ozbiljnosti greške

Ovaj dodatak sumira smjernice za klasifikaciju ozbiljnosti za grešku u specifikaciji. Ova tabela će biti dodata budućoj reviziji EPD-a, a zatim će ovaj odjeljak biti obrisan.

Pročitajte više o ovom priručniku i preuzmite PDF:

Dokument procesa upravljanja specifikacijama (SMPD) – Optimizirani PDF
Dokument procesa upravljanja specifikacijama (SMPD) – Originalni PDF

Imate li pitanja o vašem priručniku? Objavite u komentarima!

Reference

Uputstvo za upotrebu