Дакумент працэсу кіравання спецыфікацыямі (SMPD)

Дакумент працэсу Bluetooth®

• Перагляд: V27
• Дата перагляду: 2019-05-17
•  Адрас электроннай пошты для зваротнай сувязі: BARB-feedback@bluetooth.org

Анатацыя:
Гэты дакумент вызначае працэсы распрацоўкі для стварэння і паляпшэння спецыфікацый Bluetooth і афіцыйных дакументаў.

Гісторыя версій

Удзельнікі апошняй версіі

Гэты дакумент, незалежна ад яго назвы або зместу, не з'яўляецца спецыфікацыяй Bluetooth, на якую распаўсюджваюцца ліцэнзіі, выдадзеныя Bluetooth SIG Inc. ("Bluetooth SIG") і яе членамі ў адпаведнасці з Ліцэнзійным пагадненнем аб патэнце/аўтарскім праве Bluetooth і Ліцэнзійным пагадненнем аб гандлі Bluetooth.

ГЭТЫ ДАКУМЕНТ ПРАДСТАЎЛЯЕЦЦА "ЯК ЁСЦЬ", І BLUETOOTH SIG, ЯЕ ЧЛЕНЫ І ІХ АФІЛІІРАВАННІ НЕ РОБЯЦЬ НІЯКІХ ЗАЯЎ АБО ГАРАНТЫЙ І АДМОВАЛЯЮЦЦА АД УСІХ ГАРАНТЫЙ, ЯВНЫХ АБО РАЗРАЗУЕМЫХ, УКЛЮЧАЮЧЫ ЛЮБЫЯ ГАРАНТЫІ КАМЕНДЖНАЙ ПРЫГОДНАСЦІ, ПРАВА ПРАВА, НЕПАРУШЭННЯ, ПРЫГОДНАСЦІ ДЛЯ ЛЮБЫХ КАНКРЭТНЫХ МЭТ, ШТО ЗМЕСТ ГЭТАГА ДАКУМЕНТА БЕЗ ПАМЫЛАК.

У МЕРЫ, НЕ ЗАБАРОНЕНАЙ ЗАКОНАМ, BLUETOOTH SIG, ЯЕ ЧЛЕНЫ І ІХ ФІЛІЯЛЫ АДМОВАЛЯЮЦЦА АД УСЯКАЙ АДКАЗНАСЦІ, ЯКІЯ ВЫНІКАЮЦЬ З ВЫКАРЫСТАННЯ ГЭТАГА ДАКУМЕНТА І ЛЮБОЙ ІНФАРМАЦЫІ, ЯКАЙ ЗМЕШЧАЕЦЦА Ў ГЭТЫМ ДАКУМЕНЦЕ, УКЛЮЧАЮЧЫ СТРАТУ ДАХОДУ, ПРЫБЫТКУ, ДАДЗЕНЫХ АБО ПРАГРАМ, АБО БІЗНЕС ПЕРЫВАННЕ АБО ЗА СПЕЦЫЯЛЬНЫЯ, Ускосныя, ускосныя, ВЫПАДКОВЫЯ АБО ШТРАФНЫЯ ШКОДЫ, НЕЗАЛЕЖНА АД ТЭОРЫІ АДКАЗНАСЦІ, І НАВАТ КАЛІ BLUETOOTH SIG, ЯЕ ЧЛЕНАМ АБО ІХ ФІЛІЯЛАМ БЫЛІ ПАВЕДАМЛЕНЫ АБ МАГЧЫМАСЦІ ТАКОГА ШКОДУ.

Гэты дакумент з'яўляецца ўласнасцю Bluetooth SIG. Гэты дакумент можа ўтрымліваць або ахопліваць прадмет, які з'яўляецца інтэлектуальнай уласнасцю Bluetooth SIG і яго членаў. Размяшчэнне гэтага дакумента не дае ліцэнзіі на любую інтэлектуальную ўласнасць Bluetooth SIG або яе членаў.

Гэты дакумент можа быць зменены без папярэдняга паведамлення.

Аўтарскія правы © 2004–2019 Bluetooth SIG, Inc. Марка і лагатыпы Bluetooth належаць Bluetooth SIG, Inc. Іншыя брэнды і назвы іншых вытворцаў з'яўляюцца ўласнасцю адпаведных уладальнікаў.

 

1. Уводзіны

Дакумент працэсу кіравання спецыфікацыямі (SMPD) апісвае працэсы, якія аўтары спецыфікацый і паўторнаviewЯны павінны прытрымлівацца для распрацоўкі новых спецыфікацый і ўдасканалення існуючых спецыфікацый (напрыклад, для дадання або выдалення функцыянальных магчымасцей або змены пэўных функцыянальных магчымасцей у прынятай спецыфікацыі), для падтрымання прынятых спецыфікацый і для кіравання заканчэннем тэрміну службы прынятых спецыфікацый. Акрамя таго, гэты дакумент апісвае працэс стварэння, паўторнаviewі зацвярджэнне белых дакументаў.

Існуюць адрозненні ў працэсе распрацоўкі спецыфікацый паміж распрацоўкай новых спецыфікацый і ўдасканаленнем існуючых спецыфікацый з-за неад'емных адрозненняў у аб'ёме гэтых задач; гэтыя адрозненні вылучаны ў гэтым дакуменце.

Працэс распрацоўкі спецыфікацыі ўключае:

• Этап патрабаванняў (апісаны ў раздзеле 3) для вызначэння функцыянальных патрабаванняў
• Этап распрацоўкі (апісаны ў раздзеле 4) для распрацоўкі і пераўтварэнняview спецыфікацыі
• Этап праверкі (апісаны ў Раздзеле 5) для праверкі спецыфікацый з дапамогай тэсціравання сумяшчальнага прататыпа (IOP).
• Этап прыняцця/зацвярджэння (апісаны ў раздзеле 6), каб прадставіць спецыфікацыі Савету дырэктараў Bluetooth SIG (BoD) для прыняцця/зацвярджэння

Дакумент "Працэс выпраўленняў спецыфікацый" (EPD) [3] апісвае працэс прапановы і паўторнага выкарыстанняviewпошук выпраўленняў спецыфікацый і зацвярджэнне іх у якасці выпраўленняў выпраўленняў (як вызначана ў Статуце [2]) да прынятых спецыфікацый. Калі не пазначана іншае, усе спасылкі на памылкі ў гэтым SMPD азначаюць памылкі спецыфікацыі.

1.1 Старшынства

Статут Bluetooth SIG, Inc. (Статут) і пагадненні аб членстве [2] маюць прыярытэт перад любым супярэчлівым зместам гэтых дакументаў і SMPD. Нягледзячы ні на што ў гэтым дакуменце, Савет дырэктараў захоўвае за сабой поўную свабоду меркавання і паўнамоцтвы прымаць меры і рашэнні, нават калі гэтыя дзеянні і рашэнні не адпавядаюць або супярэчаць чым-небудзь у гэтым дакуменце, і нішто ў гэтым дакуменце не абмяжоўвае і не абмяжоўвае незалежныя паўнамоцтвы савета дырэктараў. і разважлівасць.

Калі ёсць якія-небудзь канфлікты паміж тэкстам у SMPD і малюнкамі, тэкст мае перавагу.

1.2 Рэферэнтныя групы і камітэты

У гэтым дакуменце згадваюцца наступныя тыпы груп: даследчыя групы (SG), экспертныя групы (EG) і працоўныя групы (WG). РГ таксама можа мець падгрупу, якая падпарадкоўваецца РГ. Падобным чынам у гэтым дакуменце згадваюцца наступныя тыпы камітэтаў: Bluetooth Architectural Review Board (BARB), Bluetooth Test and Interoperability (BTI) і Bluetooth Qualification Review Савет (BQRB). Гэты дакумент таксама адносіцца да тэхнічнага персаналу Bluetooth SIG (BSTS) і Савета дырэктараў.

1.3 Камітэт рэviewы і зацвярджэння

Камітэт рэview з'яўляецца паўторнымview які праводзіцца членамі камітэта (звычайна 3 членамі), каб даць зваротную сувязь на працягу пэўнага часу (звычайна 2-3 тыдні), аднак рэview час можа адрознівацца ў залежнасці ад працягласці і складанасці матэрыялу і іншых прыярытэтаў у камітэце. Група, якая запытвае рэview і камітэта, які праводзіць перазview кожны дамаўляецца аб працягласці рэview. Члены групы і камітэта выкарыстоўваюць інструменты Bluetooth SIG для паведамлення і запісу пачатку і канца паўторуview. Звычайна група будзе апрацоўваць водгукі камітэта, калі яны будуць атрыманы. Калі камітэт рэview час сканчаецца, група завяршае разгляд водгукаў камітэта, а таксама павінна разгледзець любыя познія прыбыцціview зваротнай сувязі, памятаючы, што матэрыял можа падлягаць наступнаму зацвярджэнню камітэтам.

Зацвярджэнне камітэта атрымліваецца шляхам галасавання членаў камітэта ў адпаведнасці з Працэсным дакументам рабочай групы [4].

1.4 Паведамленні членам і даступнасць матэрыялаў

Усе апавяшчэнні, якія прадастаўляюцца ўдзельнікам у адпаведнасці з гэтым дакументам, могуць адпраўляцца па электроннай пошце, напрыклад, перыядычныя тэхнічныя абнаўлення. Апавяшчэнні, якія павінны быць прадастаўлены ўсім членам, будуць адпраўлены ўсім актыўным удзельнікам (г.зн. членства ў якіх не было прыпынена, спынена або адклікана). Калі апавяшчэнні адпраўляюцца па электроннай пошце, яны будуць адпраўлены на апошні вядомы адрас электроннай пошты (як гэта адлюстравана ў актуальных на той момант запісах Bluetooth SIG) кожнага чалавека, які зарэгістраваўся пад уліковым запісам кампаніі-члена і які не адмовіўся ад атрымання апавяшчэнняў па электроннай пошце. Нішто ў гэтым дакуменце не змяняе абавязацельствы або патрабаванні Bluetooth SIG адносна прадастаўлення паведамлення ў адпаведнасці з Статутам або любым іншым пагадненнем паміж Bluetooth SIG і любым удзельнікам.

Усюды, дзе гэты дакумент спасылаецца на a webсайт, які даступны для ўсіх удзельнікаў, гэта адносіцца да даступнасці для асоб, якія маюць актыўны ўліковы запіс Bluetooth SIG. Удзельнікі, якія не маюць актыўнага ўліковага запісу, могуць стварыць уліковы запіс праз Bluetooth SIG webсайт.

1.5 Шаблоны

Для кожнага тыпу дакумента (напрыклад, спецыфікацыі, тэхнічныя дакументы, тэставыя дакументы), згаданага ў гэтым SMPD, Bluetooth SIG забяспечвае шаблон. Шаблон павінен быць выкарыстаны ў якасці асновы для кожнага дакумента, падрыхтаванага ў адпаведнасці з гэтым SMPD. Невыкарыстанне правільнага шаблону можа прывесці да таго, што дакумент не будзе зацверджаны. Шаблоны даступныя на Bluetooth SIG webсайт [8].

1.6 Тыпы спецыфікацый

Ёсць некалькі тыпаў спецыфікацый Bluetooth SIG. Іерархічна ўсе спецыфікацыі залежаць ад асноўнай спецыфікацыі Bluetooth. Спецыфікацыі, такія як традыцыйныя праfiles; традыцыйныя пратаколы; і на аснове ГАТТ праfiles, паслугі на аснове GATT і пратаколы на аснове GATT залежаць ад функцый асноўнай спецыфікацыі. Іншыя характарыстыкі, такія як характарыстыкі мадэлі Mesh, залежаць ад Mesh Profile спецыфікацыя, якая ў сваю чаргу залежыць ад асноўнай спецыфікацыі.

Спецыфікацыя Core Specification Supplement (CSS) вызначае тыпы даных, фарматы даных і агульны праfile і службовыя коды памылак, якія выкарыстоўваюцца ў асноўнай спецыфікацыі і іншых спецыфікацыях і самі па сабе не вызначаюць паводзін.

Спецыфікацыя Дадатку да спецыфікацыі GATT (GSS) вызначае фарматы характарыстык і дэскрыптараў, якія выкарыстоўваюцца Profiles і Паслугі і сам па сабе не вызначае ніякіх паводзін.
Спецыфікацыя Mesh Device Properties (MDP) вызначае ўласцівасці сеткі, якія выкарыстоўваюцца Mesh Profile і спецыфікацыі мадэлі Mesh і сама па сабе не вызначае ніякіх паводзін.

 

2. паview

У гэтым раздзеле ёсць надview працэсаў і не прызначаны для ўключэння ўсіх дэталяў.

Малюнак 2.1 паказвае шэсць асноўных этапаў, якія складаюць працэс кіравання спецыфікацыямі.

Першыя чатыры этапы адбываюцца ў працэсе распрацоўкі спецыфікацыі і складаюцца з этапу патрабаванняў (раздзел 3), этапу распрацоўкі (раздзел 4), этапу праверкі (раздзел 5) і этапу прыняцця/зацвярджэння (раздзел 6). Затым ідуць дзве фазы пасля ўсынаўлення: фаза абслугоўвання спецыфікацый (раздзел 7) і фаза заканчэння тэрміну службы спецыфікацый (раздзел 8).

Малюнак 2.2 дэталёва дэманструе чатыры этапы працэсу распрацоўкі спецыфікацыі. Шэрыя палі паказваюць асноўныя вынікі для кожнай фазы. Аранжавыя рамкі абагульняюць этапы працэсу.

На этапе патрабаванняў (апісаным у раздзеле 3) прапанова пачаць новую працу (Новая прапанова аб працы (NWP)) ініцыюе працэс распрацоўкі спецыфікацый шляхам вызначэння карыстальніцкіх сцэнарыяў, якія будуць уключаны, калі новая праца працягнецца. Калі NWP зацверджаны, прызначаная група стварае дакумент аб функцыянальных патрабаваннях (FRD). Пасля зацвярджэння FRD і прызначэння яго групе пачынаецца этап распрацоўкі.

Падчас фазы распрацоўкі (апісанай у раздзеле 4) распрацоўка спецыфікацыі праходзіць праз паслядоўнасць stages (ад 0.5/DIPD да 0.9/CR), што завяршылася поўным праектам спецыфікацыі. Спецыфікацыя 0.9/CR робіцца даступнай для ўсіх членаў, а затым прадстаўляецца радзе дырэктараў, які разглядае спецыфікацыю для зацвярджэння. Пасля зацвярджэння пачынаецца этап праверкі.

Падчас этапу праверкі распрацоўкі спецыфікацый (апісанага ў Раздзеле 5), зацверджаная Саветам дырэктараў спецыфікацыя 0.9/CR становіцца даступнай для ўсіх удзельнікаў для паўторнагаview і праверка, і член Review пачынаецца. Праверка ажыццяўляецца з дапамогай тэсціравання ўзаемадзеяння (IOP) паміж прататыпамі, створанымі ўдзельнікамі. Пасля завяршэння тэсціравання ВГД (калі патрабуецца для спецыфікацыі) і BARB зацвярджае справаздачу аб выпрабаванні ВГД, пачынаецца этап прыняцця/зацвярджэння.

Падчас этапу прыняцця/зацвярджэння (апісанага ў Раздзеле 6) завяршаецца падрыхтоўка спецыфікацыі і адпаведных тэставых дакументаў; Атрыманы дазволы BARB, BQRB, BTI; і канчатковы пакет спецыфікацый прадстаўляецца ў Савет дырэктараў, які разглядае спецыфікацыю для прыняцця (г.зн. канчатковага зацвярджэння).

Спецыфікацыі можа спатрэбіцца вярнуцца да папярэдняй фазы або этапаўtage, калі ўнесены істотныя змены. У некаторых выпадках можна таксама адмовіцца ад часткі этапу, як апісана ў раздзеле 4.4.

Этап абслугоўвання спецыфікацый (апісаны ў раздзеле 7) пачынаецца пасля прыняцця спецыфікацыі Саветам дырэктараў. Падчас гэтага этапу паведамляюцца і ацэньваюцца патэнцыйныя памылкі, выяўленыя ў прынятай спецыфікацыі, і (пры неабходнасці) у спецыфікацыю ўносяцца выпраўленні выпраўленняў. Фаза абслугоўвання спецыфікацый працягваецца, пакуль спецыфікацыя не будзе прызнана састарэлай або адменена (гл. Фазу заканчэння жыцця спецыфікацыі ў наступным параграфе).

Фаза заканчэння тэрміну службы спецыфікацыі (апісаная ў раздзеле 8) апісвае працэс адмены і адклікання прынятых спецыфікацый.

 

3. Этап патрабаванняў

Этап патрабаванняў пачынаецца альбо з NWP (у якім гаворыцца аб жаданні пачаць працу над адным або некалькімі карыстальніцкімі сцэнарыямі), альбо пасля вызначэння таго, што патрэбная новая праца ўжо ахоплена статутам іх WG. Калі РГ хоча пачаць новую працу, якая, на яе думку, ужо ўваходзіць у статут яе РГ, РГ павінна прытрымлівацца працэсу, вызначанага ў раздзеле 3.1, каб перайсці непасрэдна да распрацоўкі FRD. Для ўсіх астатніх элементаў працы рабочая група павінна прытрымлівацца працэсу, вызначанага ў раздзеле 3.2. FRD вызначае аб'ём функцыянальных патрабаванняў, якія выкарыстоўваюцца для стварэння спецыфікацый на этапе распрацоўкі. Этап патрабаванняў паказаны на малюнку 3.1.

3.1 Новая праца, на якую распаўсюджваецца статут РГ

Калі РГ хоча пачаць новую працу і абгрунтавана лічыць, што функцыянальнасць, якую яна хоча дадаць, ужо ўваходзіць у статут яе РГ, РГ можа пачаць працу над FRD пры ўмове, што яна неадкладна паведаміць BARB. РГ будзе ўключаць у сваё паведамленне BARB апісанне прапанаванай новай працы і копію статута РГ з выдзеленай мовай, якая дазваляе ім пачаць новую працу.

Калі BARB адхіляе аналіз рабочай групы, рабочая група павінна спыніць працу над FRD і працягнуць працэс NWP, апісаны ў раздзеле 3.2. Калі BARB зацвердзіць аналіз рабочай групы, рабочая група неадкладна паведаміць аб гэтым BSTS (па электроннай пошце specification.manager@bluetooth.com), і BSTS дадасць гэты пункт у парадак дня наступнага Савета дырэктараў.

РГ будзе ўключаць у сваё апавяшчэнне BSTS тую ж інфармацыю, што і BARB. Калі Савет дырэктараў адхіляе аналіз РГ, РГ павінна спыніць працу над FRD і прыступіць да працэсу NWP, апісанага ў Раздзеле 3.2. Калі Савет дырэктараў зацвердзіць аналіз РГ, РГ можа працягваць працу над FRD, як паказана ў Раздзеле 3.3.

3.2 Новая працоўная прапанова (NWP)

Любы ўдзельнік, WG, SG або EG можа стварыць і прадставіць NWP (праз Bluetooth SIG webсайт [10]). NWP павінен уключаць, як мінімум, наступную інфармацыю з выкарыстаннем афіцыйнага шаблону, прадстаўленага ў [8]:

• Карыстальніцкія сцэнарыі
• Абавязацельства члена развіваць FRD і ў якой вобласці (напрыклад, удзельнік, аўтар, Reviewэ-э, прататып)
• Прапанаванае кіраўніцтва працай ФРД
• Прапанаванае групавое заданне для работы ФРД
• Адрас электроннай пошты асноўнага аўтара(аў)

Заўвага: Кіраўніцтва па працэсе NWP даступна на Bluetooth SIG webсайт [10].

Пры распрацоўцы НПП БСТС будзе выконваць наступныя задачы:

• Дайце аўтару (аўтарам) пацверджанне атрымання (звычайна на працягу сямі каляндарных дзён з моманту атрымання) і акрэсліце наступныя крокі.
• Пры неабходнасці папрацуйце з аўтарам (аўтарамі), каб NWP быў зразумелым і поўным. Для гэтага можа спатрэбіцца некалькі ітэрацый NWP.
• Калі NWP змяшчае заявы аб памылках у прынятых спецыфікацыях Bluetooth, супрацоўнічайце з аўтарам (аўтарамі). file запісы ў сістэму памылак.
• Калі заўважана, што NWP патэнцыйна дублюе працу, якая ўжо выконваецца або ўжо завершана, паведаміце аўтару(ам) іншай працы для іх ацэнкі.
• Размясціце NWP у NWP webсайт даступны ўсім членам.
• Паведаміце ўсім членам, што NWP даступны для паўторнага выкарыстанняview і ці патрэбны дадатковыя абавязацельствы членаў па распрацоўцы FRD.

Удзельнікі могуць звязацца з аўтарам (аўтарамі), каб задаць пытанні ці даць водгук адносна NWP.

Прынамсі тры кампаніі-ўдзельніцы павінны ўзяць на сябе абавязацельства прыняць удзел у завяршэнні выніковага FRD, каб NWP стала кандыдатам на зацвярджэнне Савета дырэктараў, і прынамсі адна кампанія-ўдзельніца павінна быць асацыяваным членам або членам-прамоўтарам. Пасля зацвярджэння NWP Саветам дырэктараў, Савет дырэктараў прызначыць NWP існуючай падгрупе або SG з усіх членаў для працы над FRD (апісана ў раздзеле 3.3). Калі адпаведнай падгрупы РГ або СГ не існуе, яе можна стварыць.

Для NWP, якія маюць дастатковую прыхільнасць членаў, BSTS будзе выконваць наступныя дадатковыя задачы:

• Прынамсі за 13 дзён да зацвярджэння NWP Саветам дырэктараў паведаміце BARB і групе, якой рэкамендаваны NWP, аб зацвярджэнні NWP. Гэта зроблена для таго, каб даць магчымасць для зваротнай сувязі ў такіх галінах, як прапанаваная група, ці ахоплена ЧПП ужо існуючай працай і г.д.
• Адпраўце запоўнены NWP у Савет дырэктараў.

1. Калі NWP прадстаўлены членамі, якія не звязаны з групай, арганізуйце, каб адзін з членаў прадставіў NWP Савету дырэктараў.
2. Калі NWP прадстаўлены групай, арганізуйце, каб старшыня групы прадставіў NWP Савету дырэктараў.
3. Запрасіць на паседжанне Савета дырэктараў старшыню БАРБ і старшынь груп, у якія рэкамендаваны да прызначэння НПР.
4. Калі NWP зацверджаны і прызначаны Саветам дырэктараў, паведаміце пра гэта групе, якой ён быў прызначаны; аўтар(ы); члены, вызначаныя ў NWP як абавязацельствы распрацаваць адпаведны FRD; і, калі NWP прапануецца групай, група вынікаў і наступных крокаў.

Пасля зацвярджэння NWP Саветам дырэктараў абнавіце статус NWP webсайт.

Любы NWP можа быць адхілены Саветам дырэктараў па сваім меркаванні, напрыкладample, з-за абмежаванасці рэсурсаў, калі праца ўжо цалкам завершана, праца выходзіць за межы кіруючых дакументаў Bluetooth SIG (напрыклад, інтэрфейс прыкладнога праграмавання (API)) [2], або калі прапанаваная праца павінна быць fileг як памылку. Калі NWP будзе адхілены, BSTS паведаміць аўтарам(ам), членам, вызначаным у NWP як абавязацельства распрацаваць адпаведны FRD, і, калі NWP прапануецца групай, групу. У паведамленні будуць указаны прычыны адмовы. Аўтар (аўтары), адданыя члены або група могуць запытаць час у парадку дня Савета дырэктараў, каб абскардзіць адмову.

Калі член або група жадае прапанаваць выдаліць функцыю з прынятай спецыфікацыі, група або член павінны падрыхтаваць NWP. NWP павінен уключаць аналіз уплыву, які акажа выдаленне на зваротную сумяшчальнасць і ўзаемадзеянне, у тым ліку аналіз уплыву на тэставыя выпадкі.

NWP не патрабуюцца для ўдасканалення спецыфікацый CSS, GSS або MDP: звычайна абнаўленні спецыфікацый CSS, GSS або MDP вынікаюць з абнаўленняў іншых спецыфікацый, якія маюць уласныя NWP.

3.3 Дакумент аб функцыянальных патрабаваннях (FRD)

FRD вызначаюць функцыянальныя патрабаванні для ўключэння карыстальніцкіх сцэнарыяў. FRD павінен уключаць, як мінімум, наступную інфармацыю з выкарыстаннем афіцыйнага шаблону, прадстаўленага ў [8]:

• Карыстальніцкія сцэнарыі
• Функцыянальныя патрабаванні на аснове карыстальніцкіх сцэнарыяў
• Абавязацельства ўдзельніка распрацаваць выніковую спецыфікацыю(-і)
• Дадатковая падтрымка прататыпа членамі для чаканых роляў
• Рэкамендаваная рабочая група для распрацоўкі выніковых спецыфікацый

Развіццё ФРД

FRD ствараюцца прызначанай падгрупай РГ з усімі членамі або членамі SG пры рэдакцыйнай падтрымцы BSTS. Любы ўдзельнік, зацікаўлены ва ўдзеле ў развіцці FRD, можа далучыцца да групы.

FRD павінны паказаць абавязацельства як мінімум дзвюх (хоць рэкамендуецца трох) кампаній-членаў на ўзроўні асацыяваных або прамоўтэраў прыняць удзел у распрацоўцы выніковай спецыфікацыі. Рабочыя групы або SG, якія прадстаўляюць FRD, павінны паспрабаваць атрымаць шырокую падтрымку з боку кампаній-членаў групы, якія прадстаўляюць мэтавы галіновы сегмент, вызначаны ў FRD.

Новая функцыянальнасць, прапанаваная ў FRD, павінна падтрымлівацца як мага большай колькасцю транспартных сродкаў і існуючых прылад. Гэта ўключае, напрыклад,ample, падтрымліваючы праfiles і паслугі як на базавай хуткасці/пашыранай хуткасці перадачы дадзеных (BR/EDR), так і на транспарце Bluetooth з нізкім энергаспажываннем (LE). Калі новай функцыянальнасці не хапае дастатковай падтрымкі членаў для транспарту, напрыкладample з-за адсутнасці абавязацельстваў удзельнікаў па вызначэнні выкарыстання транспарту або патэнцыйна недастатковай колькасці тэставых платформ IOP для адной або некалькіх роляў падтрымка гэтага транспарту можа быць выключана з FRD.

Калі іншае не апраўдана, новая функцыянальнасць, праfiles, і службы павінны адпавядаць патрабаванням зваротнай сумяшчальнасці, апісаным у раздзеле 3.3.2.

WG або SG павінны прадставіць FRD у BARB для пераглядуview і адабрэнне. BARB павінен зацвердзіць або адхіліць FRD на падставе свайго інжынернага меркавання. У выпадку зацвярджэння BARB FRD стане даступным для ўсіх удзельнікаў, а BSTS адправіць паведамленне аб яго наяўнасці.

FRD не патрабуюцца для ўдасканалення спецыфікацый CSS, GSS або MDP: звычайна абнаўленні спецыфікацый CSS, GSS або MDP вынікаюць з абнаўленняў іншых спецыфікацый, якія маюць уласныя FRD.

Патрабаванні да зваротнай сумяшчальнасці

Зваротная сумяшчальнасць для BR/EDR

Для працы BR/EDR патрабаванне зваротнай сумяшчальнасці вызначаецца як узаемадзеянне з часткай BR/EDR асноўнай спецыфікацыі Bluetooth v1.1 і пазнейшых.

Зваротная сумяшчальнасць для Bluetooth Low Energy

Для працы LE патрабаванне зваротнай сумяшчальнасці вызначаецца як узаемадзеянне з часткай LE асноўнай спецыфікацыі Bluetooth v4.0 і больш позняй версіі.

Зваротная сумяшчальнасць для спецыфікацый, акрамя асноўнай спецыфікацыі

Для іншых спецыфікацый, акрамя асноўнай спецыфікацыі Bluetooth, неабходна падтрымліваць зваротную сумяшчальнасць дадзенай версіі з усімі больш раннімі версіямі, якія маюць аднолькавы асноўны нумар версіі. Напрыкладample, версія 1.3 павінна быць сумяшчальная з версіямі 1.2, 1.1 і 1.0, але версія 2.0 можа быць несумяшчальная з версіямі 1.0, 1.1, 1.2 і 1.3. Звярніце ўвагу, што павелічэнне асноўнага нумара версіі асноўнай спецыфікацыі не азначае адсутнасці зваротнай сумяшчальнасці з папярэднімі версіямі.

Вызваленне ад патрабаванняў зваротнай сумяшчальнасці

РГ або SG могуць прапанаваць вызваліць пэўную функцыянальнасць ад патрабавання зваротнай сумяшчальнасці, калі будзе прадстаўлена абгрунтаванне. Напрыкладample, калі паказана, што функцыянальнасць мае нізкі ўзровень прыняцця на рынку або з-за праблем з сумяшчальнасцю лепш выдаліць або замяніць функцыянальнасць, чым змяняць функцыянальнасць. WG або SG павінны ўключаць у FRD любыя выключэнні адносна зваротнай сумяшчальнасці, якія зацвярджаюцца BARB пасля зацвярджэння FRD. Любыя выключэнні, зацверджаныя BARB, будуць прадстаўлены на зацвярджэнне Савету дырэктараў на 0.9/CR Stage.

3.4 Статут рабочай групы

Калі BARB зацвярджае FRD, які прапануецца прызначыць існуючай рабочай групе, гэтая рабочая група павінна падрыхтаваць праект абнаўлення свайго статута, каб дадаць новую функцыянальнасць у сферу дзеяння (калі савет дырэктараў раней не зацвердзіў аналіз рабочай групы аб тым, што абнаўленне статута рабочай групы з'яўляецца не патрабуецца). Аднак, калі BARB зацвярджае FRD, які прапануецца прызначыць новай РГ, BARB і члены, якія зацікаўлены ў развіцці функцый, выкладзеных у FRD, павінны падрыхтаваць праект статута для новай РГ з новай функцыянальнасцю, уключанай у статутны аб'ём .

Пасля таго як новы або абноўлены статут РГ будзе падрыхтаваны, ён павінен быць адпраўлены ў BARB для пераглядуview і адабрэнне. Пасля таго, як BARB зацвердзіць статут, праект новага або абноўленага статута РГ будзе прадстаўлены на зацвярджэнне ў Савет дырэктараў.

Пасля таго, як Савет дырэктараў зацвердзіць статут, рабочая група, якой Савет дырэктараў даручыў працу па распрацоўцы спецыфікацый, павінна працаваць у цесным супрацоўніцтве з групай, якая падрыхтавала FRD, на выпадак, калі спатрэбяцца неабходныя абнаўленні або ўдакладненні гэтага FRD. Калі неабходна абнаўленне FRD на этапе распрацоўкі, трэба выконваць працэсы, апісаныя ў раздзеле 3.3 і ў гэтым раздзеле; аднак распрацоўка спецыфікацый можа адбывацца паралельна з абнаўленнямі статута FRD і WG.

3.5 Патрабаванні Патрабаванні да выхаду з фазы

Этап патрабаванняў завершаны, а этап распрацоўкі пачынаецца, калі статут рабочай групы з неабходным аб'ёмам для FRD будзе пацверджаны або зацверджаны Саветам дырэктараў і выкананы наступныя патрабаванні:

• NWP быў альбо зацверджаны Саветам дырэктараў, альбо Савет дырэктараў пагадзіўся, што NWP непатрэбны.
• ФРД і адпаведны статут РГ зацверджаны БАРБ.

 

4. Фаза развіцця

На этапе распрацоўкі прызначаныя РГ ствараюць новую спецыфікацыю і/або паляпшаюць існуючую спецыфікацыю. FRD вызначае патрабаванні да новай або пашыранай спецыфікацыі Bluetooth. У спецыфікацыі не дапускаюцца функцыянальныя магчымасці, якія разумна не звязаны з патрабаваннямі FRD. Мэта складаецца ў тым, каб стварыць спецыфікацыю 0.9/CR, якая будзе гатовая да этапу праверкі (апісанага ў раздзеле 5) пасля завяршэння этапу распрацоўкі.
На этапе распрацоўкі спецыфікацыя (або ўдасканаленне спецыфікацыі) прасоўваецца праз тры секундыtagэс.

Для новай спецыфікацыі тры stages з'яўляюцца:

• 0.5 Сtage
• 0.7 Сtage
• 0.9 Сtage

Для паляпшэння спецыфікацый, тры stages з'яўляюцца:

• Праект дакумента аб прапанове паляпшэння (DIPD) Stage
• Дакумент канчатковай прапановы па паляпшэнню (FIPD) Stage
• Запыт на змяненне (CR) Stage

Кожны stage апісана далей у наступных падраздзелах. Малюнак 4.1 ніжэй ілюструе розныя дакументы, якія рабочая група будзе рыхтаваць на кожным этапеtage.

Малюнак 4.1: Закончанаview спецыфікацыі stagякія адбываюцца на этапе развіцця

Роля BARB на працягу ўсяго працэсу распрацоўкі спецыфікацый заключаецца ў прадастаўленні рабочым групам кансультацый і тэхнічнай дапамогі. Рабочыя групы могуць у любы час запытваць у BARB тэхнічную кансультацыю адносна распрацоўкі спецыфікацыі і архітэктурных канцэпцый, якія будуць выкарыстоўвацца ў спецыфікацыі. Рабочым групам асабліва рэкамендуецца запытваць раннія водгукі ад BARB для функцый, якія маюць больш складаныя архітэктурныя меркаванні.

4.1 0.5/DIPD Stage

Падчас 0.5/DIPD Stage, рабочая група распрацуе наступнае, выкарыстоўваючы афіцыйныя шаблоны, прадстаўленыя ў [8]:

1. Для новай спецыфікацыі чарнавік спецыфікацыі 0.5, які павінен уключаць, як мінімум, наступную інфармацыю:

• Архітэктура, якая адпавядае патрабаванням, выкладзеным у FRD
• Для пратаколаў вызначаны пункты доступу да паслуг
• За паслугі, адкрытыя даныя і паводзіны
• Для профіfiles, ідэнтыфікаваныя пратаколы і вызначаны функцыянальныя магчымасці

2. Для паляпшэння спецыфікацый, праект DIPD, які павінен уключаць, як мінімум, інфармацыю аб наступным:

• фон: Аб'ём працы, мэты, якія кіруюць працай, і тое, як гэтая канкрэтная прапанова ўпісваецца ў аб'ём
• Скончанаview прапановы: Рэзюмэ пашыранай функцыянальнасці (дадатковая гнуткасць, палепшаная прадукцыйнасць і г.д.), прадстаўленае DIPD, у тым ліку дакладнае апісанне таго, як новая функцыя ўпісваецца ў бягучую версію спецыфікацыі. Калі рабочая група ацаніла некалькі прапаноў, гэтыя прапановы павінны быць уключаны, каб даць BARB магчымасць вызначыць, ці была зроблена дастатковая належная абачлівасць пры выбары пераважнай прапановы.
• Пакрыццё патрабаванняў: Рэзюмэ ахопу функцыянальных патрабаванняў, прадстаўленых прапановай, са спасылкай на адпаведныя сістэмныя патрабаванні і сцэнарыі выкарыстання, прыведзеныя ў адпаведнай FRD
• Вызначэнне праблемы: Выклад праблем, вырашаных прапановай(-ямі)
• Крытэрыі адбору: Заява адносна крытэрыяў адбору/прадукцыйнасці з звязаных паказчыкаў ацэнкі, якія кіравалі працэсам адбору
• Абгрунтаванне выбару: Вывучэнне паказчыкаў ацэнкі, якія абгрунтоўваюць выбар паміж прапановамі і выяўляюць кампрамісы
• Апісанне: Апісанне функцыянальнасці і пашыраных пратаколаў. Гэты раздзел можна адаптаваць да розных патрэбаў, дадаючы адпаведныя падраздзелы.

3. Тэст стратэгіі: Апісанне функцыянальных магчымасцей, прапанаваных для праверкі (ці не праверкі) у рамках кваліфікацыйнай праграмы Bluetooth, і таго, як функцыянальнасць прапануецца правяраць (напрыклад, чаканні ад ніжняга(-ых) тэстара(-аў) або верхняга(-ых) тэсціроўшчыка(-аў), і калі тэсты будуць прыпісаны як тэсты на адпаведнасць або ўзаемадзеянне або іх спалучэнне). Гэта можа быць у асобным дакуменце або ў асобным раздзеле спецыфікацыі 0.5/DIPD. Пагадненні, якія будуць выкарыстоўвацца ў стратэгіі тэсціравання, апісаны ў Стратэгіі тэсціравання і тэрміналогііview дакумент (ТСТО) [5].

Асноўная аўдыторыя дакументаў на гэтым сtagе члены РГ і БАРБ, якія рэview архітэктурныя прапановы і патрабаванні пакрыцця, і БТІ хто рэviewСтратэгія тэставання. У большасці выпадкаў дакументы на гэтым сtage не прызначаны для ўтрымання тэксту, які плануецца ўключыць у канчатковую спецыфікацыю.

BSTS павінна аднview усе дакументы для ўзгаднення з Bluetooth Drafting Guidelines [1] і вызначыць праблемы, якія павінна вырашыць рабочая група. БАРБ мусіць пераview спецыфікацыі 0.5/DIPD. Для паляпшэння спецыфікацый BARB таксама павінен паўторнаview DIPD на адпаведнасць патрабаванням зваротнай сумяшчальнасці, апісаным у раздзеле 3.3.2. БТІ павінна паўторнаview стратэгія тэставання.

BARB павінен альбо зацвердзіць, альбо адхіліць спецыфікацыю 0.5/DIPD на падставе свайго інжынернага меркавання. У выпадку зацвярджэння BARB спецыфікацыі 0.5/DIPD будуць даступныя на Bluetooth SIG webсайт для ўсіх асацыяваных членаў і прамоўтэраў, а BSTS выдасць паведамленне аб яго даступнасці. На 0.5/DIPD Stage, зацвярджэнне стратэгіі тэсціравання не патрабуецца.
0.5/DIPD Stage не патрабуецца для ўдасканалення спецыфікацый CSS, GSS або MDP

0.5/DIPD Stagэлектронныя патрабаванні да выхаду

0.5/DIPD Stage завершана, і 0.7/FIPD Stage пачынаецца, калі выкананы наступныя патрабаванні да выхаду:

• БДСТ завяршыў рэviewспецыфікацыі 0.5/DIPD і стратэгіі тэсціравання.
• BARB ухваліў спецыфікацыю 0.5/DIPD.
• БТІ завяршыла перапрацоўкуview стратэгіі выпрабаванняў.
• BSTS зрабіў зацверджаную спецыфікацыю 0.5/DIPD даступнай для ўсіх асацыяваных членаў і прамоўтэраў.

4.2 0.7/FIPD Stage

Падчас 0.7/FIPD Stage, рабочая група распрацуе наступнае, выкарыстоўваючы афіцыйныя шаблоны, прадстаўленыя ў [8]:

1. Для новай спецыфікацыі чарнавік спецыфікацыі 0.7, які павінен уключаць, як мінімум, наступную інфармацыю:

• Апісанне ўсіх змяненняў, якія былі ўнесены пасля зацверджанай BARB версіі 0.5, уключаючы новыя або мадыфікаваныя прапановы, крытэрыі выбару і абгрунтаванне выбару. Змены павінны быць апісаны на тым жа ўзроўні дэталізацыі, які патрабуецца ў 0.5 Stage.
• Выкананы ўсе функцыянальныя патрабаванні FRD.

2. Для паляпшэння спецыфікацый, праект FIPD, які павінен уключаць, як мінімум, інфармацыю аб наступным:

• Апісанне ўсіх змяненняў, унесеных з моманту зацвярджэння BARB DIPD, уключаючы новыя або мадыфікаваныя прапановы, крытэрыі адбору і абгрунтаванне выбару. Змены павінны быць апісаны на тым жа ўзроўні дэталізацыі, які патрабуецца ў DIPD Stage.
• Па меры неабходнасці дадаткова развіваліся вобласці, апісаныя ў раздзеле 4.1 адносна DIPD.
• Завершанае апісанне паляпшэння.
• Абноўленае архітэктурнае апісанне.
• Выкананы ўсе функцыянальныя патрабаванні FRD.

3. Тэставыя дакументы 0.7/FIPD, якія павінны ўключаць, як мінімум, наступную інфармацыю:

• Набор тэстаў, які складаецца са спісу мэтаў тэставання, апісаных у TSTO [5].
• Заява аб адпаведнасці ўкаранення (ICS), як апісана ў TSTO [5].

Для паляпшэння спецыфікацый набор тэстаў і ICS могуць пастаўляцца ў выглядзе асобных дакументаў або ў выглядзе дадатковых раздзелаў у FIPD.

Асноўная аўдыторыя дакументаў, вырабленых на гэтым сtagе члены РГ і БАРБ, якія рэview поўнае апісанне функцыі або паляпшэння, уключаючы тэкст, які плануецца ўключыць у канчатковую спецыфікацыю. БТІ - аўдыторыя для пераview экзаменацыйных дакументаў.

BSTS будзе адзview новыя або змененыя часткі спецыфікацыі 0.7/FIPD і тэставых дакументаў на адпаведнасць інструкцыям па складанні Bluetooth, уключаючы моўныя пагадненні, устаноўленыя Bluetooth SIG. БАРБ будзе паўторнаview спецыфікацыі 0.7/FIPD.

BSTS будзе дапамагаць рабочай групе ў падрыхтоўцы тэставых дакументаў 0.7/FIPD у адпаведнасці з TSTO [5].

БТІ павінна паўторнаview тэставыя дакументы 0.7/FIPD. Рабочая група павінна прадаставіць спецыфікацыю 0.7/FIPD у БТІ ў якасці эталона пры паўторнымviewтэставыя дакументы 0.7/FIPD, якія БТІ будзе паўторнаview у адпаведнасці са Спецыфікацыяй БТІ Review Кантрольны спіс працэсаў [6].

Пасля таго, як BARB завяршыў сваю рэview спецыфікацыі 0.7/FIPD і БТІ завяршыла пераглядview тэставых дакументаў 0.7/FIPD, BSTS зробіць паўторныviewСпецыфікацыя ed 0.7/FIPD даступная ўсім асацыяваным і прамоўтэрскім членам.

0.7/FIPD Stage не патрабуецца для паляпшэння спецыфікацый CSS, GSS або MDP.

0.7/FIPD Stagэлектронныя патрабаванні да выхаду

0.7/FIPD Stage завершаны і 0.9/CR Stage пачынаецца, калі выкананы наступныя патрабаванні да выхаду:

• БДСТ завяршыў рэviewспецыфікацыі 0.7/FIPD і тэставых дакументаў.
• БАРБ завяршыў рэviewу адпаведнасці са спецыфікацыяй 0.7/FIPD.
• БТІ завяршыла рэviewнабор тэстаў 0.7/FIPD (мэты тэсціравання) і 0.7/FIPD ICS.
• БДСТ здзейсніў рэпviewСпецыфікацыя ed 0.7/FIPD даступная ўсім асацыяваным і прамоўтэрскім членам.

4.3 0.9/CR Stage

Ёсць два тыпы CR: інтэграваны CR, які ўяўляе сабой дакумент з адсочваннем змяненняў усёй прынятай спецыфікацыі, які паказвае ўсе змены з папярэдняй версіі, і скарочаны CR, які з'яўляецца дакументам, які змяшчае інструкцыі па мадыфікацыі толькі закранутых раздзелаў версія спецыфікацыі, на якой заснаваны CR.

Падчас 0.9/CR Stage, рабочая група распрацуе наступнае, выкарыстоўваючы афіцыйныя шаблоны, прадстаўленыя ў [8]:

1. Для новай спецыфікацыі поўны змест чарнавіка спецыфікацыі 0.9, які павінен уключаць, як мінімум, наступную інфармацыю:

• Апісанне ўсіх змяненняў, зробленых пасля BARB-reviewвыданне спецыфікацыі 0.7 (або пасля таго, як спецыфікацыя 0.5, калі вытворчасць спецыфікацыі 0.7 была адменена), у тым ліку новыя або
• змененыя прапановы, крытэрыі адбору і абгрунтаванне выбару. Змены павінны быць апісаны на тым жа ўзроўні дэталізацыі, які патрабуецца ў 0.5 Stagе і 0.7 пдtage.

2. Для паляпшэння спецыфікацыі:

• Або інтэграваны CR, які павінен уключаць, як мінімум, інфармацыю аб наступным:
• Апісанне ўсіх змяненняў, зробленых пасля BARB-reviewрэд FIPD (або пасля DIPD, калі FIPD быў адменены), уключаючы новыя або змененыя прапановы, крытэрыі адбору і абгрунтаванне выбару. Змены павінны быць апісаны на тым жа ўзроўні дэталізацыі, які патрабуецца ў DIPD Stage і FIPD Stage.
• Усе змены, прапанаваныя ў раней прынятую спецыфікацыю з дапамогай адсочвання змяненняў.
• Усе зацверджаныя тэхнічныя памылкі (з кожнай памылкай са спасылкай на нумар памылкі), паказаныя з дапамогай адсочвання змяненняў, якія яшчэ не былі ўключаны ў раней прынятую версію спецыфікацыі і якія ўплываюць на тэкст, які звязаны з удасканаленнем спецыфікацыі; або якія іншым чынам уплываюць на тэставанне ВГД.

3. Або скарочаны CR, які павінен уключаць, як мінімум, наступную інфармацыю:

• Апісанне ўсіх змяненняў, зробленых пасля BARB-reviewрэд FIPD (або пасля DIPD, калі FIPD быў адменены), уключаючы новыя або змененыя прапановы, крытэрыі адбору і абгрунтаванне выбару. Змены павінны быць апісаны на тым жа ўзроўні дэталізацыі, які патрабуецца ў DIPD Stage і FIPD Stage.
• Усе змены, прапанаваныя для кожнага закранутага раздзела і параграфа спецыфікацыі, якія CR прапануе змяніць.
• Усе зацверджаныя тэхнічныя памылкі (з кожнай памылкай са спасылкай на нумар памылкі), паказаныя з выкарыстаннем разметкі, якія яшчэ не былі ўключаны ў раней прынятую версію спецыфікацыі і якія ўплываюць на тэкст, які звязаны з удасканаленнем спецыфікацыі; або якія іншым чынам уплываюць на тэставанне ВГД.

4. CSS CR (калі спецыфікацыя патрабуе новых запісаў), якая можа быць убудавана ў скарочаны CR спецыфікацыі.
5. GSS CR (калі спецыфікацыі патрабуюцца новыя запісы), які можа быць убудаваны ў скарочаны CR спецыфікацыі.
6. MDP CR (калі новыя запісы патрабуюцца спецыфікацыяй), які можа быць убудаваны ў скарочаны CR спецыфікацыі.
7. Тэставыя дакументы 0.9/CR, якія павінны ўключаць, як мінімум, наступную інфармацыю з выкарыстаннем афіцыйнага шаблону, прадстаўленага ў [8]:

• Пакет тэстаў 0.9/CR, які ўключае поўныя тэсты і звязаную табліцу адлюстравання тэстаў (TCMT), як апісана ў TSTO [5].
• 0.9/CR ICS, як апісана ў TSTO [5].
• Калі для канфігурацыі тэстаў патрабуюцца пэўныя параметры для тэсціруемай рэалізацыі (IUT), дадатковая інфармацыя для тэсціравання рэалізацыі 0.9/CR (IXIT).
• 0.9/CR Test Case Reference List (TCRL) (неабавязковы для абнаўлення асноўных спецыфікацый).

8. Аналіз тэставага пакрыцця, які паказвае, якія патрабаванні да спецыфікацыі пратэставаны або не пратэставаны ў 0.9/CR Test Suite (для паляпшэння спецыфікацый аналіз тэставага пакрыцця павінен уключаць толькі нядаўна дададзеныя і закранутыя функцыі, а не незакранутыя вобласці арыгінальная спецыфікацыя).
9. План праверкі ВГД.

Для паляпшэння спецыфікацый Набор тэстаў, ICS і IXIT могуць пастаўляцца ў выглядзе асобных дакументаў або ў выглядзе дадатковых раздзелаў у скарочаным CR.

У большасці выпадкаў інтэграваны або скарочаны CR павінен быць заснаваны на раней прынятай версіі спецыфікацыі, але ён таксама можа быць заснаваны на апошнім прамежкавым праекце. Нумар версіі апошняга прамежкавага праекта спецыфікацыі павінен быць нумарам версіі, звязаным з версіяй дакумента, якая замарожана і не будзе змяняцца з цягам часу. У адваротным выпадку дадатковую ідэнтыфікацыйную інфармацыю (напрыклад, дату дакумента і a URL у пастаяннае месца) павінны быць прадастаўлены для ідэнтыфікацыі канкрэтнай «базавай» версіі. Калі выкарыстоўваецца прамежкавы чарнавік, усе змены, не звязаныя непасрэдна з CR у дадзеным раздзеле, які мадыфікуецца CR, павінны быць уключаны, але не абавязкова паказвацца з дапамогай разметкі. Калі адпаведныя часткі прамежкавага чарнавіка будуць пазней абноўлены, CR павінен быць абноўлены, каб адлюстраваць абнаўленні прамежкавага чарнавіка.

У ідэале скарочаны матэрыял CR інтэгруецца ў чарнавік поўнай спецыфікацыі і поўных тэставых дакументаў адпаведна перад этапам праверкі, але яны таксама могуць быць інтэграваны ў пачатку этапу праверкі. Калі для спецыфікацыі (напрыклад, асноўнай спецыфікацыі) распрацоўваецца некалькі функцый, можа быць пажадана інтэграваць функцыі ў адзін чарнавік пасля завяршэння тэставання IOP.

BSTS будзе адзview спецыфікацыя 0.9/CR і тэставыя дакументы на адпаведнасць інструкцыям па складанні Bluetooth. Потым БАРБ паўторнаview спецыфікацыя 0.9/CR, а затым план тэсціравання ВГД (як апісана ў раздзеле 4.3.1). Пасля таго, як спецыфікацыя 0.9/CR будзе прадстаўлена рабочай групай у BARB для пераўтварэнняview, BSTS зробіць яго даступным для ўсіх членаўview і паведаміць усім членам аб яго даступнасці. З гэтага моманту ў працэсе распрацоўкі спецыфікацый BSTS будзе рабіць чарнавікі спецыфікацый, прадстаўленых у BARB, даступнымі для ўсіх членаў з перыядычнымі паведамленнямі, якія адпраўляюцца ўсім членам.

Для ўдасканалення спецыфікацый рабочая група будзе рэкамендаваць Савету дырэктараў, ці павінны папярэднія версіі спецыфікацый быць састарэлымі або адкліканымі, уключаючы тэхнічныя прычыны рэкамендацыі(й).

БАРБ будзе паўторнаview аналіз WG на адпаведнасць спецыфікацыі 0.9/CR патрабаванням, прыведзеным у FRD, любыя патэнцыйныя праблемы бяспекі, любыя нарматыўныя праблемы, адпаведнасць архітэктуры Bluetooth і, для паляпшэння спецыфікацыі, адпаведнасць патрабаванням зваротнай сумяшчальнасці, апісаным у раздзеле 3.3.2. .XNUMX. Калі BARB выявіць любыя патэнцыйныя праблемы бяспекі, BARB паведаміць аб гэтым BSTS для паўторнага разглядуview і каардынацыя з Экспертнай групай па бяспецы; і калі BARB выявіць якія-небудзь нарматыўныя наступствы, BARB паведаміць BSTS паўторнаview і каардынаваць дзеянні з Камітэтам па рэгуляванні і юрысконсультам Bluetooth SIG. BARB павінен зацвердзіць або адхіліць спецыфікацыю 0.9/CR на аснове свайго інжынернага меркавання і ўліку фактараў, апісаных у гэтым параграфе.

БТІ паўторнаview тэставыя дакументы 0.9/CR з улікам аналізу тэставага пакрыцця. БТІ павінна альбо зацвердзіць, альбо адхіліць дакументы праверкі 0.9/CR.

Пасля зацвярджэння BARB спецыфікацыі 0.9/CR рабочая група прадстаўляе план тэсціравання ВГД у BARB для пераглядуview.

Спецыфікацыя 0.9/CR, зацверджаная BARB, прадстаўляецца Савету дырэктараў для зацвярджэння пачатку тэсціравання ВГД і публікацыі спецыфікацыі 0.9/CR для ўсіх членаў.

Каб вылучыць патэнцыйныя юрыдычныя праблемы, працоўныя групы могуць запытаць спецыфікацыюview ад юрысконсульта Bluetooth SIG (юрыдычная справаview) перад абавязковым судовым паўторамview адбываецца на этапе прыняцця/зацвярджэння. Тым не менш, для ўдасканалення спецыфікацый, юрыдычная рэview павінна быць зроблена на інтэграваным CR (у адрозненне ад скарочанага CR), і гэта павінна быць запланавана як мага раней, каб былі даступныя рэсурсы.

План тэставання ВГД

Рабочая група распрацуе пісьмовы план тэсціравання ВГД, які павінен адпавядаць усім патрабаванням, вызначаным ніжэй, для выкарыстання на этапе праверкі падчас тэсціравання ВГД. Рабочыя групы павінны прадставіць план тэсціравання ВГД у BARB для паўторнага разглядуview да таго, як пачнецца падзея(-і) тэсціравання ВГД. Для простых удасканаленняў спецыфікацый (асабліва тых, якія не патрабуюць мадыфікацыі або дадання якіх-небудзь тэставых выпадкаў у Test Suite), тэсціраванне IOP можа не спатрэбіцца, і рабочая група можа адправіць у BARB запыт на адмову ад тэсціравання IOP з дапамогай працэсу, вызначанага у раздзеле 4.4.

План тэсціравання ВГД павінен уключаць:

1. Тэставыя прыклады для праверкі ўсіх новых абавязковых, дадатковых і ўмоўных функцый
2. Прынамсі адзін тэставы прыклад для кожнага аперацыйнага кода
3. Як мінімум адзін тэставы прыклад для кожнага параметра
4. Як мінімум адзін тэставы прыклад для кожнага тыпу пакета
5. Выпрабаванні зваротнай сумяшчальнасці для паляпшэння спецыфікацый, каб патрабаванні, пералічаныя ў Раздзеле 3.3.2, выконваліся для ўсіх пашыраных функцый (таксама гл. Раздзел 4.3.1.1).
6. Тэставыя выпадкі, калі IUT падвяргаецца ўздзеянню значэнняў за межамі вызначаных дыяпазонаў або паводніцкіх аспектаў, якія лічацца несапраўднымі або нечаканымі (тэставыя прыклады несапраўдных паводзін). Звярніце ўвагу, што чакаецца, што тэстар, напрыклад PTS або іншы тэставы інструмент, будзе ініцыятарам любога несапраўднага паводзін.
7. Любыя часова прысвоеныя нумары (выбіраюцца ў каардынацыі з BSTS, каб пазбегнуць накладання падчас наступных тэсціравання ВГД), якія будуць выкарыстоўвацца падчас тэсціравання ВГД, як апісана ў раздзеле 4.3.1.2.
8. Вызначэнне неабходнай колькасці незалежных рэалізацый, якія павінны прайсці кожны тэставы прыклад, з улікам патрабаванняў да пакрыцця, апісаных у раздзеле 4.3.1.3
9. Ідэнтыфікацыя любых тэстаў у наборы тэстаў, якія, на думку рабочай групы, павінны быць выключаны, і абгрунтаванне іх выключэння. Да іх звычайна адносяцца: • тэставыя прыклады Future Proofing (напрыклад, агульныя тэсты, каб можна было ўлічыць магчымыя будучыя дапаўненні, такія як дадатковыя характарыстыкі, пашыральныя характарыстыкі або выкарыстанне бітаў або палёў, зарэзерваваных для будучага выкарыстання (RFU))
   • Тэставыя прыклады, якія з'яўляюцца часткай іншых уключаных тэстаў
   • Агульныя тэсты, якія практычна ідэнтычныя тэстам, якія выконваюцца для некалькіх іншых спецыфікацый (напрыклад, ініцыяванне агульных кодаў памылак)
   • Тэставыя прыклады з той жа мэтай тэставання, што і тэставыя прыклады, якія выконваюцца на іншым транспарце (напрыклад, тэставы варыянт BR/EDR, падобны на тэставы варыянт LE)
   • Надзейнасць або стрэс-тэставанне рэалізацыі

План тэсціравання IOP можа таксама ўключаць тэсты, унікальныя для тэсціравання IOP, такія як скразныя тэсты, якія аб'ядноўваюць больш складаныя паслядоўнасці, якія могуць нагадваць тыповы сцэнарый карыстальніка.

Хаця зацвярджэнне BARB плана тэсціравання ВГД не патрабуецца (пры ўмове, што план тэсціравання ВГД будзе працягваць мадыфікавацца і ўдасканальвацца з кожным мерапрыемствам тэсціравання ВГД), патрабуецца зацвярджэнне BARB справаздачы аб тэсціраванні ВГД (гл. Раздзел 5.1.1) . Калі план тэсціравання ВГД не задавальняе ўсім патрабаванням, вызначаным у Раздзеле 4.3.1, рабочая група павінна прадставіць BARB кароткі змест любых вядомых адхіленняў і абгрунтаванне кожнага адхілення перад пачаткам тэсціравання ВГД.

План тэсціравання IOP і тэставыя прыклады павінны ў асноўным грунтавацца на змесце тэставых дакументаў адпаведнай спецыфікацыі.

Каб зрабіць мерапрыемствы па тэсціраванні ВГД эфектыўнымі, рабочая група павінна мець план тэсціравання ВГД і ўсе звязаныя тэставыя прыклады, завершаныя і даступныя распрацоўнікам, у ідэале, па меншай меры за месяц да першага мерапрыемства па тэсціраванню ВГД.

Планаванне тэставання зваротнай сумяшчальнасці
Для ўдасканалення спецыфікацый тэставанне IOP на зваротную сумяшчальнасць павінна прадугледжваць праверку ўсіх актыўных і састарэлых версій спецыфікацый, таму што гэтыя спецыфікацыі і функцыі, якія звычайна сустракаюцца ў прадуктах Bluetooth, могуць мець вельмі працяглы тэрмін службы (напрыклад, транспартныя сродкі). Рабочая група павінна прааналізаваць неабходны ўзровень тэставання зваротнай сумяшчальнасці (калі ён ёсць), уключаючы версіі і тэсты для выканання, і прадаставіць гэты аналіз BARB. БАРБ мусіць пераview аналіз і рэкамендаваць змены (калі такія маюцца) для ўключэння РГ у план тэсціравання ВГД.

Удзельнікам, якія ўдзельнічаюць у тэсціраванні зваротнай сумяшчальнасці, рэкамендуецца браць састарэлыя прылады, якія былі кваліфікаваны ў адпаведнасці з папярэднімі версіямі спецыфікацый. Рабочая група павінна паведаміць аб любых збоях зваротнай сумяшчальнасці ў справаздачы аб выпрабаванні IOP. Кампаніям-удзельнікам таксама прапануецца праводзіць тэсціраванне зваротнай сумяшчальнасці ў сваіх лабараторыях па-за месцам правядзення тэсціравання ВГД і паведамляць рабочай групе аб любых праблемах, звязаных са спецыфікацыямі.

Часовыя прысвоеныя нумары, якія выкарыстоўваюцца ў тэставанні ВГД
Неабходна пракансультавацца з BSTS і BARB для ўзгаднення часовага прысваення прысвоеных нумароў, якія будуць выкарыстоўвацца падчас тэсціравання ВГД, каб не было супярэчнасцей або сутыкненняў з іншымі спецыфікацыямі. Гэтыя часовыя значэнні павінны быць уключаны ў план тэсціравання ВГД і не будуць прызначаны для выкарыстання ні ў якіх прынятых спецыфікацыях.

Для тэставання IOP, дзе прапануецца адно або некалькі новых 16-бітных значэнняў UUID, значэнні ў дыяпазоне ад 0x7F00 да 0x7FFF зарэзерваваны для тэсціравання IOP.

Для тэсціравання IOP, дзе прапануецца адно або некалькі новых значэнняў мультыплексара паслуг фіксаванага пратаколу (PSM), будуць выкарыстоўвацца значэнні, пачынаючы з канца сапраўднага дыяпазону ад 0x0000 да 0x007F, як паказана ў асноўнай спецыфікацыі.

Патрабаванні да пакрыцця
Рабочая група павінна прадаставіць BARB доказы таго, што неабходная колькасць (як апісана ў наступных раздзелах) незалежных рэалізацый прайшла кожны тэставы прыклад. Любы запыт рабочай групы аб выключэнні з неабходнай колькасці незалежных укараненняў павінен быць указаны ў плане тэсціравання IOP, які прадстаўляецца ў BARB.

Рэалізацыі лічацца незалежнымі адна ад адной, пакуль усе часткі, якія маюць дачыненне да праверкі, былі распрацаваны незалежна адзін ад аднаго, г.зн. рознымі камандамі (якія неабавязкова паходзяць з розных кампаній). BSTS можа дапамагчы ў ацэнцы таго, ці можна лічыць прататыпы незалежнымі адзін ад аднаго, каб захаваць ананімнасць і канфідэнцыяльнасць дэталяў рэалізацыі.

Звярніце ўвагу, што інструменты тэставання, у тым ліку PTS, не лічацца незалежнымі рэалізацыямі.

Асноўная спецыфікацыя Патрабаванні да пакрыцця IOP
Функцыя асноўнай спецыфікацыі звычайна вызначае адну або некалькі роляў, дзе кожная роля прызначана для ўзаемадзеяння з адной або некалькімі іншымі ролямі або, магчыма, сама з сабой.

Для кожнай пары роляў, прызначаных для ўзаемадзеяння адна з адной, павінна быць прадэманстравана ўзаемадзеянне як мінімум трох незалежных рэалізацый кожнай ролі з трыма незалежнымі рэалізацыямі дадатковай ролі.

Для кожнай ролі, якая можа ўзаемадзейнічаць з іншай прыладай у той жа ролі, як мінімум тры незалежныя рэалізацыі гэтай ролі павінны прадэманстраваць, што яны могуць узаемадзейнічаць адна з адной у гэтай ролі.

Патрабаванні да ахопу IOP спецыфікацыі паслуг
Як мінімум тры незалежныя рэалізацыі сэрвісу павінны прадэманстраваць, што яны ўзаемадзейнічаюць як мінімум з адной кліенцкай рэалізацыяй, якой можа быць PTS.

профіfile і патрабаванні да ахопу спецыфікацыі пратаколу IOP
профіfile і спецыфікацыі пратаколу звычайна вызначаюць адну або некалькі роляў, дзе кожная роля прызначана для ўзаемадзеяння з адной або некалькімі іншымі ролямі або, магчыма, сама з сабой.

Для кожнай пары роляў, прызначаных для ўзаемадзеяння адна з адной, як мінімум дзве незалежныя рэалізацыі кожнай ролі павінны прадэманстраваць, што яны ўзаемадзейнічаюць з двума незалежнымі рэалізацыямі дадатковай ролі.

Для кожнай ролі, якая можа ўзаемадзейнічаць з іншай прыладай у той жа ролі, як мінімум тры незалежныя рэалізацыі гэтай ролі павінны прадэманстраваць, што яны ўзаемадзейнічаюць адна з адной у гэтай ролі.

Патрабаванні да пакрыцця ВГД спецыфікацыі мадэлі
Як мінімум тры незалежныя рэалізацыі мадэлі сервера або мадэлі кіравання павінны прадэманстраваць, што яны ўзаемадзейнічаюць як мінімум з адной рэалізацыяй кліента (якая можа быць PTS), і як мінімум адна рэалізацыя мадэлі кліента павінна прадэманстраваць, што яна ўзаемадзейнічае як мінімум з адной рэалізацыяй мадэлі сервера і PTS.

Нумарацыя версій спецыфікацыі

Падчас 0.9/CR Stage, рабочая група павінна падрыхтаваць рэкамендацыю для прадстаўлення Савету дырэктараў адносна нумара версіі, які будзе прымяняцца да спецыфікацыі пасля прыняцця.

Версіі спецыфікацый дзеляцца на два тыпы: поўныя версіі, якія ўключаюць новыя або абноўленыя функцыі, і версіі для абслугоўвання (таксама вядомыя як «версіі з кропкай Z»), якія ўключаюць тэхнічныя і рэдакцыйныя памылкі, але не ўключаюць новыя або абноўленыя Асаблівасці. Поўныя выпускі маюць нумары з дзвюх частак у выглядзе XY, напрыклад 2.1 або 5.0, у той час як версіі для абслугоўвання маюць нумары з трох частак у выглядзе XYZ, напрыклад 2.1.2. Значэнне Z не можа быць роўным 0.

Для любых дзвюх версій адна называецца «вышэйшай версіяй», а другая — «ніжэйшай версіяй». Гэта вызначаецца па наступных правілах:

• Калі кампаненты X адрозніваюцца, той з больш высокім значэннем X з'яўляецца «больш высокай версіяй».
• Калі кампаненты X аднолькавыя, але кампаненты Y адрозніваюцца, той з больш высокім значэннем Y з'яўляецца «вышэйшай версіяй».
• Калі кампаненты XY аднолькавыя, але кампаненты Z адрозніваюцца, той з больш высокім значэннем Z з'яўляецца «больш высокай версіяй». Лік XY, які складаецца з дзвюх частак, для гэтай мэты разглядаецца як лік XY0, які складаецца з трох частак.

Напрыкладample, наступныя нумары версій будуць у парадку ад самай нізкай да самай высокай: 1.4, 2.0, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.2. Для CSS кожнае абнаўленне павялічвае толькі кампанент X нумара версіі.

Перадумовы зацвярджэння Саветам дырэктараў
У канцы фазы распрацоўкі спецыфікацый павінны быць выкананы наступныя патрабаванні, перш чым спецыфікацыя 0.9/CR будзе прадстаўлена ў Савет дырэктараў на зацвярджэнне:

• РГ завяршыла аналіз ахопу тэстам.
• БДСТ завяршыў рэviewспецыфікацыі 0.9/CR і тэставых дакументаў.
• BARB ухваліў спецыфікацыю 0.9/CR.
• BARB зацвердзіў CR CSS (калі спецыфікацыя патрабуе новых запісаў), які можа быць убудаваны ў скарочаны CR спецыфікацыі.
• BARB зацвердзіў GSS CR і MDP CR (калі спецыфікацыя патрабуе новых запісаў).
• BTI ухваліў 0.9/CR Test Suite, ICS і TCRL разам з IXIT (пры ўмове, што IXIT неабходны для выканання тэстаў у Test Suite). TCRL не з'яўляецца абавязковым для гэтага stage для абнаўлення асноўнай спецыфікацыі.
• Рабочая група прадставіла план тэсціравання ВГД у BARB для пераглядуview (калі BARB не адмаўляецца ад тэставання).

Дакументы, прадстаўленыя Савету дырэктараў, павінны ўключаць зацверджаную BARB спецыфікацыю 0.9/CR і прэзентацыю Савету дырэктараў, якая павінна ўключаць:

• Любыя вядомыя запыты на адмову ад тэсціравання ВГД або любое з патрабаванняў, вызначаных у раздзеле 4.3.1
• Спіс транспартаў, якія падтрымлівае спецыфікацыя (напрыклад, BR/EDR, LE і г.д.)
• Для паляпшэння спецыфікацый любыя выключэнні з патрабаванняў зваротнай сумяшчальнасці (апісаных у Раздзеле 3.3.2), якія запытвае РГ
• Для паляпшэння спецыфікацый, рэкамендацыя ад рабочай групы аб нумары версіі для прымянення да прынятай спецыфікацыі
• Для ўдасканалення спецыфікацыі, рэкамендацыі рабочай групы па заканчэнні тэрміну службы для папярэдняй(-ых) версіі(-й) прынятай спецыфікацыі, уключаючы любыя тэхнічныя прычыны, па якіх састарэласць або адмена любой папярэдняй версіі спецыфікацыі рэкамендуецца або не рэкамендуецца, і абгрунтаванне за рэкамендацыю
• Любыя нявырашаныя сур'ёзныя праблемы з боку членаў BARB або BTI (напрыклад, прычыны любога галасавання "Не" падчас зацвярджэння, праблемы, якія ўзніклі ў выніку паўторнагаview тэставых дакументаў або занепакоенасць тым, што спецыфікацыя 0.9/CR выходзіць за межы FRD або статута)
• Статус падрыхтоўкі Profile Tuning Suite (PTS) або іншыя неабходныя інструменты, звязаныя з усынаўленнем, падрыхтаваныя BSTS

Савет дырэктараў можа зацвердзіць спецыфікацыю 0.9/CR для тэсціравання ВГД у адпаведнасці з патрабаваннямі Статута [2] да таго, як BTI зацвердзіць дакументы па тэсціраванні 0.9/CR і да таго, як рабочая група пацвердзіць, што план тэсціравання ВГД адпавядае патрабаванням, вызначаным у раздзеле 4.3.1. 0.9. Савет дырэктараў таксама можа абумоўліваць зацвярджэнне спецыфікацыі 0.9/CR для тэсціравання ВГД зацвярджэннем BTI тэставых дакументаў XNUMX/CR.

0.9/CR Stagэлектронныя патрабаванні да выхаду
0.9/CR Stage завершана, і этап праверкі пачынаецца, калі Савет дырэктараў зацвярджае пачатак тэсціравання ВГД.

4.4 Адмова ад працэсу распрацоўкі спецыфікацый

Рабочая група можа запытаць адмову ад аднаго або некалькіх з наступных этапаў працэсу:

• 0.5/DIPD Stage
• 0.7/FIPD Stage
• Тэставанне ВГД на этапе праверкі

Каб запытаць адмову, рабочая група павінна выкарыстаць шаблон адмовы ад працэсу, прадстаўлены Bluetooth SIG [8], і падаць запыт на адмову ў кожны камітэт (напрыклад, BARB або BTI), які абавязаны пераview або зацвердзіць праект спецыфікацыі або адпаведныя тэставыя дакументы ў stage што рабочая група прапануе адмовіцца, і кожны з гэтых камітэтаў павінен зацвердзіць запыт на адмову.

Запыт на адмову павінен уключаць наступнае:

• Ідэнтыфікацыя сtage(s), ад якіх РГ хоча адмовіцца
• Абгрунтаванне, чаму сtage(s) варта адмовіцца
• Ідэнтыфікацыя кожнага камітэта (напрыклад, BTI і/або BARB), які патрабуецца паўторнаview і зацвердзіць запыт на адмову

Камітэт, які разглядае адмову, можа запатрабаваць, каб прадстаўнік рабочай групы зрабіў прэзентацыю, каб абгрунтаваць адмову ад працэсу SMPD, перш чым прыняць рашэнне па запыце на адмову.

Калі адмова патрабуе адмовы ад некалькіх этапаў і частка адмовы адхілена, а частка зацверджана, у адказе камітэта павінна быць указана, якія крокі ў запыце на адмову былі зацверджаны, а якія адхілены. Калі запыт аб адмове адхілены, паведамленне аб адмове павінна ўтрымліваць прычыны адмовы.

5. Этап праверкі

На этапе праверкі рабочая група правядзе тэставанне ВГД па спецыфікацыі 0.9/CR з мэтай атрымання справаздачы аб выпрабаванні ВГД для BARB review і адабрэнне. Кожны раз, калі гэта магчыма, тэставанне IOP удасканаленняў спецыфікацый павінна праводзіцца ў адпаведнасці з інтэграваным праектам спецыфікацыі. Акрамя таго, член Review, як таго патрабуе Статут [2], пачынаецца падчас гэтага этапу.

Калі спецыфікацыя (або ўдасканаленне) не патрабуе тэсціравання ВГД, то тэставанне ВГД на этапе праверкі можа быць адменена з дапамогай працэсу, апісанага ў Раздзеле 4.4.

На працягу ўсяго тэсціравання IOP (якое можа складацца з адной або некалькіх падзей) рабочая група павінна адсочваць праблемы з дапамогай сістэмы адсочвання праблем Bluetooth SIG і праводзіць ітэрацыі, каб уключыць абнаўленні ў праект спецыфікацыі, тэставыя дакументы і план тэсціравання IOP. Пасля завяршэння тэсціравання ВГД рабочая група павінна завяршыць абнаўленні праектаў спецыфікацый і тэставых дакументаў для вырашэння ўсіх праблем, а таксама падрыхтаваць і адправіць справаздачу аб выпрабаванні ВГД у BARB для паўторнагаview і адабрэнне. Гэта паказана на малюнку 5.1.

На этапе праверкі можа пачацца некалькі дзеянняў. Гэтыя дзеянні могуць адбывацца паралельна і ўключаць у сябе наступнае:

• Спецыфікацыя 0.9/CR, зацверджаная Саветам дырэктараў, становіцца даступнай для ўсіх членаў BSTS з паведамленнем аб пачатку членскага Review перыяд, неабходны Статутам.
• Любыя неабходныя абнаўленні ўключаюцца ў CSS (які можа быць убудаваны ў скарочаны CR спецыфікацыі).
• Вызначэнні характарыстык або дэскрыптараў уключаны ў спецыфікацыі GSS, а таксама ў PTS для тэставання ВГД.
• Вызначэнні ўласцівасцей сеткі ўключаны ў спецыфікацыі MDP, а таксама ў PTS для тэставання ВГД.
• BSTS дазваляе рэгістраваць платформу IOP і інструмент для ўводу вынікаў у рамках падрыхтоўкі да тэставання IOP.
• Тэст ВГД, калі патрабуецца (гл. Раздзел 5.1).
• Review каментарыі і праблемы, у тым ліку прадстаўленыя ў выніку тэсціравання ВГД, апрацоўваюцца, а змены ўключаюцца ў праект спецыфікацыі.

5.1 Тэставанне ВГД

Асноўная мэта тэсціравання ВГД - праверка спецыфікацыі, напрыкладampле, праверка дакладнасці і неадназначнасці тэксту, паўторнаviewпошук любых фундаментальных памылак і недапрацовак у праектаванні, а таксама забеспячэнне пацверджання раней усталяваных патрабаванняў, распрацаваных раней у працэсе распрацоўкі спецыфікацый. Тэставанне ВГД можа прывесці да змяненняў у чарнавой спецыфікацыі, і для завяршэння ўсіх неабходных тэсціравання можа спатрэбіцца некалькі выпрабаванняў ВГД.

Важна даць членам, якія не ўваходзяць у РГ, магчымасць удзельнічаць у тэсціраванні ВГД, таму што яны забяспечваюць незалежны тэст view спецыфікацыі і можа выявіць неадназначнасці ў спецыфікацыі, якія могуць быць невідавочнымі членам рабочай групы, якія распрацоўвалі праект. Перад кожным мерапрыемствам тэсціравання ВГД BSTS будзе даваць падрабязную інфармацыю аб мерапрыемстве, апошнюю версію спецыфікацыі, набор тэстаў і план тэсціравання ВГД і апавяшчаць усіх членаў у ідэале за месяц да кожнага мерапрыемства. Абноўлены чарнавік спецыфікацыі, набор тэстаў і план тэсціравання ВГД, якія выкарыстоўваюцца падчас тэсціравання ВГД, павінны быць даступныя па меншай меры за тыдзень да кожнага мерапрыемства.

Падчас тэсціравання ВГД парныя камбінацыі платформ будуць спрабаваць выканаць тэсты, а ўдзельнікі тэсціравання ВГД будуць запісваць вынікі "прайдзены/неправедзены" кожнага тэсту і каментарыі. Ананімнае рэзюмэ гэтых вынікаў (са спасылкай, напрыклад, на «Платформу A», «Платформу B» і г.д.) і любыя каментарыі будуць збірацца падчас выпрабаванняў IOP і прадастаўляцца членам РГ падчас і пасля IOP выпрабавальнае мерапрыемства. У выпадку, калі патрабуецца дадатковая інфармацыя для лепшага разумення любых каментарыяў або збояў, якія адбыліся падчас тэсціравання ВГД, BSTS можа выступаць у якасці пасярэдніка для збору дадатковай інфармацыі ад удзельніка, які падае заяўку.

Калі магчыма, PTS варта абнавіць для падтрымкі тэсціравання IOP з платформамі на ўсіх узроўнях, вышэйшых за інтэрфейс хост-кантролера (HCI), і прысутнічаць на мерапрыемствах тэсціравання IOP для гэтых узроўняў. Іншыя інструменты тэсціравання таксама могуць прысутнічаць на мерапрыемствах тэсціравання ВГД. Рэзюмэ вынікаў тэсціравання з дапамогай PTS або іншых інструментаў тэсціравання (калі такія маюцца) павінна быць уключана ў пратакол тэсціравання ВГД.

Тэставанне IOP будзе адкрыта для ўсіх удзельнікаў, якія жадаюць забяспечыць рэалізацыю прататыпа, аднак Bluetooth SIG можа абумовіць удзел прыняццем пагадненняў з Bluetooth SIG (уключаючы пагадненні аб удзеле і канфідэнцыяльнасці). Рабочая група адказвае за апрацоўку і вырашэнне праблем, выяўленых падчас тэсціравання ВГД, і абнаўленне закранутых дакументаў; Зацверджаныя рабочай групай змены павінны быць уключаны ў якасці абнаўленняў у праект спецыфікацыі і тэставых дакументаў для выкарыстання пры кожным тэсціраванні ВГД.

Перад этапам праверкі рабочыя групы могуць правесці папярэдняе тэсціраванне ВГД на мерапрыемствах, адкрытых толькі для членаў РГ, аднак вынікі неафіцыйнага тэсціравання могуць не быць уключаны ў вынікі тэсціравання ВГД.

Можа здарыцца так, што выкананы ўсе крокі да першага тэсціравання ВГД, у тым ліку абвешчаная дата і месца правядзення тэсціравання ВГД з намерам пачаць тэсціраванне ВГД, але адабрэнне Савета дырэктараў не было атрымана да пачатку тэсціравання. У гэтым выпадку Рада дырэктараў можа дазволіць уключэнне вынікаў тэстаў, якія былі сабраныя да зацвярджэння Радай дырэктараў на пачатак тэсціравання ВГД, пры ўмове, што сабраныя вынікі грунтуюцца на той жа спецыфікацыі і наборы тэстаў, зацверджаных Радай дырэктараў.

Тэставанне IOP не патрабуецца для ўдасканалення спецыфікацый CSS, GSS або MDP.

Справаздача аб выпрабаванні ВГД
Пасля завяршэння тэставання IOP рабочая група павінна прадставіць справаздачу аб выпрабаванні IOP у BARB з мэтай прадэманстраваць, што неабходная колькасць незалежных платформаў прайшла неабходныя выпрабаванні. БАРБ мусіць пераview а таксама зацвердзіць або адхіліць справаздачу аб выпрабаванні ВГД і паведаміць рабочай групе, калі спатрэбіцца дадатковае тэсціраванне ВГД перад адпраўкай пакета спецыфікацый праекта галасавання ў Савет дырэктараў. BSTS і рабочая група павінны пераканацца, што ў справаздачы аб выпрабаванні ВГД не з'явіцца інфармацыя, якая ідэнтыфікуе члена, перш чым адправіць справаздачу ў BARB.

Справаздача аб выпрабаванні ВГД павінна ўключаць:

• Спіс усіх падзей тэсціравання ВГД, якія адбыліся на этапе праверкі, уключаючы іх даты і месцы.
• Колькасць кампаній-членаў і незалежных платформаў, якія ўдзельнічалі ў кожным мерапрыемстве IOP, у тым ліку пра тое, ці выкарыстоўваўся PTS.
• Спіс спецыфікацый, пакета тэстаў і версій плана тэсціравання IOP, якія выкарыстоўваюцца на кожным мерапрыемстве.
• Рэзюмэ, якое паказвае, ці адпавядаюць усе тэставыя прыклады мінімальным крытэрам.
• Рэзюмэ ўсіх адхіленняў ад патрабаванняў плана тэсціравання ВГД, вызначаных у раздзеле 4.3.1, і абгрунтаванне кожнага адхілення.
• Рэзюмэ ахопу PTS для тэставых прыкладаў у Test Suite.
• Спіс усіх тэстаў (уключаючы тэсты зваротнай сумяшчальнасці) з плана тэсціравання IOP, колькасць праходжанняў тэстаў, колькасць няўдач тэстаў і тое, ці былі выкананы мінімальныя крытэрыі для кожнага тэсту, уключаючы тлумачэнне таго, чаму якія-небудзь патрабаванні не былі выкананы сустрэў.
• Кароткі выклад праблем, каментарыяў і пытанняў на кожным мерапрыемстве (уключаючы тыя filed супраць спецыфікацыі падчас тэсціравання ВГД) ​​і ўплыў на спецыфікацыю і тэставыя дакументы.

5.2 Патрабаванні да выхаду з фазы праверкі

Фаза праверкі завершана, і фаза зацвярджэння/прыняцця пачынаецца, калі BARB зацвердзіць справаздачу аб выпрабаванні ВГД (калі толькі BARB не адмовілася ад тэставання) і будуць выкананы ўсе наступныя патрабаванні:

• BSTS зрабіла зацверджаную спецыфікацыю 0.9/CR даступнай для ўсіх удзельнікаў Member Review у адпаведнасці з патрабаваннямі Статута і апавясціў усіх членаў аб яго наяўнасці.
• Усе праблемы, выяўленыя падчас тэсціравання ВГД і якія аказваюць уплыў на тэставанне, былі ўключаны і пратэставаны.
• WG завяршыла тэсціраванне ВГД (калі BARB не адмяніў тэставанне).

 

6. Фаза прыняцця/зацвярджэння

На этапе прыняцця/зацвярджэння спецыфікацыі і звязаныя з імі тэставыя дакументы завяршаюцца, атрымліваюцца адабрэнні BARB, BQRB і BTI, выдаецца паведамленне аб прапанаванай даце прыняцця разам з канчатковай версіяй праекта спецыфікацыі, якая прадстаўляецца ў Савет дырэктараў на прыняцце ( Праект галасавання), а канчатковы пакет спецыфікацый перадаецца ў Савет дырэктараў. Пасля мінімальнай працягласці Member Review патрабаванне Статута [2]) было задаволена, Савет дырэктараў разгледзіць спецыфікацыю для прыняцця ў Дату прыняцця. Пасля прыняцця спецыфікацыя публікуецца і сістэма кваліфікацыі ўключана. Этап прыняцця/зацвярджэння паказаны на малюнку 6.1.

6.1 Праект галасавання

Праект для галасавання ствараецца шляхам уключэння абнаўленняў (прадстаўленых на этапе праверкі) у неабходныя дакументы спецыфікацыі і падрыхтоўкі канчатковага чарнавіка новай спецыфікацыі. Для паляпшэння спецыфікацыі BSTS створыць інтэграваную спецыфікацыю шляхам інтэграцыі аднаго або некалькіх CR у раней прынятую больш высокую версію спецыфікацыі (гл. Раздзел 4.3.2), калі гэта яшчэ не завершана да фазы праверкі.

Калі на гэтай фазе ў спецыфікацыі ўнесены змены і РГ, BARB або BTI вызначаць, што любое змяненне патрабуе дадатковага тэсціравання ВГД, спецыфікацыя вернецца да часткі тэсціравання ВГД на этапе праверкі, каб РГ магла правесці дадатковыя тэсты. Падчас этапу прыняцця/зацвярджэння наступныя дакументы будуць завершаны і прадстаўлены Савету дырэктараў да даты прыняцця:

• Праект для галасавання
• Усе дапаможныя спецыфікацыі (напрыклад, CSS, GSS, MDP), неабходныя для адпаведнага тыпу спецыфікацыі (або паляпшэння), калі не былі прыняты раней
• Для ўдасканалення спецыфікацый - версія прынятай версіі спецыфікацыі з адсочваннем змяненняў, якая паказвае змены, прапанаваныя ў праекце для галасавання
• Апісанне РГ любых патрабаванняў да зваротнай сумяшчальнасці (як апісана ў Раздзеле 3.3.2), якія не былі выкананы, і абгрунтаванне любых выключэнняў
• Апісанне рабочай групы любых патрабаванняў плана тэсціравання ВГД (як апісана ў Раздзеле 4.3.1), якія не былі выкананы, і абгрунтаванне любых адхіленняў разам са справаздачай аб выпрабаванні ВГД (якая можа быць прадастаўлена шляхам прадастаўлення спасылкі на копію на Bluetooth SIG webсайт)
• Рэкамендацыя рабочай групы аб спыненні або адкліканні любой папярэдняй(-ых) версіі(-й) прынятай спецыфікацыі разам з абгрунтаваннем, якое падкрэслівае змены пасля 0.9/CR Stagе рэкамендацыя па заканчэнні жыцця
• Рэзюмэ, падрыхтаванае рабочай групай, змяненняў у асаблівасцях або функцыянальнасці пасля спецыфікацыі 0.9/CR (калі ёсць)
• Рэзюмэ, падрыхтаванае BARB, аб занепакоенасці членаў BARB аб тым, што спецыфікацыя, створаная рабочай групай, выходзіць за рамкі статута, зацверджанага Саветам дырэктараў (калі ёсць)
• Спіс застаўшыхся нявырашаных прававых пытанняў з юрыдычнага рэview (калі ёсць)
• Тэставы пакет, зацверджаны BTI, разам з зацверджаным WG рэзюмэ тэставага ахопу спецыфікацыі праекта галасавання. У выпадку нядаўна дададзенай або змененай функцыі без тэставага пакрыцця патрабуецца пісьмовае абгрунтаванне пропуску
• ICS і IXIT, зацверджаныя BTI (калі гэтага патрабуе спецыфікацыя)
• TCRL ухвалены BTI і BQRB
• Справаздача, падрыхтаваная BSTS сумесна з BTI адносна стану гатоўнасці інструментаў (напрыклад, PTS і іншых інструментаў тэсціравання, Bluetooth Launch Studio), у тым ліку, калі якія-небудзь тэставыя прыклады ў TCRL не падтрымліваюцца інструментамі тэсціравання
• Рэзюмэ, падрыхтаванае РГ, усіх неабходных прысвоеных нумароў
• Кантрольны спіс усынаўлення, падрыхтаваны BSTS і рабочай групай, паказвае, што ўсе вынікі ў гэтым раздзеле выкананы
• Уся іншая інфармацыя, якую запытвае Савет дырэктараў

На этапе прыняцця/зацвярджэння рабочая група павінна выкарыстоўваць сістэму адсочвання праблем Bluetooth SIG, каб фіксаваць праблемы і каментарыі да чарнавіка спецыфікацыі і тэставых дакументаў, каб яны былі ўлічаны пры дапрацоўцы чарнавіка спецыфікацыі для галасавання. Для паляпшэння спецыфікацый усе адпаведныя зацверджаныя памылкі (г.зн. тыя зацверджаныя памылкі, якія яшчэ не інтэграваныя) павінны быць уключаны і павінны быць ідэнтыфікаваны з дапамогай адсочваных змяненняў.

Рабочая група павінна падаць канчатковы праект спецыфікацыі ў BSTS для юрыдычнага разглядуview. Для новых спецыфікацый, прававой рэview будзе ўключаць у сябе ўсю спецыфікацыю. Для паляпшэння спецыфікацый, review у першую чаргу будзе сканцэнтравана на змененых частках спецыфікацыі. Мэтай прававой рэview у першую чаргу заключаецца ў выяўленні прававых рызык, якія рабочая група павінна разгледзець і імкнуцца вырашыць. Прававыя водгукі будуць класіфікаваны ў залежнасці ад сур'ёзнасці. Калі неабавязковы юрыдычны рэview быў выкананы пры 0.9/CR Stage, версія, якая прадстаўлена на юрыдычны паўторview павінны паказваць у якасці адсочваных змяненняў усе змены, зробленыя пасля гэтай версіі (згенераваныя РГ або BSTS). Пасля завяршэння судовага рэview, рабочая група і BSTS дамовяцца аб уключэнні водгукаў у праект спецыфікацыі. Калі ёсць якія-небудзь нявырашаныя юрыдычныя заўвагі ад юрыдычнага рэview па праекце спецыфікацыі, старшыня рабочай групы можа запытаць час на парадак дня Савета дырэктараў для ўзгаднення рашэння.

Паралельна з юрыдычнымі рэview, рабочая група павінна прадставіць праект спецыфікацыі ў BARB для пераглядуview. Пасля першапачатковага прадстаўлення ў BARB BSTS паведаміць усім членам аб тым, што праект спецыфікацыі быў прадстаўлены ў BARB для пераглядуview і што ён таксама даступны для Member Review. Калі рабочая група прадставіць абнаўленні чарнавой спецыфікацыі для паўторнага пераўтварэння BARBviewBSTS будзе перыядычна адпраўляць дадатковыя паведамленні ўсім членам.

Пасля завяршэння BARB review, WG і BARB дамовяцца аб тым, што водгукі будуць уключаны ў праект спецыфікацыі.

Калі юрыдычная рэview прыводзіць якія-небудзь істотныя змены, дадатковыя рэview by BARB можа спатрэбіцца. Сапраўды гэтак жа, калі BARB review прывядзе да якіх-небудзь змяненняў па сутнасці, BSTS будзе вызначаць, калі дадатковая юрыдычная справаview гэтых змяненняў патрабуецца. Пасля завяршэння судовага рэview і БАРБ рэview, BARB павінен альбо зацвердзіць, альбо адхіліць праект для галасавання.

Калі якія-небудзь тэставыя дакументы патрабуюць абнаўлення, BSTS дапаможа РГ у абнаўленні тэставых дакументаў. БТІ павінна альбо зацвердзіць, альбо адхіліць дакументы праверкі. У выпадку зацвярджэння BTI BTI дапаможа ў дапрацоўцы TCRL і даставіць гэты дакумент у BQRB разам з адпаведнымі ICS, IXIT і Test Suite. BSTS вызначыць дату пасяджэння Савета дырэктараў, калі Савет мае намер правесці галасаванне па прыняцці праекта для галасавання (Дата прыняцця), і прадаставіць яго БТІ для выкарыстання ў TCRL. Зацвярджэнне спецыфікацыі BARB, зацвярджэнне BTI ўсіх тэставых дакументаў (уключаючы Набор тэстаў, TCRL, ICS і IXIT) і зацвярджэнне TCRL BQRB павінны адбыцца не пазней за Дату прыняцця.

BSTS праінфармуе ўсіх членаў аб завяршэнні і наяўнасці праекта для галасавання і даты прыняцця. Дата прыняцця будзе ўстаноўлена не раней, чым праз 60 дзён пасля паведамлення членам аб зацверджанай Саветам дырэктараў спецыфікацыі 0.9/CR, за выключэннем выпадкаў, калі член Review тэрмін скарачаецца Саветам дырэктараў у адпаведнасці са Статутам і не менш чым праз 14 дзён пасля паведамлення аб Даце прыняцця членам у адпаведнасці са Статутам. У выпадках, калі некалькі CR былі інтэграваныя ў праект для галасавання, пачатак Member Review гэта дата, калі члены былі апавешчаныя аб апошнім CR, зацверджаным Саветам дырэктараў.

Пасля паведамлення аб даце прыняцця членам дазваляецца зацверджанае Саветам дырэктараў выпраўленне памылак друку ў праекце для галасавання. Графік прыняцця спецыфікацыі паказаны на малюнку 6.2.

6.2 Прысвоеныя нумары

Bluetooth SIG падтрымлівае агульнадаступны набор прызначаных нумароў на Bluetooth SIG Assigned Numbers webсайт [7]. Гэтыя прызначаныя нумары згрупаваны ў розных лічбавых прасторах (звязаны набор лікаў без дублікатаў). Прызначаныя нумары могуць накладацца на іншыя прызначаныя нумары ў розных лічбавых прасторах, але паўторнае выкарыстанне нумароў у лікавай прасторы забараняецца. Розныя нумарныя прасторы вызначаны ў спецыфікацыі, якая вызначае выкарыстанне прызначаных нумароў.

Пасля таго як BARB зацвердзіць справаздачу аб выпрабаванні ВГД, рабочая група адправіць у BARB запыт на прысваенне новых нумароў у межах нумароў, неабходных канчатковай спецыфікацыі. БАРБ будзе паўторнаview запыт і праца з BSTS для вызначэння прысвоеных нумароў. Пасля зацвярджэння BARB BSTS заплануе публікацыю прызначаных нумароў, якія будуць агульнадаступнымі на Bluetooth SIG Assigned Numbers webсайт [7] на працягу тыдня пасля прыняцця спецыфікацыі.

Пасля публікацыі прызначаных нумароў на Bluetooth SIG Assigned Numbers webна сайце або ў рамках прынятай спецыфікацыі, прысвоеныя нумары павінны быць нязменнымі (не змяняць ні значэнне, ні значэнне). Калі яны становяцца непрыдатнымі для выкарыстання па нейкай прычыне, яны становяцца зарэзерваванымі каштоўнасцямі і не дапускаюцца для паўторнага выкарыстання.

6.3 Патрабаванні да выхаду з фазы прыняцця/зацвярджэння

Этап зацвярджэння/прыняцця завершаны, калі Савет дырэктараў прыняў спецыфікацыю і былі выкананы наступныя дзеянні пасля прыняцця:

• BSTS зрабіў канчатковыя прызначаныя нумары агульнадаступнымі на Bluetooth SIG webсайт.
• BSTS зрабіў прынятую спецыфікацыю агульнадаступнай на Bluetooth SIG webсайт
• BSTS зрабіў усе пацвярджаючыя дакументы (напрыклад, CSS, GSS, MDP), неабходныя для адпаведнай спецыфікацыі, агульнадаступнымі на Bluetooth SIG webсайт.
• BSTS зрабіў адпаведныя тэставыя дакументы даступнымі для ўсіх удзельнікаў Bluetooth SIG webсайт.
• Для ўдасканалення спецыфікацый BSTS зрабіла інфарматыўную версію раней прынятай версіі спецыфікацыі з адсочваннем змяненняў з усімі зменамі, зробленымі нядаўна прынятай версіяй, і зрабіла яе даступнай для ўсіх удзельнікаў Bluetooth SIG webсайт.
• BSTS ўключыў сістэму кваліфікацыі.
• BSTS апавясціла ўсіх членаў аб наяўнасці прынятай спецыфікацыі і ўсіх суправаджальных дакументаў.

Bluetooth SIG плануе завяршыць гэтыя дзеянні пасля прыняцця на працягу тыдня пасля прыняцця спецыфікацыі.

 

7. Фаза абслугоўвання спецыфікацый

Фаза абслугоўвання спецыфікацый пачынаецца пасля завяршэння фазы прыняцця/зацвярджэння. Пры выяўленні праблем (напрыклад, неадназначнасці фармулёвак або тэхнічных памылак) са спецыфікацыяй або звязанымі тэставымі дакументамі, яны павінны быць задакументаваны шляхам стварэння прапаноў па памылках з дапамогай інструмента Bluetooth SIG Errata. Прапановы аб памылках у спецыфікацыях будуць апрацаваны, класіфікаваны і зацверджаны ў адпаведнасці з EPD [3]. Памылкі набора тэстаў апрацоўваюцца і класіфікуюцца ў адпаведнасці з TSTO [5]. Калі ёсць якія-небудзь канфлікты паміж SMPD і EPD або TSTO, SMPD мае перавагу.

Памылка спецыфікацыі павінна выкарыстоўвацца толькі для выпраўлення тэхнічных або рэдакцыйных памылак у канчаткова прынятых спецыфікацыях Bluetooth. Даданне, змяненне і выдаленне функцыянальнасці можа быць зроблена толькі з дапамогай працэсу паляпшэння спецыфікацый, вызначанага раней у гэтым дакуменце.

7.1 Паскораны працэс выпраўлення памылак

Калі памылка зацверджана ў адпаведнасці з працэсам, вызначаным у EPD [3], WG, BARB або BSTS могуць рэкамендаваць лічыць яе тэрміновай і паскорыць. Калі гэта адбудзецца, BSTS разам з рабочай групай або BARB прадставяць рэкамендацыі радзе дырэктараў. Савет дырэктараў вырашыць, прыняць ці адхіліць рэкамендацыю. Калі рэкамендацыя будзе прынята, BSTS неадкладна ўключыць зацверджаную памылку ў шаблон памылак [8] і будзе працаваць з адказнай рабочай групай, каб завяршыць паскоранае выпраўленне выпраўленняў, якое будзе перададзена ў РГ для перагляду.view і адабрэнне.

Надview паскоранага працэсу выпраўлення паказана на малюнку 7.1.

Наступныя дакументы павінны быць завершаны і прадастаўлены Савету дырэктараў да даты прыняцця:

• Ухвалены BARB праект паскоранага выпраўлення памылак.
• Апісанне РГ любых патрабаванняў да зваротнай сумяшчальнасці (як апісана ў раздзеле 3.3.2), якія не былі выкананы, і абгрунтаванне любых выключэнняў.
• Спіс застаўшыхся нявырашаных прававых пытанняў з юрыдычнага рэview (калі ёсць).
• Набор тэстаў, зацверджаны BTI, ICS і IXIT (калі гэтага патрабуе памылка).
• TCRL, зацверджаны BTI і BQRB (калі гэтага патрабуе памылка).
• Справаздача, складзеная BSTS разам з BTI адносна стану гатоўнасці інструментаў (напрыклад, PTS і іншых тэставых інструментаў, Bluetooth Launch Studio), у тым ліку, ці не падтрымліваюцца тэставыя прыклады ў TCRL інструментамі тэсціравання, і тлумачэнне (калі гэтага патрабуе памылка ).
• Кантрольны спіс усынаўлення, завершаны BSTS і WG, які паказвае, што вынікі ў гэтым раздзеле выкананы.
• Уся іншая інфармацыя, якую запытвае Савет дырэктараў.

BSTS будзе працаваць з адказнай рабочай групай, каб дапрацаваць праект паскоранага выпраўлення памылак і стварыць версію для перадачы адказнай рабочай групе для пераглядуview і адабрэнне.

Рабочая група павінна падаць паскоранае выпраўленне памылак у BSTS для судовага разглядуview. Пасля завяршэння судовага рэview, рабочая група і BSTS дамовяцца аб тым, што водгукі будуць уключаны ў паскоранае выпраўленне памылак. Калі ёсць якія-небудзь нявырашаныя юрыдычныя заўвагі ад юрыдычнага рэview што тычыцца паскоранага выпраўлення памылак, старшыня рабочай групы можа запытаць час для ўключэння ў парадак дня Савета дырэктараў, каб запытаць меркаванне Савета дырэктараў па рашэнні.

Паралельна з юрыдычнымі рэview, рабочая група павінна накіраваць у BARB паскоранае выпраўленне памылакview. Пасля таго, як паскоранае выпраўленне памылак будзе адпраўлена ў BARB, BSTS зробіць яго даступным для ўсіх удзельнікаў, кабview і паведаміць усім членам аб яго даступнасці. Пасля завяршэння BARB review, рабочая група і BARB дамовяцца аб тым, што водгукі будуць уключаны ў паскоранае выпраўленне памылак.

Калі юрыдычная рэview прыводзіць якія-небудзь істотныя змены, дадатковыя рэview by BARB можа спатрэбіцца. Сапраўды гэтак жа, калі BARB review прывядзе да якіх-небудзь змяненняў па сутнасці, BSTS будзе вызначаць, калі дадатковая юрыдычная справаview гэтых змяненняў патрабуецца. Пасля завяршэння судовага рэview і БАРБ рэview, BARB павінен зацвердзіць або адхіліць паскоранае выпраўленне памылак.

Калі якія-небудзь тэставыя дакументы патрабуюць абнаўлення, BSTS дапаможа РГ у абнаўленні тэставых дакументаў. Пасля зацвярджэння BTI тэставых дакументаў BTI дапаможа ў дапрацоўцы TCRL і даставіць дакумент у BQRB разам з адпаведнымі ICS, IXIT і Test Suite, калі гэта дастасавальна. BSTS ацэніць дату прыняцця і перадасць яе BTI для выкарыстання ў TCRL. Зацвярджэнне BARB паскоранага выпраўлення памылак, зацвярджэнне BTI ўсіх тэставых дакументаў (уключаючы набор тэстаў, TCRL, ICS і IXIT, калі гэта дастасавальна) і зацвярджэнне TCRL BQRB павінны адбыцца не пазней за Дату прыняцця.

BSTS праінфармуе ўсіх членаў аб завяршэнні і даступнасці паскоранага выпраўлення памылак і прапанаванай даце прыняцця. Дата прыняцця будзе ўстаноўлена і паведамлена ўсім членам у адпаведнасці са Статутам [2], і дата прыняцця павінна быць не менш чым праз 14 дзён пасля паведамлення членам. Пасля паведамлення членам аб прапанаванай даце прыняцця Савет дырэктараў можа зацвердзіць выпраўленне памылак друку ў паскораным выпраўленні выпраўленняў без дадатковага паведамлення аб прапанаванай даце прыняцця і чакання неабходных 14 дзён.

Bluetooth SIG зробіць прынятае паскоранае выпраўленне выпраўленняў агульнадаступным і плануе зрабіць гэта на працягу тыдня пасля прыняцця. Паведамленне аб яго наяўнасці будзе выдадзена BSTS ўсім членам.

Паскораны працэс выпраўлення памылак завершаны, калі Савет дырэктараў прыняў Паскоранае выпраўленне выпраўленняў і былі завершаны наступныя дзеянні пасля прыняцця:

• BSTS зрабіў прынятае паскоранае выпраўленне памылак і адпаведныя тэставыя дакументы (калі гэтага патрабуе памылка) у адкрытым доступе на Bluetooth SIG webсайт.
• BSTS уключыў сістэму кваліфікацыі (калі гэтага патрабуе памылка).
• BSTS апавясціла ўсіх членаў аб наяўнасці прынятага паскоранага выпраўлення памылак.

Пасля завяршэння гэтых мерапрыемстваў выпраўленне памылак будзе запланавана для інтэграцыі ў закранутыя спецыфікацыі альбо ў рамках запланаванага ўдасканалення спецыфікацый, альбо ў наступным выпуску для абслугоўвання, як апісана ў Раздзеле 7.2.

7.2 Працэс выпуску для абслугоўвання (спецыфікацыі .Z)

Прыблізна кожны год BSTS будзе вызначаць, ці ёсць якія-небудзь зацверджаныя выпраўленні (так званыя выпраўленні выпраўленняў), класіфікаваныя як тэхнічныя/высокія або тэхнічныя/крытычныя і якія яшчэ не ўключаны ў тэкст якой-небудзь дзеючай спецыфікацыі (напрыклад, прынятая спецыфікацыя, якая не была састарэлай або адкліканай). Глядзіце Дадатак A для вызначэння класіфікацыі памылак. Уладальнік спецыфікацыі (альбо рабочая група, упаўнаважаная для падтрымання спецыфікацыі, альбо BARB, калі ніякая рабочая група не ўпаўнаважана падтрымліваць спецыфікацыю), можа таксама запытаць больш ранні выпуск актыўнай спецыфікацыі для абслугоўвання, у якую можна ўключыць любыя зацверджаныя памылкі. Пасля вызначэння BSTS або запыту ўладальніка спецыфікацыі пачнецца працэс выпуску тэхнічнага абслугоўвання.

Надview працэсу выпуску абслугоўвання паказана ў Памылка! Крыніца спасылкі не знойдзена.

У пачатку працэсу выпуску тэхнічнага абслугоўвання BSTS разам з уладальнікам спецыфікацыі, BARB і BTI распрацуюць і прадставяць радзе дырэктараў план па ўключэнні выпраўленняў выпраўленняў у апублікаваную версію спецыфікацыі. У прапанаваным плане павінна быць указана, ці будуць выпраўленні выпраўленняў уключаны ў тэхнічны выпуск спецыфікацыі (напрыклад, у версію .Z) або ў паляпшэнне спецыфікацыі, якое ўжо знаходзіцца ў стадыі выканання (напрыклад, у версію XY). Прапанаваны план павінен улічваць, ці былі дададзены новыя абавязковыя функцыі паміж версіямі прынятых спецыфікацый, разліковы час, калі плануецца прыняцце наступнага ўдасканалення спецыфікацый, і іншыя фактары.

Пасля зацвярджэння плана Саветам дырэктараў BSTS разам з уладальнікам спецыфікацый прыступяць да ўключэння ўсіх тэхнічных/сярэдніх, тэхнічных/высокіх і тэхнічных/крытычных выпраўленняў памылак у чарнавік спецыфікацыі, які называецца «Праект выпуску для абслугоўвання». Для рэдакцыйных або тэхнічных/нізкіх выпраўленняў выпраўленняў, калі выпраўленні выпраўленняў прымяняюцца да больш чым адной версіі спецыфікацыі, BSTS будзе, калі Рада дырэктараў не пакажа іншага, інтэграваць гэтыя выпраўленні толькі ў самую апошнюю больш высокую версію спецыфікацыі пры наступным абнаўленні гэтай версіі . Ніякія змены не могуць быць уключаны ў чарнавік выпуску абслугоўвання, акрамя ўключэння выпраўленняў выпраўленняў. Кожны чарнавік выпуску абслугоўвання павінен ідэнтыфікаваць усе ўключаныя выпраўленні выпраўленняў з дапамогай адсочвання змяненняў, каб паказаць прапанаваныя змены ў раней прынятай версіі апублікаванай спецыфікацыі.

Час прапанаванага ўключэння для кожнага выпраўлення выпраўленняў у чарнавік выпуску абслугоўвання будзе залежаць ад уплыву на набор тэстаў: усе выпраўленні выпраўленняў, якія не аказваюць уплыву на набор тэстаў, могуць быць уключаны адразу, але выпраўленні выпраўленняў, якія ўплываюць на набор тэстаў, будуць уключаны. апрацоўваюцца такім чынам, каб час супадаў з абнаўленнем TCRL.

BTI і BSTS усталююць крайні тэрмін для ўключэння выпраўленняў выпраўленняў з уплывам набору тэстаў у чарнавік выпуску абслугоўвання. Гэты тэрмін звычайна складае ад 3 да 6 месяцаў да запланаванай даты зацвярджэння наступнага буйнога выпуску TCRL. Выпраўленні памылак з уплывам Test Suite, якія прапусцілі крайні тэрмін для ўключэння, будуць апрацаваны ў рамках наступнага штогадовага выпуску TCRL. Такім чынам, калі не запытваецца больш ранні выпуск, максімальны час для ўключэння выпраўленняў тэхнічных/высокіх або тэхнічных/крытычных памылак у абнаўленне спецыфікацыі складае прыблізна ад 15 да 18 месяцаў.

Уладальнік спецыфікацый павінен падаць праект выпуску тэхнічнага абслугоўвання, які ён зацвердзіў як канчатковы, для судовага пераглядуview. Юрыдычная рэview у першую чаргу будзе сканцэнтравана на змененых частках спецыфікацыі. Пасля завяршэння судовага рэview, уладальнік спецыфікацый і BSTS дамовяцца аб тым, што водгукі будуць уключаны ў чарнавік выпуску абслугоўвання. Калі ёсць якія-небудзь нявырашаныя юрыдычныя заўвагі ад юрыдычнага рэview у праекце выпуску тэхнічнага абслугоўвання Уладальнік спецыфікацый можа запытаць час для ўключэння ў парадак дня Савета дырэктараў, каб запытаць меркаванне Савета дырэктараў па рашэнні.

Паралельна з юрыдычнымі рэview, уладальнік спецыфікацыі павінен адправіць праект выпуску абслугоўвання ў BARB для паўторнага разглядуview. Пасля таго як чарнавік выпуску абслугоўвання будзе прадстаўлены ў BARB, BSTS зробіць яго даступным для ўсіх удзельнікаўview і паведаміць усім членам аб яго даступнасці. Пасля завяршэння BARB review, уладальнік спецыфікацыі і BARB дамовяцца аб уключэнні водгукаў у чарнавік спецыфікацыі.

Калі юрыдычная рэview прыводзіць якія-небудзь істотныя змены, дадатковыя рэview by BARB можа спатрэбіцца. Сапраўды гэтак жа, калі BARB review прывядзе да якіх-небудзь змяненняў па сутнасці, BSTS будзе вызначаць, калі дадатковая юрыдычная справаview гэтых змяненняў патрабуецца. Пасля завяршэння судовага рэview і БАРБ рэview, BARB павінен зацвердзіць або адхіліць чарнавік выпуску абслугоўвання. У выпадку зацвярджэння BARB гэта становіцца праектам для галасавання.

Для выпраўленняў выпраўленняў, якія ўплываюць на тэставыя дакументы, і калі адпаведныя выпраўленні тэстаў будуць апрацаваны да будучага выпуску TCRL, BSTS будзе працаваць з уладальнікам спецыфікацый і BTI для абнаўлення тэставых дакументаў. Пасля зацвярджэння BTI тэставых дакументаў BSTS ацэніць дату прыняцця і прадаставіць BTI прапанаваную дату прыняцця для выкарыстання ў TCRL. BTI даставіць TCRL у BQRB разам з адпаведнымі ICS, IXIT і Test Suite, калі гэта дастасавальна. Зацвярджэнне спецыфікацыі BARB, зацвярджэнне BTI ўсіх тэставых дакументаў (уключаючы Набор тэстаў, TCRL, ICS і IXIT, калі гэта дастасавальна) і зацвярджэнне TCRL BQRB павінны адбыцца не пазней за Дату прыняцця.

BSTS праінфармуе ўсіх членаў аб завяршэнні і наяўнасці праекта для галасавання і прапанаванай даты прыняцця. Дата прыняцця будзе ўстаноўлена і паведамлена ўсім членам у адпаведнасці са Статутам, і дата прыняцця павінна быць не менш чым праз 14 дзён пасля таго, як членам будзе прадастаўлена апавяшчэнне. Пасля паведамлення членам аб прапанаванай даце прыняцця Савет дырэктараў можа зацвердзіць выпраўленні памылак друку ў праекце для галасавання без дадатковага паведамлення аб прапанаванай даце прыняцця і чакання неабходных 14 дзён.

Наступныя дакументы павінны быць завершаны і прадастаўлены Савету дырэктараў да даты прыняцця:

• Праект для галасавання
• Версія праекта для галасавання з адсочваннем змяненняў, якая паказвае ўсе змены ў прынятай версіі спецыфікацыі, якая мае аднолькавае значэнне XY (напрыклад, калі праект для галасавання прапануецца як версія 1.4.2, змены будуць адсочвацца ў параўнанні з версіяй 1.4.1 версія спецыфікацыі)
• Рэкамендацыя Уладальніка спецыфікацыі аб спыненні або адкліканні любой папярэдняй версіі(-й) прынятай спецыфікацыі разам з абгрунтаваннем
• Спіс застаўшыхся нявырашаных прававых пытанняў з юрыдычнага рэview (калі ёсць)
• Зацверджаны BTI набор тэстаў, ICS і IXIT (калі гэта патрабуецца ў адпаведнасці з версіяй тэхнічнага абслугоўвання)
• TCRL, зацверджаны BTI і BQRB (калі гэтага патрабуе рэліз тэхнічнага абслугоўвання)
• Справаздача, складзеная BSTS разам з BTI, адносна стану гатоўнасці інструментаў (напрыклад, PTS і іншых тэставых інструментаў, Bluetooth Launch Studio), уключаючы любыя тэставыя прыклады ў TCRL, якія не падтрымліваюцца тэставымі інструментамі, і тлумачэнне (калі патрабуецца для абслугоўвання рэліз)
• Кантрольны спіс прыняцця, завершаны BSTS і ўладальнікам спецыфікацый, які паказвае, што вынікі ў гэтым раздзеле выкананы
• Уся іншая інфармацыя, якую запытвае Савет дырэктараў

Працэс выпуску тэхнічнага абслугоўвання завершаны, калі Савет дырэктараў прыняў праект для галасавання і наступныя дзеянні пасля прыняцця былі завершаны:

• BSTS зрабіў прынятую спецыфікацыю і звязаныя з ёй тэставыя дакументы (калі гэтага патрабуе рэліз тэхнічнага абслугоўвання) агульнадаступнымі на Bluetooth SIG webсайт.
• BSTS зрабіў інфармацыйную версію раней прынятай версіі спецыфікацыі з адсочваннем змяненняў з усімі зменамі, уключанымі ў новую версію, даступнай для ўсіх удзельнікаў Bluetooth SIG webсайт.
• BSTS ўключыў сістэму кваліфікацыі.
• БДСТ апавясціла ўсіх членаў аб наяўнасці прынятага тэхнічнага задання і суправаджальных дакументаў.

Bluetooth SIG плануе завяршыць гэтыя дзеянні пасля прыняцця на працягу тыдня пасля прыняцця спецыфікацыі.

Пасля завяршэння гэтых дзеянняў спецыфікацыя застаецца на этапе абслугоўвання спецыфікацыі, пакуль спецыфікацыя не будзе прызнана састарэлай або адменена, як гэта вызначана ў Раздзеле 8.

 

8. Спецыфікацыя Фаза заканчэння жыцця

Спецыфікацыі могуць быць састарэлымі або адкліканымі, калі яны заменены новымі версіямі, прызнаныя тэхнічна недастатковымі або па іншых прычынах. Састарэлыя і адкліканыя спецыфікацыі архівуюцца і больш не абнаўляюцца. Састарэлыя і адкліканыя спецыфікацыі разглядаюцца па-рознаму ў праграме кваліфікацыі Bluetooth.

Любы член, група або камітэт можа адправіць рэкамендацыі аб спыненні або адкліканні спецыфікацыі разам з адпаведным графікам у BSTS (па электроннай пошце на

specification.manager@bluetooth.com) у любы час. BSTS таксама можа рэкамендаваць састарэць або адклікаць спецыфікацыю і звязаныя з ёй тэрміны. BSTS перадасць рэкамендацыю BARB і групе або камітэту, адказным за захаванне спецыфікацыі для паўторнага выкарыстанняview і зваротная сувязь.

BARB і адказная група або камітэт ацэняць рэкамендацыі аб спыненні або адмене спецыфікацыі і разгледзяць наступныя (невычарпальныя) крытэрыі:

• Ці ёсць у папярэдняй версіі спецыфікацыі функцыі, якія састарэлі або не павінны выкарыстоўвацца?
• Ці былі дададзены новыя абавязковыя функцыі ў наступныя версіі?
• Ці ёсць недахопы ў больш ранніх версіях, якія пагаршаюць працу або ўзаемадзеянне, якія былі выпраўлены ў пазнейшых версіях і неабходныя для прасоўвання існуючых карыстальніцкіх сцэнарыяў?
• Ці ёсць дадатковыя функцыі ў пазнейшых версіях, неабходныя для прасоўвання новых карыстальніцкіх сцэнарыяў?
• Ці палепшылася зручнасць выкарыстання і сумяшчальнасць у пазнейшых версіях?
• Ці ёсць паляпшэнні бяспекі ў пазнейшых версіях?

BARB і адказная група або камітэт могуць прапанаваць альтэрнатыўную рэкамендацыю.

Пасля атрымання зваротнай сувязі ад BARB або групы або камітэта, адказных за захаванне спецыфікацыі, BSTS прадставіць рэкамендацыю(-і) і водгук на разгляд Савета дырэктараў. Савет дырэктараў можа запрасіць групу або камітэт, якія адказваюць за захаванне закранутых спецыфікацый, сустрэцца і абмеркаваць рэкамендацыі. Савет дырэктараў разгледзіць рэкамендацыі і водгукі і можа пагадзіцца з прапановай або змяніць яе. Савет дырэктараў будзе патрабаваць, каб BSTS паведаміла ўсім членам аб прапановах аб спыненні або адкліканні спецыфікацый і звязаных з імі тэрмінаў на працягу 30 дзёнview перыяд, каб дазволіць усім удзельнікам даць дадатковыя водгукі да прыняцця канчатковага рашэння.

Савет дырэктараў разгледзіць водгукі, атрыманыя ад членаў. Пасля таго, як Савет дырэктараў зацвердзіць спыненне або адкліканне спецыфікацыі, BSTS паведаміць усім членам аб рашэнні і звязаным з ім тэрмінам.

8.1 Састарэласць

Калі спецыфікацыя састарэла, адбудзецца наступнае:

• Спецыфікацыя больш не будзе абнаўляцца.
• Адказная рабочая група перазview усе нявырашаныя памылкі, напісаныя супраць састарэлай спецыфікацыі, каб вызначыць, ці прымяняюцца яны да іншых спецыфікацый. Выпраўленні могуць быць адхілены ў сістэме выпраўленняў і перапісаны ў адпаведнасці з прымянімымі спецыфікацыямі.
• WG або BSTS створаць памылкі, каб абнавіць любыя неабходныя спасылкі на састарэлыя спецыфікацыі ў іншых спецыфікацыях.
• BTI абновіць прыдатныя тэставыя дакументы, каб паказаць састарэласць спецыфікацыі.
• BSTS абновіць Bluetooth SIG webсайт з інструкцыямі адносна альтэрнатыўных спецыфікацый для выкарыстання.
• Новыя памылкі больш не могуць быць прадстаўлены ў адпаведнасці са састарэлай спецыфікацыяй.
• Спецыфікацыі не будуць спасылацца ні ў якіх будучых спецыфікацыях.
• BSTS заархівуе версію спецыфікацыі, пазначаную як састарэлую, для доступу ўдзельнікаў для гістарычных мэтаў.

8.2 Зняцце

Пасля таго, як спецыфікацыя будзе адклікана, у дадатак да крокаў, якія прымяняюцца для спынення падтрымкі, адбудзецца наступнае:

• БТІ абновіць прыдатныя тэставыя дакументы, каб паказаць адкліканне спецыфікацыі.
• BSTS абновіць Bluetooth SIG webсайт з інструкцыямі адносна альтэрнатыўных спецыфікацый для выкарыстання.
• BSTS будзе архіваваць версію спецыфікацыі, пазначаную як адкліканую, для доступу членаў для гістарычных мэтаў.

Савет дырэктараў можа прыняць рашэнне неадкладна адклікаць спецыфікацыю без папярэдняга адмены спецыфікацыі.

 

9. Працэс белай паперы

Белыя кнігі створаны выключна ў інфармацыйных мэтах. Наступны працэс тэхнічнага дакумента прымяняецца да ўсіх працоўных груп, EG, SG і камітэтаў Bluetooth. Гэты раздзел не адносіцца да інфармацыйных дакументаў для выкарыстання толькі ў Bluetooth SIG.

Гэты працэс паказаны на малюнку 9.1 ніжэй.

Перш чым якая-небудзь група або камітэт пачне працу над дакументам, які яны маюць намер апублікаваць Bluetooth SIG, група або камітэт падрыхтуе як прапанаванае абнаўленне статута, у якім дакладна вызначаецца прапанаваны змест дакумента, так і прэзентацыю прапановы дакумента.

Прэзентацыя тэхнічнай прапановы павінна ўключаць як мінімум:

• Патрэба ў белай паперы
• Рэзюмэ прапанаванага зместу белай паперы
• Тлумачэнне, чаму змесціва не рэкамендуецца ўключаць у спецыфікацыі
• Мэтавая аўдыторыя
• Любыя планы тэхнічнага абслугоўвання (напрыклад, разліковы час да наступнага выпуску гэтага тэхнічнага дакумента можа спатрэбіцца)
• Рэкамендацыі па апрацоўцы папярэдніх версій тэхнічнага дакумента, калі такія маюцца (напрыклад, архіваванне)

Абнаўленне статута і прэзентацыя прапановы па дакументах павінны быць прадстаўлены для BARB review. Пры паўторнымview і зацвярджэнне абнаўлення статута BARB, BSTS прадставіць абнаўленне статута ў Савет дырэктараў на зацвярджэнне разам з дапаможнай прэзентацыяй дакумента.

Калі Савет дырэктараў зацвердзіць абнаўленне статута, група або камітэт можа прыступіць да распрацоўкі Белай кнігі.

Калі група або камітэт завершыць распрацоўку тэхнічнай кнігі, BSTS выканае рэдакцыйную праверкуview для ўзгаднення з Кіраўніцтвам па складанні Bluetooth.

Пасля вырашэння каментарыяў BSTS група павінна падаць дакумент у BSTS для судовага разглядуview. Пасля завяршэння судовага рэview, група і BSTS дамовяцца аб тым, што водгукі будуць уключаны ў тэхнічную кнігу. Калі ёсць якія-небудзь нявырашаныя юрыдычныя заўвагі ад юрыдычнага рэview на белай паперы, старшыня групы можа запытаць час для ўнясення ў парадак дня Савета дырэктараў для атрымання ўкладу Савета дырэктараў па рашэнні.

Паралельна з юрыдычнымі рэview, група павінна прадставіць Белую кнігу ў BARB для пераафармленняview. У рамках іх рэview, BARB можа рэкамендаваць, ці трэба выдаліць якую-небудзь частку тэхнічнага дакумента з тэхнічнага дакумента і ўключыць яго ў спецыфікацыю ў адпаведнасці з працэсам, апісаным у раздзеле 3. BARB можа таксама прыняць рашэнне падаць тэхнічны дакумент іншым групам або камітэтам для пераглядуview. Пасля завяршэння BARB review, група і BARB дамовяцца аб тым, што водгукі будуць уключаны ў Белую кнігу.

Калі юрыдычная рэview прыводзіць якія-небудзь істотныя змены, дадатковыя рэview by BARB можа спатрэбіцца. Сапраўды гэтак жа, калі BARB review прывядзе да якіх-небудзь змяненняў па сутнасці, BSTS будзе вызначаць, калі дадатковая юрыдычная справаview гэтых змяненняў патрабуецца. Пасля завяршэння судовага рэview і БАРБ рэview, BARB павінен альбо зацвердзіць, альбо адхіліць Белую паперу.

Пасля зацвярджэння Белай кнігі BARB аўтарская група або камітэт прадстаўляе яе на зацвярджэнне Савету дырэктараў.

Працэс афармлення тэхнічнага дакумента завершаны, калі Савет дырэктараў зацвердзіў тэхнічны дакумент і былі выкананы наступныя дзеянні пасля зацвярджэння:

• BSTS зрабіў зацверджаную тэхнічную кнігу агульнадаступнай на Bluetooth SIG webсайт.
• BSTS паведамляе ўсім членам аб зацверджанай тэхнічнай паперы.
• Калі Белая кніга з'яўляецца ўдасканаленнем існуючай Белай кнігі, BSTS заархівуе версію Белай кнігі для доступу членаў для гістарычных мэтаў.

Bluetooth SIG плануе завяршыць дзейнасць пасля зацвярджэння на працягу аднаго тыдня пасля зацвярджэння тэхнічнага дакумента.

 

10. Спасылкі

Спасылкі на дакументы Bluetooth даступныя ў Bluetooth webсайт http://www.bluetooth.com.

1. Bluetooth Drafting Guidelines (даступна на старонцы шаблонаў і дакументаў працоўных груп па адрасе https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
2. Статут Bluetooth SIG, Inc. (даступны на старонцы кіруючых дакументаў па адрасе https://www.bluetooth.com/membership-working-groups/membership-types-levels/membership-agreements)
3. Bluetooth Specification Errata Process дакумент (даступны на старонцы шаблонаў і дакументаў рабочай групы па адрасе https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
4. Дакумент аб працэсе рабочай групы (даступны на старонцы шаблонаў і дакументаў рабочай групы па адрасе https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
5. Стратэгія тэсціравання і тэрміналогія скончаныview дакумент (даступны на старонцы патрабаванняў да кваліфікацыйных іспытаў, па адрасе https://www.bluetooth.com/specifications/qualification-test-requirements)
6. Спецыфікацыя BTI Review Кантрольны спіс працэсаў (даступны на старонцы шаблонаў і дакументаў працоўных груп па адрасе https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
7. Прызначаныя нумары Bluetooth SIG (https://www.bluetooth.com/specifications/assigned-numbers)
8. Шаблоны і дакументы працоўных груп (даступныя на старонцы шаблонаў і дакументаў працоўных груп па адрасе https://www.bluetooth.com/membership-working-groups/working-groups/working-group-templates-documents)
9. Дадатак да спецыфікацый GATT (GSS) (даступна на старонцы спецыфікацый GATT па адрасе https://www.bluetooth.com/specifications/gatt)
10. Адпраўце ідэю для новай спецыфікацыі https://www.bluetooth.com/specifications/submit-an-idea-for-a-specification

 

11. Акронімы і абрэвіятуры

Табліца A: Акронімы і абрэвіятуры

 

Дадатак A – Класіфікацыя сур'ёзнасці памылак

У гэтым дадатку зведзены рэкамендацыі па класіфікацыі ступені цяжкасці для памылак у спецыфікацыі. Гэтая табліца будзе дададзена ў будучую рэвізію EPD, пасля чаго гэты раздзел будзе выдалены.

 

Даведайцеся больш пра гэта кіраўніцтва і загрузіце PDF:

Дакумент працэсу кіравання спецыфікацыямі (SMPD) – Аптымізаваны pdf
Дакумент працэсу кіравання спецыфікацыямі (SMPD) – Арыгінальны PDF

Ёсць пытанні па дапаможніку? Пішыце ў каментарах!

Спасылкі

• Кіраўніцтва карыстальніка