Spesifikasi Dokumen Proses Manajemen (SMPD)

Dokumen ini, terlepas dari judul atau isinya, bukanlah Spesifikasi Bluetooth yang tunduk pada lisensi yang diberikan oleh Bluetooth SIG Inc. ("Bluetooth SIG") dan anggotanya di bawah Perjanjian Lisensi Paten / Hak Cipta Bluetooth dan Perjanjian Lisensi Merek Dagang Bluetooth.

DOKUMEN INI DISEDIAKAN "SEBAGAIMANA ADANYA" DAN BLUETOOTH SIG, ANGGOTANYA, SERTA AFILIASINYA TIDAK MEMBERIKAN PERNYATAAN ATAU JAMINAN DAN MENOLAK SEMUA JAMINAN, TERSURAT MAUPUN TERSIRAT, TERMASUK JAMINAN APA PUN BAGIAN DIPERDAGANGKAN, JUDUL, NON-PELANGGARAN BAHWA ISI DOKUMEN INI BEBAS DARI KESALAHAN.

SEJAUH TIDAK DILARANG OLEH HUKUM, BLUETOOTH SIG, ANGGOTA, DAN AFILIASINYA MENYANGKAL SEMUA TANGGUNG JAWAB YANG TIMBUL KARENA ATAU TERKAIT PENGGUNAAN DOKUMEN INI DAN INFORMASI APA PUN YANG TERDAPAT DALAM DOKUMEN INI, TERMASUK HILANG ATAU PROGRAM PENDAPATAN, DATA ATAU PROGRAM GANGGUAN, ATAU UNTUK KERUSAKAN KHUSUS, TIDAK LANGSUNG, KONSEKUENSIAL, INSIDENTAL, ATAU MENGHUKUMKAN, APA PUN PENYEBABNYA DAN KECUALI TEORI TANGGUNG JAWAB, DAN BAHKAN JIKA BLUETOOTH SIG, ANGGOTANYA, ATAU AFILIASINYA TELAH DITINJAU ATAS KEMUNGKINAN INI.

Dokumen ini adalah hak milik Bluetooth SIG. Dokumen ini mungkin berisi atau mencakup materi pokok yang merupakan kekayaan intelektual Bluetooth SIG dan anggotanya. Penyempurnaan dokumen ini tidak memberikan lisensi apa pun kepada kekayaan intelektual apa pun dari Bluetooth SIG atau anggotanya.

Dokumen ini dapat berubah tanpa pemberitahuan.

1. Pendahuluan

Dokumen Proses Manajemen Spesifikasi (SMPD) menjelaskan proses-proses yang dibuat spesifikasi dan direferensikanviewers harus mengikuti untuk mengembangkan spesifikasi baru dan untuk meningkatkan spesifikasi yang ada (yaitu, untuk menambah atau menghapus fungsionalitas atau untuk mengubah fungsionalitas tertentu dalam spesifikasi yang diadopsi), untuk mempertahankan spesifikasi yang diadopsi, dan untuk mengelola akhir masa pakai spesifikasi yang diadopsi. Selain itu, dokumen ini menjelaskan proses pembuatan, reviewing, dan menyetujui kertas putih.

Terdapat perbedaan dalam proses pengembangan spesifikasi antara pengembangan spesifikasi baru dan peningkatan spesifikasi yang ada karena perbedaan yang melekat dalam ruang lingkup tugas tersebut; perbedaan-perbedaan itu disorot dalam dokumen ini.

Proses pengembangan spesifikasi meliputi:

Fase Persyaratan (dijelaskan dalam Bagian 3) untuk menentukan persyaratan fungsional
Fase Pengembangan (dijelaskan di Bagian 4) untuk mengembangkan dan meninjau ulangview spesifikasi

Fase Validasi (dijelaskan di Bagian 5) untuk memvalidasi spesifikasi melalui pengujian Interoperable Prototype (IOP)
Tahap Adopsi / Persetujuan (dijelaskan dalam Bagian 6) untuk mempresentasikan spesifikasi kepada Dewan Direksi (BoD) Bluetooth SIG untuk diadopsi / disetujui

Dokumen Spesifikasi Errata Process (EPD) [3] menjelaskan proses pengajuan dan reviewing spesifikasi ralat, dan menyetujui mereka sebagai Koreksi Errata (sebagaimana didefinisikan dalam Anggaran Rumah Tangga [2]) untuk mengadopsi spesifikasi. Kecuali dinyatakan lain, semua referensi untuk ralat dalam SMPD ini berarti ralat spesifikasi.

1.1 Diutamakan

The Bylaws of Bluetooth SIG, Inc. (Bylaws) dan perjanjian keanggotaan [2] lebih diutamakan daripada konten yang bertentangan dalam dokumen tersebut dan SMPD. Terlepas dari apa pun dalam dokumen ini, Direksi tetap memiliki kebijaksanaan dan kewenangan tertinggi untuk mengambil tindakan dan membuat keputusan meskipun tindakan dan keputusan tersebut tidak mengikuti, atau bertentangan dengan, apa pun dalam dokumen ini, dan tidak ada dalam dokumen ini yang membatasi atau membatasi kewenangan independen Direksi. dan kebijaksanaan.

Jika ada konflik antara teks di SMPD dan gambar, teks akan diutamakan.

1.2 Kelompok dan komite yang dirujuk

Jenis kelompok berikut dirujuk dalam dokumen ini: Kelompok Studi (SG), Kelompok Ahli (EG), dan Kelompok Kerja (WG). WG mungkin juga memiliki subkelompok yang melapor ke WG. Demikian pula, jenis komite berikut dirujuk dalam dokumen ini: Bluetooth Architectural Review Board (BARB), Bluetooth Test and Interoperability (BTI), dan Bluetooth Qualification Review Dewan (BQRB). Dokumen ini juga mengacu pada Staf Teknis Bluetooth SIG (BSTS), dan Direksi.

1.3 Komite reviews dan persetujuan

Sebuah komite review adalah review yang dilakukan oleh anggota komite (biasanya 3 anggota) untuk memberikan umpan balik dalam waktu tertentu (biasanya 2-3 minggu), namunview waktu dapat bervariasi tergantung pada panjang dan kompleksitas materi dan prioritas lain dalam komite. Grup yang meminta review dan panitia yang melakukan review masing-masing menyepakati durasi review. Anggota kelompok dan komite menggunakan alat Bluetooth SIG untuk memberi tahu dan merekam awal dan akhir review. Kelompok umumnya akan memproses umpan balik komite ketika diterima. Ketika panitia kembaliview waktu berakhir, kelompok selesai menangani umpan balik komite, dan juga harus mempertimbangkan setiap re yang datang terlambatview umpan balik dengan mengingat bahwa materi tersebut mungkin akan mendapat persetujuan selanjutnya oleh komite.

Persetujuan komite diperoleh dengan pemungutan suara dari anggota komite sesuai dengan Dokumen Proses Kelompok Kerja [4].

1.4 Pemberitahuan untuk anggota dan aksesibilitas materi

Semua pemberitahuan yang diberikan kepada anggota sesuai dengan dokumen ini dapat diberikan melalui email, seperti pembaruan teknis berkala. Pemberitahuan yang akan diberikan kepada semua anggota akan dikirim ke semua anggota aktif (yaitu, di mana keanggotaan belum ditangguhkan, dihentikan, atau ditarik). Ketika pemberitahuan dikirim melalui email, mereka akan dikirim ke alamat email terakhir yang diketahui (sebagaimana tercermin dalam catatan terkini Bluetooth SIG) dari setiap individu yang telah terdaftar di bawah akun keanggotaan perusahaan anggota dan yang tidak memilih untuk tidak menerima pemberitahuan email. Tidak ada dalam dokumen ini yang mengubah kewajiban atau persyaratan Bluetooth SIG sehubungan dengan ketentuan pemberitahuan berdasarkan Anggaran Rumah Tangga atau perjanjian lain apa pun antara Bluetooth SIG dan anggota mana pun.

Dimanapun dokumen ini mengacu pada a websitus yang dapat diakses oleh semua anggota, ini mengacu pada aksesibilitas ke individu yang memiliki akun Bluetooth SIG aktif. Anggota yang tidak memiliki akun aktif dapat membuat akun melalui Bluetooth SIG weblokasi.

1.5 Template

Untuk setiap jenis dokumen (misalnya, spesifikasi, kertas putih, dokumen uji) yang dirujuk dalam SMPD ini, Bluetooth SIG menyediakan template. Template harus digunakan sebagai dasar untuk setiap dokumen yang dihasilkan sesuai dengan SMPD ini. Kegagalan untuk menggunakan template yang benar dapat mengakibatkan dokumen tidak disetujui. Template tersedia di Bluetooth SIG websitus [8].

1.6 Jenis Spesifikasi

Ada beberapa jenis spesifikasi Bluetooth SIG. Secara hierarki, semua spesifikasi bergantung pada Spesifikasi Inti Bluetooth. Spesifikasi seperti pro tradisionalfileS; protokol tradisional; dan pro . berbasis GATTfiles, layanan berbasis GATT, dan protokol berbasis GATT semuanya bergantung pada fitur dalam Spesifikasi Inti. Spesifikasi lainnya, seperti spesifikasi Model Mesh, bergantung pada Mesh Profile spesifikasi yang pada gilirannya tergantung pada Spesifikasi Inti.

Spesifikasi Core Specification Supplement (CSS) mendefinisikan tipe data, format data, dan pro . umumfile dan kode kesalahan layanan yang digunakan oleh Spesifikasi Inti dan spesifikasi lainnya dan tidak dengan sendirinya menentukan perilaku apa pun.

Spesifikasi GATT Specification Supplement (GSS) mendefinisikan karakteristik dan format deskriptor yang digunakan oleh Profiles dan Layanan dan tidak dengan sendirinya mendefinisikan perilaku apa pun.
Spesifikasi Mesh Device Properties (MDP) mendefinisikan properti mesh yang digunakan oleh Mesh Profile dan spesifikasi Model Mesh dan tidak dengan sendirinya mendefinisikan perilaku apa pun.

2. Lebihview

Bagian ini menyediakan informasi lebih lanjutview proses dan tidak dimaksudkan untuk memasukkan semua rincian.

Gambar 2.1 menunjukkan enam fase utama yang membentuk Proses Manajemen Spesifikasi.

Empat tahap pertama terjadi selama proses pengembangan spesifikasi dan terdiri dari Tahap Persyaratan (Bagian 3), Tahap Pengembangan (Bagian 4), Tahap Validasi (Bagian 5), dan Tahap Adopsi / Persetujuan (Bagian 6). Ini diikuti oleh dua fase pasca-adopsi: Fase Pemeliharaan Spesifikasi (Bagian 7) dan Fase Akhir Masa Pakai Spesifikasi (Bagian 8).

Gambar 2.2 mengilustrasikan detail dari empat fase dalam proses pengembangan spesifikasi. Kotak abu-abu menunjukkan kiriman utama untuk setiap fase. Kotak oranye meringkas tonggak proses.

Dalam Tahap Persyaratan (dijelaskan di Bagian 3), proposal untuk memulai pekerjaan baru (New Work Proposal (NWP)) memulai proses pengembangan spesifikasi dengan menentukan skenario pengguna yang akan diaktifkan jika pekerjaan baru dilanjutkan. Jika NWP disetujui, grup yang ditetapkan membuat Dokumen Kebutuhan Fungsional (FRD). Setelah FRD disetujui dan ditugaskan ke grup, Tahap Pengembangan dimulai.

Selama Tahap Pengembangan (dijelaskan dalam Bagian 4), pengembangan spesifikasi berlangsung melalui urutan stages (0.5/DIPD hingga 0.9/CR) yang berpuncak pada rancangan lengkap spesifikasi. Spesifikasi 0.9/CR tersedia untuk semua anggota, kemudian disampaikan kepada Direksi yang mempertimbangkan spesifikasi untuk disetujui. Setelah disetujui, Tahap Validasi dimulai.

Selama Fase Validasi pengembangan spesifikasi (dijelaskan dalam Bagian 5), spesifikasi 0.9/CR yang disetujui Direksi tersedia bagi semua anggota untuk ditinjau ulang.view dan memvalidasi, dan Member Review dimulai. Validasi dilakukan melalui pengujian interoperabilitas (IOP) antara prototipe yang dibangun oleh anggota. Setelah pengujian TIO selesai (jika diperlukan untuk spesifikasi) dan BARB menyetujui laporan pengujian TIO, maka Fase Adopsi/Persetujuan dimulai.

Selama Fase Adopsi / Persetujuan (dijelaskan di Bagian 6), spesifikasi dan dokumen pengujian terkait diselesaikan; Persetujuan BARB, BQRB, dan BTI diterima; dan paket spesifikasi akhir diserahkan kepada Direksi yang mempertimbangkan spesifikasi untuk diadopsi (yaitu, persetujuan akhir).

Sebuah spesifikasi mungkin perlu kembali ke fase sebelumnya atau stage jika perubahan signifikan dibuat. Dalam beberapa kasus, mungkin juga untuk mengabaikan bagian dari fase seperti yang dijelaskan dalam Bagian 4.4.

Tahap Pemeliharaan Spesifikasi (dijelaskan dalam Bagian 7) dimulai setelah spesifikasi diadopsi oleh Direksi. Selama fase ini potensi kesalahan yang ditemukan dalam spesifikasi yang diadopsi dilaporkan dan dievaluasi, dan (jika perlu) Koreksi Errata dibuat untuk spesifikasi tersebut. Fase Pemeliharaan Spesifikasi berlanjut hingga spesifikasi tidak digunakan lagi atau ditarik (lihat Fase Akhir Masa Pakai Spesifikasi di paragraf berikut).

Fase Akhir Masa Pakai Spesifikasi (dijelaskan di Bagian 8) menjelaskan proses penghentian dan penarikan spesifikasi yang diadopsi.

3. Tahap Persyaratan

Fase Persyaratan dimulai baik dengan NWP (yang menyatakan keinginan untuk memulai pekerjaan pada satu atau lebih skenario pengguna) atau setelah penentuan bahwa pekerjaan baru yang diinginkan sudah tercakup oleh piagam WG mereka. Jika WG ingin memulai pekerjaan baru yang diyakini sudah dalam ruang lingkup piagam WG-nya, WG harus mengikuti proses yang ditentukan dalam Bagian 3.1 untuk langsung mengembangkan FRD. Untuk semua item pekerjaan lainnya, WG harus mengikuti proses yang ditentukan dalam Bagian 3.2. FRD mendefinisikan ruang lingkup persyaratan fungsional yang digunakan untuk membangun spesifikasi dalam Tahap Pengembangan. Fase Persyaratan diilustrasikan pada Gambar 3.1.

3.1 Pekerjaan baru yang tercakup dalam piagam WG

Ketika WG ingin memulai pekerjaan baru dan secara wajar yakin bahwa fungsionalitas yang ingin ditambahkannya sudah berada dalam cakupan piagam WG-nya, WG dapat mulai mengerjakan FRD, asalkan mereka segera memberi tahu BARB. WG akan memasukkan dalam pemberitahuannya kepada BARB deskripsi dari pekerjaan baru yang diusulkan dan salinan dari piagam WG dengan bahasa yang disorot yang memberi mereka wewenang untuk memulai pekerjaan baru.

Jika BARB menolak analisis WG, WG harus menghentikan pekerjaan pada FRD dan melanjutkan proses NWP yang diuraikan dalam Bagian 3.2. Jika BARB menyetujui analisis WG, WG akan segera memberitahu BSTS (melalui email ke spesifikasi.manager@bluetooth.com) dan BSTS akan menambahkan item tersebut ke agenda Direksi berikutnya.

WG akan memasukkan dalam pemberitahuannya kepada BSTS informasi yang sama yang diberikan kepada BARB. Jika BoD menolak analisis WG, WG harus berhenti mengerjakan FRD dan melanjutkan proses NWP yang diuraikan dalam Bagian 3.2. Jika Direksi menyetujui analisis WG, WG dapat terus mengerjakan FRD sebagaimana diuraikan dalam Bagian 3.3.

3.2 Proposal Kerja Baru (NWP)

Setiap anggota, WG, SG, atau EG dapat membuat dan mengirimkan NWP (melalui Bluetooth SIG websitus [10]). NWP harus menyertakan, setidaknya, informasi tentang hal-hal berikut menggunakan template resmi yang disediakan di [8]:

Skenario pengguna
Komitmen anggota untuk mengembangkan FRD dan di bidang apa (misalnya, Kontributor, Penulis, Revieweh, Prototipe)

Usulan kepemimpinan pekerjaan FRD
Usulan tugas kelompok untuk pekerjaan FRD
Alamat email penulis utama

Catatan: Panduan proses NWP tersedia di Bluetooth SIG websitus [10].

BSTS akan melakukan tugas-tugas berikut selama pengembangan NWP:

Berikan tanda terima kepada penulis (biasanya dalam tujuh hari kalender setelah diterima) dan uraikan langkah selanjutnya.

Jika perlu, bekerjasamalah dengan penulis agar NWP jelas dan lengkap. Ini mungkin memerlukan beberapa iterasi NWP.
Jika NWP berisi pernyataan tentang kesalahan dalam spesifikasi Bluetooth yang diadopsi, bekerja samalah dengan penulis untuk file entri ke dalam sistem ralat.
Jika diketahui bahwa NWP berpotensi menduplikasi pekerjaan yang sedang berlangsung atau telah selesai, beri tahu penulis pekerjaan lain untuk evaluasi mereka.

Posting NWP ke NWP websitus yang dapat diakses oleh semua anggota.
Beritahu semua anggota bahwa NWP tersedia untuk review dan apakah diperlukan komitmen anggota tambahan untuk mengembangkan FRD.

Anggota dapat menghubungi penulis untuk mengajukan pertanyaan atau memberikan umpan balik mengenai NWP.

Setidaknya tiga perusahaan anggota harus berkomitmen untuk berpartisipasi dalam penyelesaian FRD yang dihasilkan agar NWP menjadi calon persetujuan Direksi, dan setidaknya satu perusahaan anggota harus menjadi anggota Associate atau Promotor. Setelah persetujuan Dewan Direksi dari NWP, Direksi akan menugaskan NWP kepada subkelompok WG yang beranggotakan semua anggota atau SG untuk mengerjakan FRD (dijelaskan dalam Bagian 3.3). Jika subgrup WG atau SG yang sesuai tidak ada, salah satunya dapat dibuat.

Untuk NWP yang memiliki komitmen anggota yang cukup, BSTS akan melakukan tugas tambahan sebagai berikut:

Setidaknya 13 hari sebelum NWP diusulkan untuk disetujui oleh BoD, beri tahu BARB, dan grup yang direkomendasikan NWP untuk penugasan, tentang persetujuan NWP yang tertunda. Hal ini dilakukan untuk memberikan kesempatan umpan balik di bidang-bidang seperti kelompok yang diusulkan, apakah NWP sudah tercakup dalam pekerjaan yang ada, dll.

Menyerahkan NWP yang telah diselesaikan ke BoD.

Jika NWP diajukan oleh anggota yang tidak terkait dengan suatu kelompok, atur salah satu anggota tersebut untuk menyampaikan NWP kepada Direksi.
Jika NWP diajukan oleh kelompok, atur ketua kelompok untuk mempresentasikan NWP kepada Direksi.

Undanglah ketua BARB dan ketua kelompok, yang mana NWP direkomendasikan untuk penugasan, ke rapat Direksi.
Jika NWP disetujui dan ditetapkan oleh Direksi, beri tahu grup tempat itu ditugaskan; penulis; anggota yang diidentifikasi dalam NWP berkomitmen untuk mengembangkan FRD terkait; dan jika NWP diusulkan oleh kelompok, kelompok hasil dan langkah selanjutnya.

Setelah NWP disetujui oleh Direksi, perbarui status NWP weblokasi.

Setiap NWP dapat ditolak oleh Direksi atas pertimbangannya sendiri, misalnyaample, karena keterbatasan sumber daya, jika pekerjaan telah selesai sepenuhnya, pekerjaan tersebut berada di luar cakupan dokumen yang mengatur Bluetooth SIG (misalnya, Application Programming Interface (API)) [2], atau jika pekerjaan yang diusulkan harus filed sebagai kesalahan. Jika NWP ditolak, BSTS akan memberi tahu penulis, anggota yang diidentifikasi dalam NWP berkomitmen untuk mengembangkan FRD terkait, dan, jika NWP diusulkan oleh grup, grup. Pemberitahuan akan menyertakan alasan penolakan. Penulis, anggota yang berkomitmen, atau kelompok dapat meminta waktu dalam agenda Direksi untuk mengajukan banding atas penolakan tersebut.

Jika anggota atau kelompok ingin mengusulkan penghapusan fitur dari spesifikasi yang diadopsi, kelompok atau anggota harus menyiapkan NWP. NWP harus mencakup analisis dampak penghapusan terhadap kompatibilitas mundur dan interoperabilitas, termasuk analisis dampak pada kasus uji.

NWP tidak diperlukan untuk penyempurnaan spesifikasi CSS, GSS, atau MDP: biasanya, update spesifikasi CSS, GSS, atau MDP dihasilkan dari update ke spesifikasi lain yang memiliki NWP sendiri.

3.3 Dokumen Persyaratan Fungsional (FRD)

FRD menentukan persyaratan fungsional untuk mengaktifkan skenario pengguna. FRD harus menyertakan, minimal, informasi berikut ini menggunakan templat resmi yang disediakan di [8]:

Skenario pengguna
Persyaratan fungsional berdasarkan skenario pengguna

Komitmen anggota untuk mengembangkan spesifikasi yang dihasilkan
Dukungan prototipe opsional oleh anggota untuk peran yang diantisipasi
Direkomendasikan WG untuk mengembangkan spesifikasi yang dihasilkan

Pengembangan FRD

FRD dibuat oleh subkelompok WG semua anggota yang ditetapkan atau anggota SG dengan dukungan editorial dari BSTS. Setiap anggota yang tertarik untuk berpartisipasi dalam pengembangan FRD dapat bergabung dengan grup.

FRD harus menunjukkan komitmen dari setidaknya dua (meskipun tiga disarankan) perusahaan anggota tingkat Associate atau Promotor untuk berpartisipasi dalam pengembangan spesifikasi yang dihasilkan. WG atau SG yang mengajukan FRD harus berusaha untuk mendapatkan dukungan luas dari perusahaan anggota grup yang mewakili segmen industri sasaran yang diidentifikasi dalam FRD.

Fungsionalitas baru yang diusulkan dalam FRD harus dapat didukung pada sebanyak mungkin transportasi dan perangkat yang ada. Ini termasuk, misalnyaample, mendukung pro . berbasis GATTfiles dan layanan pada transport Basic Rate/Extended Data Rate (BR/EDR) dan transport Bluetooth Low Energy (LE). Jika fungsionalitas baru tidak memiliki dukungan anggota yang memadai untuk transportasi, misalnyaample karena kurangnya komitmen anggota untuk mendefinisikan penggunaan transportasi atau kemungkinan jumlah platform uji TIO yang tidak mencukupi untuk satu atau lebih peran, dukungan pada transportasi tersebut dapat dikecualikan dari FRD.

Kecuali jika dibenarkan, fungsi baru, profiles, dan layanan harus sesuai dengan persyaratan kompatibilitas mundur yang dijelaskan dalam Bagian 3.3.2.

WG atau SG harus menyerahkan FRD ke BARB untuk review dan persetujuan. BARB harus menyetujui atau menolak FRD berdasarkan penilaian tekniknya. Jika disetujui oleh BARB, FRD akan tersedia untuk semua anggota dan pemberitahuan ketersediaannya akan dikeluarkan oleh BSTS.

FRD tidak diperlukan untuk penyempurnaan spesifikasi CSS, GSS, atau MDP: biasanya, update spesifikasi CSS, GSS, atau MDP dihasilkan dari update ke spesifikasi lain yang memiliki FRD sendiri.

Persyaratan kompatibilitas mundur

Kompatibilitas mundur untuk BR / EDR

Untuk operasi BR / EDR, persyaratan kompatibilitas mundur didefinisikan sebagai interoperation dengan bagian BR / EDR dari Spesifikasi Inti Bluetooth v1.1 dan yang lebih baru.

Kompatibilitas mundur untuk Bluetooth Hemat Energi

Untuk operasi LE, persyaratan kompatibilitas mundur didefinisikan sebagai interoperation dengan bagian LE dari Spesifikasi Inti Bluetooth v4.0 dan yang lebih baru.

Kompatibilitas ke belakang untuk spesifikasi selain Spesifikasi Inti

Untuk spesifikasi selain Spesifikasi Inti Bluetooth, kompatibilitas mundur dari versi tertentu harus dipertahankan dengan semua versi sebelumnya yang memiliki nomor versi utama yang sama. Untuk mantanample, versi 1.3 harus kompatibel dengan versi 1.2, 1.1, dan 1.0, tetapi versi 2.0 mungkin tidak kompatibel dengan versi 1.0, 1.1, 1.2, dan 1.3. Perhatikan bahwa peningkatan nomor versi utama dari Spesifikasi Inti tidak menyiratkan kurangnya kompatibilitas dengan versi sebelumnya.

Pengecualian dari persyaratan kompatibilitas ke belakang

WG atau SG dapat mengusulkan untuk mengecualikan fungsionalitas tertentu dari persyaratan kompatibilitas mundur jika pembenaran diberikan. Untuk mantanample, jika fungsionalitas terbukti memiliki tingkat adopsi pasar yang rendah atau, karena masalah interoperabilitas, lebih baik untuk menghapus atau mengganti fungsionalitas daripada memodifikasi fungsionalitas. WG atau SG harus menyertakan pengecualian kompatibilitas mundur apa pun di FRD, yang disetujui oleh BARB setelah persetujuan FRD. Pengecualian yang disetujui BARB akan diajukan kepada Direksi untuk disetujui pada 0.9/CR Stage.

3.4 Piagam Kelompok Kerja

Ketika BARB menyetujui FRD yang diusulkan untuk ditugaskan ke WG yang ada, WG tersebut harus menyiapkan draft update untuk piagamnya untuk menambahkan fungsionalitas baru ke ruang lingkup (kecuali Direksi sebelumnya telah menyetujui analisis WG bahwa pembaruan piagam WG tidak dibutuhkan). Namun, ketika BARB menyetujui FRD yang diusulkan untuk ditugaskan ke WG baru, BARB dan anggota yang tertarik untuk mengembangkan fungsionalitas yang diuraikan dalam FRD harus menyiapkan draft charter untuk WG baru dengan fungsionalitas baru yang termasuk dalam cakupan charter. .

Setelah piagam WG baru atau yang diperbarui disiapkan, itu harus diserahkan ke BARB untuk review dan persetujuan. Setelah BARB menyetujui piagam tersebut, draf piagam WG yang baru atau yang diperbarui akan diserahkan kepada Direksi untuk disetujui.

Setelah Direksi menyetujui piagam tersebut, WG yang ditugaskan untuk pekerjaan pengembangan spesifikasi oleh Direksi harus bekerja sama dengan kelompok yang menyiapkan FRD jika diperlukan pembaruan atau klarifikasi yang diperlukan untuk FRD tersebut. Jika pembaruan FRD diperlukan selama Tahap Pengembangan, proses yang diuraikan dalam Bagian 3.3 dan bagian ini harus diikuti; namun, pengembangan spesifikasi dapat terjadi secara paralel dengan pembaruan piagam FRD dan WG.

3.5 Persyaratan Persyaratan keluar fase

Fase Persyaratan selesai dan Fase Pengembangan dimulai ketika piagam WG dengan ruang lingkup yang diperlukan untuk FRD dikonfirmasi atau disetujui oleh Direksi dan persyaratan berikut telah dipenuhi:

NWP telah disetujui oleh Direksi, atau Direksi telah menyetujui bahwa NWP tidak diperlukan.

FRD dan piagam WG terkait telah disetujui oleh BARB.

4. Tahap Pengembangan

Selama Tahap Pengembangan, WG yang ditugaskan membuat spesifikasi baru dan / atau meningkatkan spesifikasi yang ada. FRD menentukan persyaratan spesifikasi Bluetooth yang baru atau yang disempurnakan. Tidak ada fungsionalitas yang diperbolehkan dalam spesifikasi yang tidak cukup terkait dengan persyaratan di FRD. Tujuannya adalah untuk membuat spesifikasi 0.9 / CR yang siap untuk Tahap Validasi (dijelaskan dalam Bagian 5) pada akhir Tahap Pengembangan.
Selama Fase Pengembangan, spesifikasi (atau peningkatan spesifikasi) maju melalui tiga tahap:tagyaitu.

Untuk spesifikasi baru, tiga stagadalah:

tahun 0.5tage
tahun 0.7tage

tahun 0.9tage

Untuk peningkatan spesifikasi, tiga stagadalah:

Draf Dokumen Usulan Perbaikan (DIPD) Stage

Dokumen Proposal Perbaikan Akhir (FIPD) Stage
Ubah Permintaan (CR) Stage

Setiap stage dijelaskan lebih lanjut dalam subbagian berikut. Gambar 4.1 di bawah ini mengilustrasikan berbagai dokumen yang akan disiapkan oleh WG di setiap stage.

Gambar 4.1: Lebihview dari spesifikasi stagyang terjadi selama Fase Pengembangan

Peran BARB selama proses pengembangan spesifikasi adalah memberikan saran dan bantuan teknis kepada WG. WG dapat, kapan saja, meminta saran teknis kepada BARB terkait pengembangan spesifikasi dan konsep arsitektural yang akan digunakan dalam spesifikasi. WG secara khusus didorong untuk meminta umpan balik awal dari BARB untuk fitur yang memiliki pertimbangan arsitektur yang lebih kompleks.

4.1 0.5/DIPD Stage

Selama 0.5/DIPD Stage, WG akan mengembangkan yang berikut menggunakan templat resmi yang disediakan di [8]:

Untuk spesifikasi baru, draf spesifikasi 0.5, yang minimal harus menyertakan informasi berikut ini:

Arsitektur untuk memenuhi persyaratan sebagaimana tercantum dalam FRD

Untuk protokol, jalur akses layanan ditentukan
Untuk layanan, data dan perilaku terekspos
Untuk profiles, protokol diidentifikasi dan fungsionalitas ditentukan

2. Untuk peningkatan spesifikasi, draf DIPD, yang minimal harus mencakup informasi sebagai berikut:

Latar belakang: Cakupan pekerjaan, tujuan yang memandu pekerjaan, dan bagaimana proposal khusus ini sesuai dengan cakupannya
Lebihview dari proposal: Ringkasan fungsionalitas yang diperluas (fleksibilitas tambahan, kinerja yang ditingkatkan, dll.) Yang disediakan oleh DIPD termasuk penjelasan yang jelas tentang bagaimana fungsionalitas baru tersebut sesuai dengan versi spesifikasi saat ini. Jika WG telah mengevaluasi beberapa proposal, proposal ini harus dimasukkan agar BARB berkesempatan untuk menentukan apakah telah dilakukan uji tuntas yang memadai dalam pemilihan proposal yang disukai.

Cakupan persyaratan: Ringkasan cakupan persyaratan fungsional yang diberikan oleh proposal, dengan mengacu pada persyaratan sistem yang sesuai dan skenario penggunaan yang diberikan dalam FRD terkait
Definisi masalah: Pernyataan masalah yang diselesaikan oleh proposal
Kriteria pemilihan: Pernyataan tentang kriteria pemilihan / kinerja dari metrik evaluasi terkait yang telah memandu proses pemilihan

Pembenaran pilihan: Pemeriksaan metrik evaluasi yang membenarkan pilihan antara proposal dan mengungkapkan trade-off
Keterangan: Penjelasan tentang fungsionalitas dan protokol yang diperluas. Bagian ini dapat menyesuaikan dengan kebutuhan yang berbeda dengan menambahkan sub-bagian yang relevan.

3. Strategi Tes: Deskripsi fungsionalitas yang diusulkan untuk diuji (atau tidak diuji) sebagai bagian dari Program Kualifikasi Bluetooth dan bagaimana fungsionalitas itu diusulkan untuk diuji (misalnya, harapan pada Penguji Bawah atau Penguji Atas), dan jika pengujian akan diatribusikan sebagai uji kesesuaian atau interoperabilitas atau kombinasi keduanya). Ini mungkin dalam dokumen terpisah atau bagian terpisah dalam spesifikasi 0.5/DIPD. Konvensi yang akan digunakan dalam Strategi Uji dijelaskan dalam Strategi Uji dan Terminologi Overview dokumen (TSTO) [5].

Audiens utama dokumen di s . initage adalah anggota WG dan BARB yang review proposal arsitektur dan cakupan kebutuhan, dan BTI yang reviews Strategi Uji. Dalam kebanyakan kasus, dokumen di s . initage tidak dimaksudkan untuk memuat teks yang direncanakan untuk dimasukkan dalam spesifikasi akhir.

BSTS harus mengulangview semua dokumen untuk konsistensi dengan Bluetooth Drafting Guidelines [1] dan mengidentifikasi masalah untuk ditangani oleh WG. BARB harus mengulangview spesifikasi 0.5/DIPD. Untuk peningkatan spesifikasi, BARB juga harus review DIPD untuk memenuhi persyaratan kompatibilitas mundur yang dijelaskan dalam Bagian 3.3.2. BTI harus mengulangview Strategi Tes.

BARB harus menyetujui atau menolak spesifikasi 0.5/DIPD berdasarkan pertimbangan teknisnya. Jika disetujui oleh BARB, spesifikasi 0.5/DIPD akan tersedia di Bluetooth SIG websitus untuk semua anggota Associate dan Promotor dan pemberitahuan ketersediaannya akan dikeluarkan oleh BSTS. Pada 0.5/DIPD Stage, persetujuan Strategi Uji tidak diperlukan.
0.5/DIPD Stage tidak diperlukan untuk penyempurnaan spesifikasi CSS, GSS, atau MDP

0.5/DIPD Stage persyaratan keluar

0.5/DIPD Stage selesai dan 0.7/FIPD Stage dimulai ketika persyaratan keluar berikut terpenuhi:

BSTS telah menyelesaikan reviewing spesifikasi 0.5/DIPD dan Strategi Uji.

BARB telah menyetujui spesifikasi 0.5 / DIPD.
BTI telah menyelesaikan review dari Strategi Tes.
BSTS telah membuat spesifikasi 0.5 / DIPD yang disetujui tersedia untuk semua anggota Associate dan Promotor.

4.2 0.7/FIPD Stage

Selama 0.7/FIPD Stage, WG akan mengembangkan yang berikut menggunakan templat resmi yang disediakan di [8]:

Untuk spesifikasi baru, draf spesifikasi 0.7, yang minimal harus menyertakan informasi berikut ini:

Deskripsi semua perubahan yang dibuat sejak 0.5 BARB disetujui, termasuk proposal baru atau yang dimodifikasi, kriteria seleksi, dan justifikasi pilihan. Perubahan harus dijelaskan pada tingkat detail yang sama seperti yang dipersyaratkan dalam 0.5 Stage.

Semua persyaratan fungsional dari FRD ditangani.

2. Untuk peningkatan spesifikasi, draf FIPD, yang minimal harus mencakup informasi sebagai berikut:

Uraian tentang semua perubahan yang dilakukan sejak DIPD yang disetujui BARB, termasuk proposal baru atau yang dimodifikasi, kriteria seleksi, dan justifikasi pilihan. Perubahan harus dijelaskan pada tingkat detail yang sama seperti yang dipersyaratkan dalam DIPD Stage.

Jika perlu, wilayah yang dikembangkan lebih lanjut yang dijelaskan dalam Bagian 4.1 tentang DIPD.
Deskripsi lengkap tentang peningkatan tersebut.
Deskripsi arsitektur yang diperbarui.
Semua persyaratan fungsional dari FRD ditangani.

3. 0.7 / FIPD dokumen pengujian, yang minimal harus mencakup informasi sebagai berikut:

Rangkaian Tes, terdiri dari daftar Tujuan Tes seperti yang dijelaskan dalam TSTO [5].
Pernyataan Kesesuaian Implementasi (ICS), seperti yang dijelaskan dalam TSTO [5].

Untuk peningkatan spesifikasi, Test Suite dan ICS dapat diberikan sebagai dokumen terpisah atau sebagai bagian tambahan dalam FIPD.

Audiens utama dari dokumen yang dihasilkan di s . initage adalah anggota WG dan BARB yang review deskripsi lengkap fitur atau peningkatan termasuk beberapa teks yang direncanakan untuk dimasukkan dalam spesifikasi akhir. BTI adalah penonton untuk review dari dokumen pengujian.

BSTS akan kembaliview bagian baru atau yang diubah dari spesifikasi 0.7/FIPD dan dokumen uji untuk konsistensi dengan Panduan Penyusunan Bluetooth, termasuk konvensi bahasa yang ditetapkan oleh Bluetooth SIG. BARB akan kembaliview spesifikasi 0.7/FIPD.

BSTS akan membantu WG dalam mempersiapkan dokumen tes 0.7 / FIPD sesuai dengan TSTO [5].

BTI harus mengulangview dokumen uji 0.7/FIPD. WG harus memberikan spesifikasi 0.7/FIPD kepada BTI sebagai referensi saat reviewing dokumen uji 0.7/FIPD, yang BTI akan review sesuai dengan Spesifikasi BTI Review Daftar Periksa Proses [6].

Setelah BARB menyelesaikan review dari spesifikasi 0.7/FIPD dan BTI telah menyelesaikan review dari dokumen uji 0.7/FIPD, BSTS akan melakukan reviewed 0.7/FIPD spesifikasi tersedia untuk semua anggota Associate dan Promotor.

0.7/FIPD Stage tidak diperlukan untuk penyempurnaan spesifikasi CSS, GSS, atau MDP.

0.7/FIPD Stage persyaratan keluar

0.7/FIPD Stage selesai dan 0.9/CR Stage dimulai ketika persyaratan keluar berikut terpenuhi:

BSTS telah menyelesaikan reviewdengan spesifikasi 0.7/FIPD dan dokumen uji.
BARB telah menyelesaikan reviewdengan spesifikasi 0.7/FIPD.
BTI telah menyelesaikan reviewing 0.7/FIPD Test Suite (Test Purposes) dan 0.7/FIPD ICS.
BSTS telah membuat reviewed 0.7/FIPD spesifikasi tersedia untuk semua anggota Associate dan Promotor.

4.3 0.9/CR Stage

Ada dua jenis CR: CR Terpadu, yang merupakan dokumen yang dilacak perubahan dari seluruh spesifikasi yang diadopsi yang menunjukkan semua perubahan sejak versi sebelumnya, dan CR yang Disingkat, yang merupakan dokumen yang memberikan instruksi untuk memodifikasi hanya bagian yang terpengaruh dari versi spesifikasi yang menjadi dasar CR.

Selama 0.9/CR Stage, WG akan mengembangkan yang berikut menggunakan templat resmi yang disediakan di [8]:

Untuk spesifikasi baru, draf lengkap konten dari spesifikasi 0.9, yang harus menyertakan, minimal, informasi berikut ini:

Deskripsi semua perubahan yang dibuat sejak BARB-reviewed 0.7 spesifikasi (atau sejak spesifikasi 0.5 jika memproduksi spesifikasi 0.7 telah dibebaskan), termasuk baru atau
proposal yang dimodifikasi, kriteria seleksi, dan justifikasi pilihan. Perubahan harus dijelaskan pada tingkat detail yang sama seperti yang dipersyaratkan dalam 0.5 Stage dan 0.7 Stage.

2. Untuk peningkatan spesifikasi:

Salah satu dari CR Terintegrasi, yang minimal harus menyertakan informasi berikut ini:
Deskripsi semua perubahan yang dibuat sejak BARB-reviewed FIPD (atau sejak DIPD jika FIPD telah dibebaskan) termasuk proposal baru atau yang dimodifikasi, kriteria seleksi, dan justifikasi pilihan. Perubahan harus dijelaskan pada tingkat detail yang sama seperti yang dipersyaratkan dalam DIPD Stage dan FIPD Stage.
Semua perubahan yang diusulkan ke spesifikasi yang diadopsi sebelumnya menggunakan pelacakan perubahan.
Semua ralat teknis yang disetujui (dengan setiap erratum direferensikan dengan nomor erratum), ditampilkan menggunakan pelacakan perubahan, yang belum dimasukkan ke dalam versi spesifikasi yang diadopsi sebelumnya, dan teks dampak yang terkait dengan peningkatan spesifikasi; atau yang berdampak pada pengujian IOP.

3. Atau CR Disingkat, yang minimal harus menyertakan informasi tentang hal-hal berikut:

Deskripsi semua perubahan yang dibuat sejak BARB-reviewed FIPD (atau sejak DIPD jika FIPD telah dibebaskan) termasuk proposal baru atau yang dimodifikasi, kriteria seleksi, dan justifikasi pilihan. Perubahan harus dijelaskan pada tingkat detail yang sama seperti yang dipersyaratkan dalam DIPD Stage dan FIPD Stage.
Semua perubahan yang diusulkan untuk setiap bagian yang terpengaruh dan paragraf spesifikasi yang CR usulkan untuk diubah.
Semua ralat teknis yang disetujui (dengan setiap erratum direferensikan dengan nomor erratum), ditampilkan menggunakan markup, yang belum dimasukkan ke dalam versi spesifikasi yang diadopsi sebelumnya, dan teks dampak yang terkait dengan peningkatan spesifikasi; atau yang berdampak pada pengujian IOP.

4. CR CSS (jika entri baru diperlukan oleh spesifikasi), yang dapat disematkan dalam CR dari spesifikasi.
5. CR GSS (jika entri baru diperlukan oleh spesifikasi), yang dapat disematkan dalam CR dari spesifikasi.
6. CR MDP (jika entri baru diperlukan oleh spesifikasi), yang dapat disematkan dalam CR dari spesifikasi.
7. Dokumen uji 0.9 / CR, yang minimal harus menyertakan informasi berikut ini menggunakan templat resmi yang disediakan di [8]:

Rangkaian Uji 0.9 / CR, yang mencakup kasus uji konten lengkap dan Tabel Pemetaan Kasus Uji terkait (TCMT), seperti yang dijelaskan dalam TSTO [5].
0.9 / CR ICS, seperti yang dijelaskan dalam TSTO [5].
Jika konfigurasi pengujian memerlukan parameter khusus untuk Implementasi Dalam Pengujian (IUT), 0.9 / CR Implementasi eXtra Informasi untuk Pengujian (IXIT).
Daftar Referensi Kasus Uji (TCRL) 0.9 / CR (opsional untuk pembaruan Spesifikasi Inti).

8. Analisis cakupan pengujian yang menunjukkan persyaratan spesifikasi mana yang diuji atau tidak diuji dalam Rangkaian Uji 0.9 / CR (untuk peningkatan spesifikasi, analisis cakupan pengujian hanya perlu menyertakan fungsionalitas yang baru ditambahkan dan terpengaruh, dan bukan area yang tidak terpengaruh spesifikasi asli).
9. Rencana tes IOP.

Untuk peningkatan spesifikasi, Test Suite, ICS, dan IXIT dapat diberikan sebagai dokumen terpisah atau sebagai bagian tambahan dalam CR yang Disingkat.

Dalam kebanyakan kasus, CR Terpadu atau Disingkat harus didasarkan pada versi spesifikasi yang diadopsi sebelumnya, tetapi juga dapat didasarkan pada draf perantara terbaru. Nomor versi spesifikasi draf perantara terbaru harus merupakan nomor versi yang terkait dengan versi dokumen yang dibekukan dan yang tidak akan berubah seiring waktu. Jika tidak, informasi identitas tambahan (seperti tanggal dokumen dan a URL ke lokasi permanen) harus diberikan untuk mengidentifikasi versi "dasar" tertentu. Jika draf perantara digunakan, setiap perubahan yang tidak terkait langsung dengan CR dalam bagian tertentu yang dimodifikasi CR harus disertakan, tetapi tidak perlu ditampilkan menggunakan markup. Jika bagian yang relevan dari draf perantara kemudian diperbarui, CR harus diperbarui untuk mencerminkan pembaruan draf perantara.

Idealnya, materi CR Ringkas diintegrasikan ke dalam draf spesifikasi lengkap dan dokumen pengujian lengkap masing-masing, sebelum Tahap Validasi, tetapi mereka juga dapat diintegrasikan pada awal Tahap Validasi. Jika beberapa fitur sedang dikembangkan untuk suatu spesifikasi (misalnya, Spesifikasi Inti), mungkin diinginkan untuk mengintegrasikan fitur-fitur tersebut ke dalam satu konsep setelah pengujian IOP selesai.

BSTS akan kembaliview spesifikasi 0.9/CR dan dokumen uji untuk konsistensi dengan Pedoman Penyusunan Bluetooth. Kemudian BARB akan kembaliview spesifikasi 0.9/CR diikuti kemudian oleh rencana uji TIO (seperti yang dijelaskan dalam Bagian 4.3.1). Setelah spesifikasi 0.9/CR diajukan oleh WG ke BARB untuk review, BSTS akan membuatnya dapat diakses oleh semua anggota untuk review dan memberi tahu semua anggota tentang ketersediaannya. Mulai saat ini dalam proses pengembangan spesifikasi, BSTS akan membuat draf spesifikasi yang diserahkan ke BARB tersedia untuk semua anggota dengan pemberitahuan berkala yang dikirimkan ke semua anggota.

Untuk peningkatan spesifikasi, WG akan merekomendasikan kepada Direksi apakah versi spesifikasi sebelumnya harus dihentikan atau ditarik kembali, termasuk alasan teknis untuk rekomendasi tersebut.

BARB akan kembaliview analisis WG tentang kesesuaian spesifikasi 0.9/CR dengan persyaratan yang diberikan dalam FRD, potensi masalah keamanan, masalah peraturan, kesesuaian dengan arsitektur Bluetooth, dan, untuk peningkatan spesifikasi, kepatuhan terhadap persyaratan kompatibilitas mundur yang dijelaskan dalam Bagian 3.3.2 .XNUMX. Jika BARB mengidentifikasi masalah keamanan potensial, BARB akan memberitahu BSTS untuk review dan koordinasi dengan Kelompok Pakar Keamanan; dan jika BARB mengidentifikasi implikasi peraturan, BARB akan memberi tahu BSTS untuk melaporkanview dan berkoordinasi dengan Regulatory Committee dan penasihat hukum Bluetooth SIG. BARB harus menyetujui atau menolak spesifikasi 0.9/CR berdasarkan pertimbangan teknis dan pertimbangan faktor-faktor yang dijelaskan dalam paragraf ini.

BTI akan kembaliview dokumen uji 0.9/CR dengan mempertimbangkan analisis cakupan pengujian. BTI harus menyetujui atau menolak dokumen uji 0.9/CR.

Setelah BARB menyetujui spesifikasi 0.9/CR, WG menyerahkan rencana uji TIO ke BARB untukview.

Spesifikasi 0.9 / CR yang disetujui BARB disajikan kepada Direksi untuk menyetujui dimulainya pengujian IOP dan publikasi spesifikasi 0.9 / CR kepada semua anggota.

Untuk menyoroti potensi masalah hukum, WG dapat meminta spesifikasi review oleh penasihat hukum Bluetooth SIG (review) sebelum pemeriksaan hukum wajibview berlangsung selama Fase Adopsi/Persetujuan. Namun, untuk peningkatan spesifikasi, referensi hukumview harus dilakukan pada CR Terpadu (sebagai lawan dari CR Singkat) dan ini harus dijadwalkan sebelumnya sejauh mungkin sehingga sumber daya tersedia.

Rencana tes IOP

WG akan mengembangkan rencana uji TIO tertulis yang harus memenuhi semua persyaratan yang ditentukan di bawah ini untuk digunakan selama Fase Validasi pada peristiwa uji TIO. WG harus menyerahkan rencana uji TIO ke BARB untuk review sebelum acara tes IOP dimulai. Untuk peningkatan spesifikasi sederhana (terutama yang tidak memerlukan modifikasi atau penambahan kasus uji apa pun di Test Suite), pengujian IOP mungkin tidak diperlukan, dan WG dapat mengajukan permintaan ke BARB untuk pengabaian dari pengujian IOP dengan menggunakan proses yang ditentukan di Bagian 4.4.

Rencana tes IOP harus mencakup:

Uji kasus untuk memverifikasi semua fitur baru wajib, opsional, dan bersyarat
Setidaknya satu kasus uji untuk setiap kode operasi
Setidaknya satu kasus uji untuk setiap parameter
Setidaknya satu kasus uji untuk setiap jenis paket
Kasus uji kompatibilitas mundur untuk peningkatan spesifikasi sehingga persyaratan yang tercantum dalam Bagian 3.3.2 terpenuhi untuk semua fungsionalitas yang ditingkatkan (juga lihat Bagian 4.3.1.1).
Uji kasus di mana IUT diekspos ke nilai di luar rentang yang ditentukan atau ke aspek perilaku yang dianggap tidak valid atau tidak terduga (kasus uji Perilaku Tidak Valid). Perhatikan bahwa penguji seperti PTS atau alat uji lainnya diharapkan akan menjadi pemrakarsa dari setiap perilaku yang tidak valid.
Setiap nomor yang ditetapkan sementara (dipilih dalam koordinasi dengan BSTS untuk menghindari tumpang tindih pada acara tes IOP mendatang) untuk digunakan pada acara tes IOP, seperti yang dijelaskan dalam Bagian 4.3.1.2.
Identifikasi jumlah implementasi independen yang diperlukan yang harus lulus setiap uji kasus, dengan mempertimbangkan persyaratan cakupan yang dijelaskan dalam Bagian 4.3.1.3
Identifikasi kasus uji apa pun dalam Rangkaian Uji yang menurut WG harus dikecualikan dan pembenaran untuk pengecualiannya. Ini biasanya mencakup: • Kasus uji Pemeriksaan Masa Mendatang (misalnya, pengujian umum sehingga kemungkinan penambahan di masa mendatang dapat diakomodasi, seperti karakteristik tambahan, karakteristik yang diperluas, atau penggunaan bit atau bidang yang Dicadangkan untuk Penggunaan di Masa Mendatang (RFU))
• Uji kasus yang merupakan bagian dari tes lain yang disertakan
• Kasus uji umum yang hampir identik dengan pengujian yang dijalankan untuk beberapa spesifikasi lain (misalnya, memicu kode kesalahan umum)
• Kasus uji dengan tujuan uji yang sama seperti kasus uji yang dijalankan di atas transportasi lain (misalnya, kasus uji BR / EDR yang mirip dengan kasus uji LE)
• Uji ketahanan atau stres dari implementasi

Rencana pengujian IOP juga dapat mencakup pengujian yang unik untuk pengujian IOP seperti kasus pengujian ujung ke ujung yang merangkai urutan yang lebih kompleks yang mungkin menyerupai skenario pengguna yang khas.

Meskipun persetujuan BARB dari rencana pengujian IOP tidak diperlukan (dengan pemahaman bahwa rencana pengujian IOP akan terus dimodifikasi dan ditingkatkan dengan setiap acara pengujian IOP), persetujuan BARB atas laporan pengujian IOP diperlukan (lihat Bagian 5.1.1) . Jika rencana pengujian IOP tidak memenuhi semua persyaratan yang ditentukan dalam Bagian 4.3.1, WG harus menyajikan ringkasan dari setiap varians yang diketahui dan alasan untuk setiap varians ke BARB sebelum acara pengujian IOP dimulai.

Rencana pengujian IOP dan kasus pengujian harus didasarkan pada konten dalam dokumen pengujian spesifikasi terkait.

Untuk membuat peristiwa uji IOP efisien, WG harus memiliki rencana uji IOP dan semua kasus uji terkait diselesaikan dan tersedia untuk pelaksana idealnya setidaknya satu bulan sebelum acara uji IOP pertama.

Merencanakan pengujian kompatibilitas mundur
Untuk peningkatan spesifikasi, pengujian IOP terhadap kompatibilitas mundur harus mempertimbangkan verifikasi terhadap semua versi spesifikasi yang aktif dan tidak digunakan lagi karena spesifikasi dan fungsionalitas yang biasa ditemukan dalam produk Bluetooth mungkin memiliki masa pakai yang sangat lama (misalnya, kendaraan). WG harus menganalisis tingkat yang sesuai dari pengujian kompatibilitas mundur yang diperlukan (jika ada) termasuk versi mana yang akan diuji dan pengujian yang harus dilakukan, dan memberikan analisis ini kepada BARB. BARB harus mengulangview analisis dan merekomendasikan perubahan (jika ada) untuk WG untuk dimasukkan ke dalam rencana uji TIO.

Anggota yang berpartisipasi dalam pengujian kompatibilitas mundur didorong untuk membawa perangkat lawas yang telah terkualifikasi dengan versi spesifikasi sebelumnya. WG harus melaporkan kegagalan kompatibilitas mundur dalam laporan pengujian IOP. Perusahaan anggota juga didorong untuk melakukan pengujian kompatibilitas mundur di lab mereka sendiri di luar lokasi acara uji IOP dan untuk melaporkan masalah apa pun yang terkait spesifikasi ke WG.

Nomor Sementara yang Ditugaskan digunakan dalam pengujian IOP
BSTS dan BARB harus dikonsultasikan untuk mengkoordinasikan penugasan sementara nomor yang ditetapkan yang akan digunakan pada acara uji IOP agar tidak terjadi tumpang tindih atau bentrok dengan spesifikasi lainnya. Nilai sementara ini harus dimasukkan dalam rencana pengujian IOP dan tidak akan ditetapkan untuk digunakan oleh spesifikasi yang diadopsi.

Untuk pengujian IOP di mana satu atau lebih nilai UUID 16-bit baru sedang diusulkan, nilai dalam kisaran 0x7F00 hingga 0x7FFF dicadangkan untuk pengujian IOP.

Untuk pengujian IOP di mana satu atau beberapa nilai Fixed Protocol Service Multiplexer (PSM) baru sedang diusulkan, nilai yang dimulai dari akhir rentang valid dari 0x0000 hingga 0x007F, seperti yang ditentukan dalam Spesifikasi Inti, akan digunakan.

Persyaratan cakupan
WG harus memberikan bukti kepada BARB bahwa jumlah yang disyaratkan (seperti yang dijelaskan di bagian berikutnya) dari implementasi independen telah lulus setiap uji kasus. Setiap permintaan WG untuk pengecualian terhadap jumlah implementasi independen yang diperlukan harus ditunjukkan dalam rencana uji IOP yang dikirimkan ke BARB.

Implementasi dianggap independen satu sama lain selama semua bagian yang relevan dengan validasi telah dikembangkan secara independen, yaitu oleh tim yang berbeda (yang tidak harus berasal dari perusahaan yang berbeda). BSTS dapat membantu dalam menilai apakah prototipe dapat dianggap independen satu sama lain untuk menjaga anonimitas dan kerahasiaan detail implementasi.

Perhatikan bahwa alat uji, termasuk PTS, tidak dianggap sebagai implementasi independen.

Spesifikasi Inti Persyaratan cakupan IOP
Fitur Spesifikasi Inti biasanya mendefinisikan satu atau lebih peran di mana setiap peran dirancang untuk beroperasi dengan satu atau lebih peran lain atau mungkin dengan peran itu sendiri.

Untuk setiap pasangan peran yang dirancang untuk saling beroperasi satu sama lain, setidaknya tiga implementasi independen dari masing-masing peran harus ditunjukkan untuk beroperasi dengan tiga implementasi independen dari peran pelengkap.

Untuk setiap peran yang dapat beroperasi dengan perangkat lain dalam peran yang sama, setidaknya tiga implementasi independen dari peran tersebut harus menunjukkan bahwa mereka dapat berinteraksi satu sama lain dalam peran tersebut.

Spesifikasi layanan persyaratan cakupan IOP
Setidaknya tiga implementasi layanan independen harus menunjukkan bahwa mereka bekerja sama dengan setidaknya satu implementasi klien, yang mungkin PTS.

Profile dan spesifikasi protokol persyaratan cakupan IOP
Profile dan spesifikasi protokol biasanya mendefinisikan satu atau lebih peran di mana setiap peran dirancang untuk beroperasi dengan satu atau lebih peran lain, atau mungkin dengan dirinya sendiri.

Untuk setiap pasangan peran yang dirancang untuk saling beroperasi satu sama lain, setidaknya dua implementasi independen dari setiap peran harus menunjukkan bahwa mereka bekerja sama dengan dua implementasi independen dari peran yang saling melengkapi.

Spesifikasi model persyaratan cakupan IOP
Setidaknya tiga model server independen atau implementasi model kontrol harus menunjukkan bahwa mereka bekerja sama dengan setidaknya satu implementasi klien (yang mungkin PTS), dan setidaknya satu implementasi model klien harus menunjukkan bahwa model itu beroperasi dengan setidaknya satu implementasi model server dan PTS.

Penomoran versi spesifikasi

Selama 0.9/CR Stage, WG harus menyiapkan rekomendasi untuk disampaikan kepada Direksi mengenai nomor versi yang akan diterapkan pada spesifikasi saat diadopsi.

Versi spesifikasi terbagi dalam dua jenis: versi rilis penuh, yang menyertakan fitur baru atau yang diperbarui, dan versi rilis pemeliharaan (juga dikenal sebagai "versi dot-Z"), yang mengintegrasikan kesalahan teknis dan editorial, tetapi tidak menyertakan yang baru atau yang diperbarui fitur. Versi rilis penuh memiliki nomor dua bagian dalam bentuk XY, seperti 2.1 atau 5.0, sedangkan versi rilis pemeliharaan memiliki nomor tiga bagian dalam bentuk XYZ, seperti 2.1.2. Nilai Z tidak boleh 0.

Untuk dua versi mana pun, yang satu disebut sebagai "versi yang lebih tinggi" dan yang lainnya adalah "versi yang lebih rendah". Ini ditentukan menurut aturan berikut:

Jika komponen X berbeda, komponen dengan nilai X lebih tinggi adalah "versi lebih tinggi".
Jika komponen X sama, tetapi komponen Y berbeda, komponen dengan nilai Y lebih tinggi disebut “versi lebih tinggi”.
Jika komponen XY sama, tetapi komponen Z berbeda, komponen dengan nilai Z lebih tinggi disebut "versi lebih tinggi". Nomor dua bagian XY, untuk tujuan ini, diperlakukan sebagai nomor tiga bagian XY0.

Misalnyaample, nomor versi berikut akan diurutkan dari versi terendah ke versi tertinggi: 1.4, 2.0, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.2. Untuk CSS, setiap pembaruan hanya menambah komponen X dari nomor versi.

Prasyarat persetujuan Direksi
Pada akhir tahap Pengembangan Spesifikasi, persyaratan berikut harus dipenuhi sebelum spesifikasi 0.9 / CR diajukan kepada Direksi untuk disetujui:

WG telah menyelesaikan analisis cakupan tes.
BSTS telah menyelesaikan reviewing spesifikasi 0.9/CR dan dokumen uji.
BARB telah menyetujui spesifikasi 0.9 / CR.
BARB telah menyetujui CR CSS (jika entri baru diperlukan oleh spesifikasi) yang dapat disematkan dalam CR dari spesifikasi.
BARB telah menyetujui GSS CR dan MDP CR (jika entri baru diperlukan oleh spesifikasi).
BTI telah menyetujui 0.9/CR Test Suite, ICS, dan TCRL, bersama dengan IXIT (asalkan IXIT diperlukan untuk melakukan tes di Test Suite). TCRL bersifat opsional pada saat initage untuk pembaruan Spesifikasi Inti.
WG telah menyerahkan rencana uji TIO ke BARB untuk review (jika pengujian tidak dibebaskan oleh BARB).

Dokumen yang disampaikan kepada Direksi harus memuat spesifikasi 0.9 / CR yang telah disetujui BARB, dan presentasi kepada Direksi yang harus memuat:

Setiap permintaan yang diketahui untuk mengabaikan pengujian IOP atau persyaratan apa pun yang ditentukan dalam Bagian 4.3.1
Daftar transport yang didukung spesifikasi (mis., BR / EDR, LE. Dll.)
Untuk peningkatan spesifikasi, pengecualian apa pun dari persyaratan kompatibilitas ke belakang (dijelaskan dalam Bagian 3.3.2) yang diminta oleh WG
Untuk peningkatan spesifikasi, rekomendasi dari WG untuk nomor versi yang akan diterapkan pada spesifikasi yang diadopsi
Untuk peningkatan spesifikasi, rekomendasi akhir masa pakai WG untuk versi sebelumnya dari spesifikasi yang diadopsi, termasuk alasan teknis mengapa penghentian atau penarikan versi sebelumnya dari spesifikasi tersebut direkomendasikan atau tidak, dan justifikasi untuk rekomendasinya
Setiap masalah serius yang belum terselesaikan dari anggota BARB atau BTI (misalnya, alasan untuk tidak ada suara selama persetujuan, kekhawatiran yang dihasilkan dari review dokumen uji, atau kekhawatiran bahwa spesifikasi 0.9/CR berada di luar cakupan FRD atau piagam)
Status persiapan Profile Tuning Suite (PTS) atau alat lain yang diperlukan terkait dengan adopsi yang disiapkan oleh BSTS

Direksi dapat memilih untuk menyetujui spesifikasi 0.9 / CR untuk pengujian IOP sebagaimana disyaratkan oleh Anggaran Rumah Tangga [2], sebelum BTI menyetujui dokumen pengujian 0.9 / CR dan sebelum WG menegaskan bahwa rencana pengujian IOP memenuhi persyaratan yang ditentukan dalam Bagian 4.3.1. 0.9. Direksi juga dapat mensyaratkan persetujuannya atas spesifikasi 0.9 / CR untuk pengujian TIO setelah dokumen pengujian XNUMX / CR disetujui oleh BTI.

0.9/CR Stage persyaratan keluar
0.9/CR Stage selesai dan Tahap Validasi dimulai ketika Direksi menyetujui dimulainya pengujian TIO.

4.4 Spesifikasi Pengabaian Proses Pengembangan

WG dapat meminta untuk mengabaikan satu atau lebih dari langkah-langkah proses berikut:

0.5/DIPD Stage
0.7/FIPD Stage
Pengujian IOP dalam Fase Validasi

Untuk meminta pengabaian, WG harus menggunakan template pengabaian proses yang disediakan oleh Bluetooth SIG [8] dan mengajukan permintaan pengabaian kepada setiap komite (yaitu, BARB atau BTI) yang diminta untuk mengajukan kembaliview atau menyetujui draf spesifikasi atau dokumen uji terkait di stage bahwa WG mengusulkan untuk mengabaikan, dan masing-masing komite tersebut harus menyetujui permintaan pelepasan tersebut.

Permintaan pengabaian harus mencakup yang berikut:

Sebuah identifikasi stage(s) yang ingin dikesampingkan oleh WG
Sebuah pembenaran mengapa stage(s) harus dikesampingkan
Identifikasi masing-masing komite (yaitu, BTI dan/atau BARB) yang diperlukan untuk review dan menyetujui permintaan pengabaian

Panitia yang mempertimbangkan pengabaian mungkin mengharuskan perwakilan WG membuat presentasi untuk membenarkan pengabaian proses SMPD sebelum memutuskan permintaan pengabaian.

Jika pengabaian permintaan untuk mengesampingkan beberapa langkah dan sebagian dari pengabaian ditolak dan sebagian disetujui, tanggapan komite harus menunjukkan langkah mana dalam permintaan pengabaian yang disetujui dan mana yang ditolak. Jika permintaan pengabaian ditolak, pemberitahuan penolakan harus menyertakan alasan penolakan.

5. Tahap Validasi

Selama Fase Validasi, WG akan melakukan pengujian TIO pada spesifikasi 0.9/CR dengan tujuan menyampaikan laporan pengujian TIO untuk BARB review dan persetujuan. Bila memungkinkan, pengujian TIO untuk peningkatan spesifikasi harus dilakukan terhadap spesifikasi draft terintegrasi. Selain itu, Anggota Review, seperti yang dipersyaratkan oleh Anggaran Rumah Tangga [2], dimulai selama fase ini.

Jika spesifikasi (atau peningkatan) tidak memerlukan pengujian IOP, maka pengujian IOP dalam Tahap Validasi dapat dicabut menggunakan proses yang dijelaskan dalam Bagian 4.4.

Selama pengujian TIO (yang mungkin merupakan satu atau lebih peristiwa), WG harus melacak masalah menggunakan sistem pelacakan masalah Bluetooth SIG dan beralih untuk memasukkan pembaruan pada spesifikasi draf, dokumen pengujian, dan rencana pengujian TIO. Setelah pengujian TIO selesai, WG harus menyelesaikan pembaruan pada spesifikasi draf dan dokumen pengujian untuk mengatasi semua masalah, dan menyiapkan dan menyerahkan laporan pengujian TIO ke BARB untuk ditinjau ulang.view dan persetujuan. Hal ini diilustrasikan pada Gambar 5.1.

Selama Tahap Validasi ada beberapa aktivitas yang mungkin dimulai. Kegiatan ini dapat terjadi secara paralel dan termasuk yang berikut ini:

Spesifikasi 0.9/CR yang telah disetujui Direksi disediakan untuk semua anggota oleh BSTS dengan pemberitahuan dimulainya Pendaftaran Anggotaview jangka waktu yang disyaratkan oleh Anggaran Rumah Tangga.
Setiap pembaruan yang diperlukan dimasukkan ke dalam CSS (yang mungkin disematkan dalam CR dari spesifikasi yang Disingkat).
Definisi karakteristik atau deskriptor dimasukkan ke dalam spesifikasi GSS serta PTS untuk pengujian IOP.
Definisi properti mesh dimasukkan ke dalam spesifikasi MDP serta PTS untuk pengujian IOP.
BSTS memungkinkan pendaftaran platform IOP dan alat entri hasil sebagai persiapan untuk pengujian IOP.
Pengujian IOP, jika diperlukan (lihat Bagian 5.1).
Review komentar dan masalah, termasuk yang diajukan sebagai hasil pengujian TIO, diproses dan perubahan dimasukkan ke dalam draf spesifikasi.

5.1 Pengujian IOP

Tujuan utama pengujian TIO adalah untuk memvalidasi spesifikasi dengan, misalnya,ample, memeriksa akurasi dan ambiguitas dalam teks, reviewing untuk setiap kesalahan dan kelalaian desain mendasar, dan memberikan validasi terhadap persyaratan yang ditetapkan sebelumnya yang dikembangkan sebelumnya dalam proses pengembangan spesifikasi. Pengujian TIO dapat mengakibatkan perubahan pada spesifikasi draf dan beberapa peristiwa pengujian TIO mungkin diperlukan untuk menyelesaikan semua pengujian yang diperlukan.

Penting untuk memberikan kesempatan kepada anggota di luar WG untuk berpartisipasi dalam pengujian TIO karena mereka memberikan kesempatan yang independen view spesifikasi dan dapat mengungkap area ambiguitas dalam spesifikasi yang mungkin tidak jelas bagi anggota WG yang mengembangkan draft. Sebelum setiap acara tes IOP, BSTS akan membuat detail acara, spesifikasi draf terbaru, Test Suite, dan rencana tes IOP tersedia dan akan memberi tahu semua anggota idealnya satu bulan sebelum setiap acara. Spesifikasi draf yang diperbarui, Test Suite, dan rencana pengujian IOP yang digunakan pada peristiwa pengujian IOP harus tersedia setidaknya satu minggu sebelum setiap peristiwa.

Selama pengujian IOP, kombinasi platform berpasangan akan mencoba menjalankan pengujian dan peserta pengujian IOP akan mencatat hasil lulus / gagal dari setiap pengujian dan komentar. Ringkasan hasil yang dianonimkan (mengacu pada misalnya, "Platform A", "Platform B", dll.) Dan setiap komentar, akan dikumpulkan selama acara uji IOP dan tersedia bagi anggota WG selama dan setelah IOP acara uji. Jika informasi tambahan diperlukan untuk mendapatkan pemahaman yang lebih baik tentang komentar atau kegagalan yang terjadi selama pengujian IOP, BSTS dapat bertindak sebagai perantara untuk mengumpulkan informasi lebih lanjut dari anggota yang mengirimkan.

Jika memungkinkan, PTS harus diperbarui untuk mendukung pengujian IOP dengan platform di semua lapisan di atas Host Controller Interface (HCI), dan hadir di acara pengujian IOP untuk lapisan tersebut. Alat pengujian lain mungkin juga hadir di acara uji IOP. Ringkasan hasil pengujian dengan PTS atau alat uji lainnya (jika ada) harus disertakan dalam laporan pengujian TIO.

Pengujian IOP akan terbuka untuk semua anggota yang ingin memberikan implementasi prototipe, namun, Bluetooth SIG dapat mensyaratkan partisipasi pada penerimaan perjanjian dengan Bluetooth SIG (termasuk perjanjian partisipasi dan kerahasiaan). WG bertanggung jawab untuk memproses dan menyelesaikan masalah yang ditemukan selama pengujian IOP, dan memperbarui dokumen yang terpengaruh; Perubahan yang disetujui WG harus dimasukkan sebagai pembaruan pada spesifikasi draf dan dokumen uji untuk digunakan di setiap acara uji IOP.

Sebelum Fase Validasi, WG dapat melakukan pengujian TIO awal di acara yang hanya terbuka untuk anggota WG, namun hasil pengujian informal mungkin tidak disertakan dalam hasil tes TIO.

Mungkin saja semua langkah yang mengarah ke acara tes IOP pertama diikuti, termasuk tanggal dan lokasi TIO yang diumumkan dengan maksud untuk memulai pengujian TIO, tetapi persetujuan Direksi belum diperoleh sebelum dimulainya acara pengujian. Dalam hal ini, Direksi dapat mengotorisasi pencantuman hasil tes yang telah dikumpulkan sebelum persetujuan Direksi untuk memulai pengujian TIO, dengan ketentuan bahwa hasil yang dikumpulkan didasarkan pada spesifikasi yang sama dan Test Suite telah disetujui oleh Direksi.

Pengujian IOP tidak diperlukan untuk penyempurnaan spesifikasi CSS, GSS, atau MDP.

Laporan tes IOP
Setelah pengujian TIO selesai, WG harus menyerahkan laporan pengujian TIO ke BARB dengan tujuan menunjukkan bahwa jumlah platform independen yang diperlukan telah lulus tes yang dipersyaratkan. BARB harus mengulangview dan menyetujui atau menolak laporan pengujian TIO dan akan memberitahu WG jika diperlukan pengujian TIO tambahan sebelum menyerahkan paket spesifikasi Voting Draft kepada Direksi. BSTS dan WG harus memastikan bahwa tidak ada informasi pengenal anggota yang muncul dalam laporan pengujian TIO sebelum menyerahkan laporan ke BARB.

Laporan tes IOP harus mencakup:

Daftar semua peristiwa uji IOP yang terjadi selama Fase Validasi termasuk tanggal dan lokasinya.
Jumlah perusahaan anggota dan platform independen yang berpartisipasi di setiap acara IOP termasuk apakah PTS digunakan.
Daftar spesifikasi, Test Suite, dan versi rencana pengujian IOP yang digunakan di setiap acara.
Ringkasan eksekutif yang menyatakan apakah semua kasus tes memenuhi kriteria kelulusan minimum atau tidak.
Ringkasan dari setiap varian dari persyaratan rencana pengujian TIO yang didefinisikan dalam Bagian 4.3.1 dan alasan untuk setiap varian.
Ringkasan cakupan PTS untuk kasus uji di Test Suite.
Daftar semua kasus uji (termasuk uji kompatibilitas mundur) dari rencana uji IOP, jumlah kelulusan uji, jumlah kegagalan uji, dan apakah kriteria minimum terpenuhi per kasus uji termasuk penjelasan mengapa persyaratan tidak ada bertemu.
Ringkasan masalah, komentar, dan pertanyaan di setiap acara (termasuk yang filed terhadap spesifikasi selama pengujian TIO) dan dampaknya terhadap spesifikasi dan dokumen pengujian.

5.2 Persyaratan keluar Fase Validasi

Fase Validasi selesai dan Fase Persetujuan / Adopsi dimulai ketika BARB telah menyetujui laporan tes IOP (kecuali tes dibebaskan oleh BARB) dan semua persyaratan berikut telah dipenuhi:

BSTS telah membuat spesifikasi 0.9/CR yang disetujui tersedia untuk semua anggota untuk Re Anggotaview sebagaimana disyaratkan oleh Anggaran Rumah Tangga dan memberitahukan semua anggota tentang ketersediaannya.
Semua masalah yang diidentifikasi selama pengujian TIO, dan yang memiliki dampak pengujian, telah dimasukkan dan diuji.
WG telah menyelesaikan pengujian IOP (kecuali pengujian dibebaskan oleh BARB).

6. Tahap Adopsi / Persetujuan

Selama Fase Adopsi/Persetujuan, spesifikasi dan dokumen pengujian terkait diselesaikan, persetujuan BARB, BQRB, dan BTI diterima, pemberitahuan tentang Tanggal Adopsi yang diusulkan diterbitkan bersama dengan versi final dari draf spesifikasi yang diserahkan kepada Direksi untuk diadopsi ( Voting Draft), dan paket spesifikasi akhir diserahkan kepada Direksi. Setelah durasi minimum Member Review disyaratkan oleh Anggaran Rumah Tangga [2]) telah dipenuhi, Direksi akan mempertimbangkan spesifikasi untuk diadopsi pada Tanggal Adopsi. Setelah adopsi, spesifikasi diterbitkan dan sistem kualifikasi diaktifkan. Fase Adopsi/Persetujuan diilustrasikan pada Gambar 6.1.

6.1 Draf Pemungutan Suara

Draf Pemungutan Suara dibuat dengan memasukkan pembaruan (disediakan dalam Tahap Validasi) ke dalam dokumen spesifikasi yang diperlukan, dan menyiapkan draf akhir dari spesifikasi baru. Untuk peningkatan spesifikasi, BSTS akan membuat spesifikasi terintegrasi dengan mengintegrasikan satu atau lebih CR (s) ke dalam versi spesifikasi yang lebih tinggi yang diadopsi sebelumnya (lihat Bagian 4.3.2) jika belum diselesaikan sebelum Fase Validasi.

Jika perubahan dilakukan pada spesifikasi selama fase ini dan WG, BARB, atau BTI menentukan bahwa setiap perubahan memerlukan pengujian IOP tambahan, spesifikasi akan kembali ke bagian pengujian IOP dari Tahap Validasi agar WG melakukan pengujian tambahan. Selama Fase Adopsi / Persetujuan, dokumen-dokumen berikut ini akan dilengkapi dan tersedia untuk Direksi sebelum Tanggal Adopsi:

Draf Pemungutan Suara
Semua spesifikasi pendukung (yaitu, CSS, GSS, MDP) seperti yang dipersyaratkan untuk jenis spesifikasi (atau peningkatan) yang relevan, jika tidak diadopsi sebelumnya
Untuk peningkatan spesifikasi, versi modifikasi yang dilacak dari versi spesifikasi yang diadopsi menunjukkan perubahan yang diusulkan dalam Voting Draft
Penjelasan dari WG tentang persyaratan kompatibilitas mundur (seperti yang dijelaskan dalam Bagian 3.3.2) yang belum terpenuhi dan justifikasi untuk pengecualian apa pun
Deskripsi dari WG tentang persyaratan rencana pengujian TIO (seperti yang dijelaskan dalam Bagian 4.3.1) yang belum terpenuhi dan pembenaran untuk setiap penyimpangan bersama dengan laporan pengujian TIO (yang dapat diberikan dengan memberikan tautan ke salinan di Bluetooth SIG weblokasi)
Rekomendasi dari WG untuk penghentian atau penarikan versi sebelumnya dari spesifikasi yang diadopsi bersama dengan pembenaran, menyoroti perubahan sejak 0.9/CR Stage rekomendasi akhir hidup
Ringkasan, disiapkan oleh WG, tentang perubahan fitur atau fungsionalitas sejak spesifikasi 0.9 / CR (jika ada)
Ringkasan, yang disiapkan oleh BARB, tentang kekhawatiran yang diajukan oleh anggota BARB bahwa spesifikasi yang dihasilkan oleh WG berada di luar cakupan piagam yang disetujui oleh Direksi (jika ada)
Daftar masalah hukum yang belum terselesaikan yang tersisa dari hukum review (jika ada)
Rangkaian Pengujian yang disetujui BTI, bersama dengan ringkasan cakupan pengujian dari spesifikasi Draf Pemungutan Suara yang disetujui WG. Dalam kasus fungsionalitas yang baru ditambahkan atau dimodifikasi tanpa cakupan pengujian, diperlukan justifikasi tertulis untuk penghilangan tersebut
ICS dan IXIT yang disetujui BTI (jika dipersyaratkan oleh spesifikasi)
TCRL disetujui oleh BTI dan BQRB
Laporan yang disiapkan oleh BSTS bersama dengan BTI mengenai status kesiapan alat (misalnya, PTS dan alat uji lainnya, Bluetooth Launch Studio) termasuk jika ada kasus pengujian di TCRL yang tidak didukung oleh alat uji
Ringkasan, disiapkan oleh WG, dari semua nomor yang diperlukan
Daftar periksa adopsi yang disiapkan oleh BSTS dan WG yang menunjukkan bahwa semua kiriman di bagian ini semuanya telah diselesaikan
Semua informasi lain yang diminta oleh Direksi

Selama Fase Adopsi / Persetujuan, WG harus menggunakan sistem pelacakan masalah Bluetooth SIG untuk menangkap masalah dan komentar terhadap rancangan spesifikasi dan dokumen pengujian sehingga mereka diperhitungkan dalam finalisasi spesifikasi Draf Pemungutan Suara. Untuk peningkatan spesifikasi, semua ralat yang disetujui yang relevan (yaitu ralat yang disetujui belum terintegrasi) harus dimasukkan, dan harus diidentifikasi menggunakan perubahan terlacak.

WG harus menyerahkan draf spesifikasi akhir kepada BSTS untuk pertimbangan hukumview. Untuk spesifikasi baru, legal review akan mencakup seluruh spesifikasi. Untuk peningkatan spesifikasi, review akan fokus terutama pada bagian spesifikasi yang diubah. Tujuan pemeriksaan hukumview terutama untuk mengidentifikasi risiko hukum yang harus dipertimbangkan dan dicari penyelesaiannya oleh WG. Umpan balik hukum akan dikategorikan berdasarkan tingkat keparahan. Jika tinjauan hukum opsionalview dilakukan pada 0.9/CR Stage, versi yang diajukan untuk peninjauan hukumview harus menunjukkan, sebagai perubahan terlacak, semua perubahan yang dibuat sejak versi tersebut (dihasilkan oleh WG atau BSTS). Setelah menyelesaikan pemeriksaan hukumview, WG dan BSTS akan menyepakati umpan balik yang akan dimasukkan ke dalam draf spesifikasi. Jika ada komentar hukum yang belum terselesaikan dari legal review mengenai rancangan spesifikasi, Ketua WG dapat meminta waktu pada agenda Direksi untuk menyepakati resolusi.

Sejalan dengan hukum review, WG harus menyerahkan draft spesifikasi ke BARB untuk review. Setelah pengajuan awal ke BARB, BSTS akan memberitahu semua anggota bahwa draft spesifikasi telah diserahkan ke BARB untuk review dan itu juga tersedia untuk Anggota Review. Jika WG mengajukan pembaruan pada draf spesifikasi untuk BARB re-review, BSTS akan mengirimkan pemberitahuan tambahan kepada semua anggota secara berkala.

Setelah menyelesaikan BARB review, WG dan BARB akan menyepakati umpan balik yang akan dimasukkan ke dalam rancangan spesifikasi.

Jika hukum review menghasilkan perubahan substantif, pertimbangan tambahanview oleh BARB mungkin diperlukan. Demikian pula, jika BARB review mengakibatkan perubahan substantif, BSTS akan menentukan apakah tambahan hukumview dari perubahan tersebut diperlukan. Setelah menyelesaikan pemeriksaan hukumview dan BARB kembaliview, BARB harus menyetujui atau menolak Rancangan Pemungutan Suara.

Jika ada dokumen tes yang perlu diperbarui, BSTS akan membantu WG dalam memperbarui dokumen tes. BTI harus menyetujui atau menolak dokumen uji. Jika disetujui oleh BTI, BTI akan membantu menyelesaikan TCRL dan mengirimkan dokumen ini ke BQRB bersama dengan ICS, IXIT, dan Test Suite terkait. BSTS akan memperkirakan tanggal rapat Direksi ketika Direksi bermaksud untuk memberikan suara pada adopsi Voting Draft (Adoption Date) dan memberikannya BTI untuk digunakan dalam TCRL. Persetujuan BARB untuk spesifikasi, persetujuan BTI untuk semua dokumen pengujian (termasuk Test Suite, TCRL, ICS, dan IXIT), dan persetujuan BQRB dari TCRL harus dilakukan pada atau sebelum Tanggal Adopsi.

BSTS akan menginformasikan semua anggota tentang finalisasi dan ketersediaan Draf Pemungutan Suara dan Tanggal Adopsi. Tanggal Adopsi akan ditetapkan tidak lebih awal dari 60 hari setelah anggota diberitahu tentang spesifikasi 0.9/CR yang disetujui Direksi, kecuali Anggota Review periode dipersingkat oleh Direksi sesuai dengan Anggaran Rumah Tangga, dan setidaknya 14 hari setelah pemberitahuan Tanggal Adopsi diberikan kepada anggota sesuai dengan Anggaran Rumah Tangga. Untuk kasus di mana beberapa CR telah diintegrasikan ke dalam Draf Pemungutan Suara, dimulainya Re Anggotaview adalah tanggal di mana anggota diberitahu tentang CR terbaru yang disetujui Direksi.

Setelah pemberitahuan Tanggal Adopsi diberikan kepada anggota, koreksi yang disetujui Direksi untuk kesalahan ketik dalam Voting Draft diizinkan. Garis waktu Adopsi Spesifikasi diilustrasikan pada Gambar 6.2.

6.2 Nomor yang ditetapkan

Bluetooth SIG menyimpan satu set nomor yang ditetapkan untuk umum di Bluetooth SIG Assigned Numbers websitus [7]. Angka-angka yang ditetapkan ini dikelompokkan dalam berbagai ruang angka (kumpulan angka terkait tanpa duplikat). Nomor yang ditetapkan mungkin tumpang tindih dengan nomor lain yang ditetapkan dalam ruang nomor yang berbeda, tetapi tidak ada nomor dalam ruang nomor yang diizinkan untuk digunakan kembali. Berbagai ruang angka didefinisikan dalam spesifikasi yang mendefinisikan penggunaan angka yang ditetapkan.

Setelah BARB menyetujui laporan uji TIO, WG akan mengajukan permintaan kepada BARB untuk menetapkan nomor baru dalam ruang nomor yang disyaratkan oleh spesifikasi akhir. BARB akan kembaliview permintaan dan bekerja dengan BSTS untuk menentukan nomor yang ditetapkan. Setelah persetujuan BARB, BSTS akan menjadwalkan publikasi nomor yang ditetapkan agar tersedia untuk umum di Bluetooth SIG Assigned Numbers websitus [7] dalam waktu satu minggu dari adopsi spesifikasi.

Setelah publikasi nomor yang ditetapkan pada Bluetooth SIG Assigned Numbers websitus atau dalam spesifikasi yang diadopsi terjadi, nomor yang ditetapkan dimaksudkan untuk tidak berubah (tidak berubah dalam nilai atau makna). Jika mereka menjadi tidak dapat digunakan karena alasan tertentu, mereka menjadi nilai yang dicadangkan dan tidak diizinkan untuk digunakan kembali.

6.3 Persyaratan keluar dari Fase Adopsi / Persetujuan

Tahap Persetujuan / Adopsi selesai ketika Direksi telah mengadopsi spesifikasi dan kegiatan pasca adopsi berikut telah diselesaikan:

BSTS telah membuat nomor akhir yang ditetapkan tersedia untuk umum di Bluetooth SIG weblokasi.
BSTS telah membuat spesifikasi yang diadopsi tersedia untuk umum di Bluetooth SIG weblokasi
BSTS telah membuat semua dokumen pendukung (misalnya, CSS, GSS, MDP) yang diperlukan untuk spesifikasi yang relevan tersedia untuk umum di Bluetooth SIG weblokasi.
BSTS telah membuat dokumen pengujian terkait tersedia untuk semua anggota di Bluetooth SIG weblokasi.
Untuk peningkatan spesifikasi, BSTS telah membuat versi pelacakan perubahan informatif dari versi spesifikasi yang diadopsi sebelumnya dengan semua perubahan yang dibuat oleh versi yang baru diadopsi dan membuatnya tersedia untuk semua anggota di Bluetooth SIG weblokasi.
BSTS telah mengaktifkan sistem kualifikasi.
BSTS telah memberi tahu semua anggota tentang ketersediaan spesifikasi yang diadopsi dan semua dokumen pendukung.

Bluetooth SIG berencana untuk menyelesaikan aktivitas pasca-adopsi ini dalam waktu satu minggu setelah adopsi spesifikasi.

7. Tahap Pemeliharaan Spesifikasi

Fase Pemeliharaan Spesifikasi dimulai setelah Fase Adopsi / Persetujuan selesai. Jika ditemukan masalah (mis., Ambiguitas kata atau kesalahan teknis) dengan spesifikasi atau dokumen pengujian terkait, masalah tersebut harus didokumentasikan dengan membuat proposal errata menggunakan alat Bluetooth SIG Errata. Spesifikasi proposal erratum akan diproses, dikategorikan, dan disetujui sesuai EPD [3]. Test Suite erratum diproses dan dikategorikan menurut TSTO [5]. Jika ada konflik antara SMPD dan EPD atau TSTO, SMPD akan diutamakan.

Kesalahan spesifikasi hanya boleh digunakan untuk memperbaiki kesalahan teknis atau editorial dalam spesifikasi Bluetooth akhir yang diadopsi. Penambahan, perubahan, dan penghapusan fungsionalitas hanya dapat dilakukan melalui proses peningkatan spesifikasi yang dijelaskan sebelumnya dalam dokumen ini.

7.1 Mempercepat proses erratum

Ketika erratum disetujui mengikuti proses yang didefinisikan dalam EPD [3], WG, BARB, atau BSTS dapat merekomendasikan bahwa itu dianggap mendesak dan harus dipercepat. Apabila hal ini terjadi, BSTS bersama dengan WG atau BARB akan menyampaikan rekomendasi tersebut kepada Direksi. Direksi akan memutuskan apakah akan menerima atau menolak rekomendasi tersebut. Jika rekomendasi diterima, BSTS akan segera memasukkan erratum yang disetujui ke dalam template erratum [8] dan bekerja dengan WG yang bertanggung jawab untuk menyelesaikan Koreksi Errata yang Dipercepat untuk diserahkan kepada WG untuk review dan persetujuan.

Sebuah selesaiview dari proses erratum dipercepat diilustrasikan pada Gambar 7.1.

Dokumen-dokumen berikut harus dilengkapi dan disediakan untuk Direksi sebelum Tanggal Adopsi:

Draf Koreksi Kesalahan Dipercepat yang disetujui BARB.
Penjelasan dari WG tentang persyaratan kompatibilitas ke belakang (seperti yang dijelaskan dalam Bagian 3.3.2) yang belum terpenuhi dan justifikasi untuk pengecualian apa pun.
Daftar masalah hukum yang belum terselesaikan yang tersisa dari hukum review (jika ada).
Rangkaian Uji, ICS, dan IXIT yang disetujui BTI (jika diperlukan oleh erratum).
TCRL yang disetujui BTI dan BQRB (jika disyaratkan oleh erratum).
Laporan yang diselesaikan oleh BSTS bersama dengan BTI mengenai status kesiapan alat (misalnya, PTS dan alat uji lainnya, Bluetooth Launch Studio) termasuk jika ada kasus pengujian di TCRL yang tidak didukung oleh alat pengujian dan penjelasan (jika diperlukan oleh erratum ).
Daftar periksa adopsi diselesaikan oleh BSTS dan WG yang menunjukkan bahwa kiriman di bagian ini semuanya telah diselesaikan.
Semua informasi lain yang diminta oleh Direksi.

BSTS akan bekerja sama dengan WG yang bertanggung jawab untuk menyelesaikan draft Percepatan Koreksi Errata dan membuat versi untuk diserahkan kepada WG yang bertanggung jawab untuk direvisi.view dan persetujuan.

Pokja harus menyerahkan Percepatan Koreksi Errata kepada BSTS untuk ditindak lanjutiview. Setelah menyelesaikan pemeriksaan hukumview, WG dan BSTS akan menyepakati umpan balik yang akan dimasukkan ke dalam Koreksi Errata Dipercepat. Jika ada komentar hukum yang belum terselesaikan dari legal review atas Percepatan Koreksi Errata, Ketua WG dapat meminta waktu dalam agenda Direksi untuk meminta masukan Direksi atas penyelesaiannya.

Sejalan dengan hukum review, WG harus menyerahkan Expedited Errata Correction ke BARB untuk review. Setelah Koreksi Errata yang Dipercepat diserahkan ke BARB, BSTS akan membuatnya dapat diakses oleh semua anggota untukview dan memberi tahu semua anggota tentang ketersediaannya. Setelah menyelesaikan BARB review, WG dan BARB akan menyepakati umpan balik yang akan dimasukkan ke dalam Koreksi Errata yang Dipercepat.

Jika ada dokumen tes yang perlu diperbarui, BSTS akan membantu WG dalam memperbarui dokumen tes. Setelah BTI menyetujui dokumen pengujian, BTI akan membantu menyelesaikan TCRL dan mengirimkan dokumen tersebut ke BQRB bersama dengan ICS, IXIT, dan Test Suite terkait sebagaimana berlaku. BSTS akan memperkirakan Tanggal Adopsi dan memberikannya kepada BTI untuk digunakan dalam TCRL. Persetujuan BARB dari Koreksi Errata yang Dipercepat, persetujuan BTI untuk semua dokumen pengujian (termasuk Test Suite, TCRL, ICS, dan IXIT sebagaimana berlaku), dan persetujuan BQRB dari TCRL harus dilakukan pada atau sebelum Tanggal Adopsi.

BSTS akan menginformasikan kepada semua anggota tentang finalisasi dan ketersediaan Koreksi Errata yang Dipercepat dan Tanggal Adopsi yang diusulkan. Tanggal Adopsi akan ditetapkan dan diberitahukan kepada semua anggota sesuai dengan Anggaran Rumah Tangga [2] dan Tanggal Adopsi harus setidaknya 14 hari setelah pemberitahuan diberikan kepada anggota. Setelah pemberitahuan tentang Tanggal Adopsi yang diusulkan diberikan kepada anggota, Direksi dapat menyetujui koreksi kesalahan ketik dalam Koreksi Kesalahan yang Dipercepat tanpa memberikan pemberitahuan tambahan tentang Tanggal Adopsi yang diusulkan dan menunggu 14 hari yang diperlukan.

Bluetooth SIG akan membuat Koreksi Kesalahan Dipercepat yang diadopsi tersedia untuk umum dan berencana untuk melakukannya dalam satu minggu setelah adopsi. Pemberitahuan ketersediaannya akan dikeluarkan oleh BSTS untuk semua anggota.

Proses percepatan erratum selesai ketika Direksi telah mengadopsi Koreksi Errata yang Dipercepat dan kegiatan pasca adopsi berikut telah diselesaikan:

BSTS telah membuat Koreksi Errata yang Dipercepat yang diadopsi dan dokumen uji terkait (jika diperlukan oleh kesalahan tersebut) tersedia untuk umum di Bluetooth SIG weblokasi.
BSTS telah mengaktifkan sistem kualifikasi (jika diminta oleh erratum).
BSTS telah memberi tahu semua anggota tentang ketersediaan Koreksi Errata Dipercepat yang diadopsi.

Pada penyelesaian aktivitas ini, Koreksi Errata akan dijadwalkan untuk diintegrasikan ke dalam spesifikasi yang terpengaruh baik sebagai bagian dari peningkatan spesifikasi yang direncanakan atau dalam rilis pemeliharaan yang akan datang seperti yang dijelaskan dalam Bagian 7.2.

7.2 Proses rilis perawatan (spesifikasi .Z)

Sekitar setiap tahun, BSTS akan menentukan apakah ada ralat yang disetujui (disebut sebagai Koreksi Ralat) yang diklasifikasikan sebagai Teknis / Tinggi atau Teknis / Kritis dan yang belum dimasukkan ke dalam teks spesifikasi aktif (yaitu, spesifikasi yang diadopsi yang belum ditinggalkan atau ditarik kembali). Lihat Lampiran A untuk definisi klasifikasi ralat. Seorang Pemilik Spesifikasi (baik WG yang disewa untuk memelihara spesifikasi, atau BARB jika tidak ada WG yang disewa untuk mempertahankan spesifikasi) juga dapat meminta rilis pemeliharaan lebih awal dari spesifikasi aktif untuk memasukkan errata yang disetujui. Setelah penentuan BSTS, atau permintaan Pemilik Spesifikasi, proses rilis pemeliharaan akan dimulai.

Sebuah selesaiview dari proses rilis pemeliharaan diilustrasikan dalam Kesalahan! Sumber referensi tidak ditemukan.

Pada awal proses rilis pemeliharaan, BSTS bersama dengan Pemilik Spesifikasi, BARB, dan BTI akan mengembangkan dan mempresentasikan rencana kepada Direksi untuk memasukkan Koreksi Errata ke dalam versi spesifikasi yang dipublikasikan. Rencana yang diusulkan harus menunjukkan apakah Koreksi Errata akan dimasukkan ke dalam rilis pemeliharaan spesifikasi (yaitu, versi .Z) atau peningkatan spesifikasi yang sedang berlangsung (yaitu, versi XY). Rencana yang diusulkan harus mempertimbangkan apakah ada fitur wajib baru yang telah ditambahkan antara versi spesifikasi yang diadopsi, perkiraan waktu ketika peningkatan spesifikasi berikutnya direncanakan untuk diadopsi, dan faktor-faktor lainnya.

Setelah rencana disetujui oleh Direksi, BSTS bersama dengan Pemilik Spesifikasi akan melanjutkan untuk memasukkan semua Koreksi Errata Teknis / Menengah, Teknis / Tinggi, dan Teknis / Kritis ke dalam rancangan spesifikasi yang disebut sebagai “Draf Rilis Pemeliharaan”. Untuk Editorial atau Teknis / Koreksi Errata Rendah, jika Koreksi Errata berlaku untuk lebih dari satu versi spesifikasi, BSTS akan, kecuali Direksi menunjukkan sebaliknya, mengintegrasikan errata tersebut hanya ke dalam versi spesifikasi yang lebih tinggi terbaru pada pembaruan berikutnya dari versi itu . Tidak ada perubahan yang dapat disertakan dalam Draf Rilis Pemeliharaan selain memasukkan Koreksi Errata. Setiap Draf Rilis Pemeliharaan harus mengidentifikasi semua Koreksi Errata yang digabungkan menggunakan pelacakan perubahan untuk menunjukkan perubahan yang diusulkan ke versi yang diadopsi sebelumnya dari spesifikasi yang dipublikasikan.

Waktu penggabungan yang diusulkan untuk setiap Koreksi Errata dalam Draf Rilis Pemeliharaan akan bergantung pada dampak Rangkaian Uji: semua Koreksi Errata yang tidak memiliki dampak Rangkaian Uji dapat langsung digabungkan, tetapi Koreksi Errata yang berdampak pada Rangkaian Uji akan dimasukkan diproses sehingga waktunya bertepatan dengan pembaruan ke TCRL.

BTI dan BSTS akan menetapkan tenggat waktu untuk memasukkan Koreksi Errata dengan dampak Rangkaian Pengujian dalam Draf Rilis Pemeliharaan. Batas waktu ini biasanya 3 hingga 6 bulan sebelum tanggal persetujuan yang direncanakan untuk rilis TCRL utama berikutnya. Koreksi Errata dengan dampak Rangkaian Uji yang melewati tenggat waktu penyertaan akan diproses sebagai bagian dari rilis TCRL tahunan berikutnya. Oleh karena itu, kecuali rilis sebelumnya diminta, waktu maksimum untuk Koreksi Errata Teknis / Tinggi atau Teknis / Kritis untuk disertakan dalam pembaruan spesifikasi adalah sekitar 15 hingga 18 bulan.

Pemilik Spesifikasi harus menyerahkan Draft Rilis Pemeliharaan yang telah disetujui sebagai final untuk re . hukumview. hukum review akan fokus terutama pada bagian spesifikasi yang diubah. Setelah menyelesaikan pemeriksaan hukumview, Pemilik Spesifikasi dan BSTS akan menyetujui umpan balik untuk dimasukkan ke dalam Draft Rilis Pemeliharaan. Jika ada komentar hukum yang belum terselesaikan dari legal review pada Maintenance Release Draft, Pemilik Spesifikasi dapat meminta waktu pada agenda Direksi untuk meminta masukan Direksi mengenai penyelesaiannya.

Sejalan dengan hukum review, pemilik Spesifikasi harus menyerahkan Draft Rilis Pemeliharaan ke BARB untuk review. Setelah Draft Rilis Pemeliharaan diserahkan ke BARB, BSTS akan membuatnya dapat diakses oleh semua anggota untuk review dan memberi tahu semua anggota tentang ketersediaannya. Setelah menyelesaikan BARB review, Pemilik Spesifikasi dan BARB akan menyetujui umpan balik untuk dimasukkan ke dalam draf spesifikasi.

Untuk Koreksi Kesalahan yang memengaruhi dokumen pengujian, dan di mana kesalahan pengujian yang sesuai akan diproses tepat waktu untuk rilis TCRL mendatang, BSTS akan bekerja dengan Pemilik Spesifikasi dan BTI untuk memperbarui dokumen pengujian. Setelah BTI menyetujui dokumen pengujian, BSTS akan memperkirakan Tanggal Adopsi dan memberikan Tanggal Adopsi yang diusulkan kepada BTI untuk digunakan dalam TCRL. BTI akan mengirimkan TCRL ke BQRB bersama dengan ICS, IXIT, dan Test Suite terkait sebagaimana berlaku. Persetujuan BARB atas spesifikasi, persetujuan BTI untuk semua dokumen pengujian (termasuk Test Suite, TCRL, ICS, dan IXIT sebagaimana berlaku), dan persetujuan BQRB dari TCRL harus dilakukan pada atau sebelum Tanggal Adopsi.

BSTS akan menginformasikan semua anggota tentang finalisasi dan ketersediaan Draf Pemungutan Suara dan Tanggal Adopsi yang diusulkan. Tanggal Adopsi akan ditetapkan dan diberitahukan kepada semua anggota sesuai dengan Anggaran Rumah Tangga dan Tanggal Adopsi harus setidaknya 14 hari setelah pemberitahuan pemberitahuan diberikan kepada anggota. Setelah pemberitahuan tentang Tanggal Adopsi yang diusulkan diberikan kepada anggota, Direksi dapat menyetujui koreksi kesalahan ketik dalam Voting Draft tanpa memberikan pemberitahuan tambahan tentang Tanggal Adopsi yang diusulkan dan menunggu 14 hari yang diperlukan.

Dokumen-dokumen berikut harus dilengkapi dan disediakan untuk Direksi sebelum Tanggal Adopsi:

Draf Pemungutan Suara
Versi draft Voting yang dilacak yang menunjukkan semua perubahan ke versi spesifikasi yang diadopsi yang memiliki nilai XY yang sama (misalnya, jika Voting Draft diusulkan sebagai versi 1.4.2, perubahan tersebut akan dilacak terhadap 1.4.1 versi spesifikasi)
Rekomendasi dari Pemilik Spesifikasi untuk penghentian atau penarikan versi sebelumnya dari spesifikasi yang diadopsi bersama dengan justifikasi
Daftar masalah hukum yang belum terselesaikan yang tersisa dari hukum review (jika ada)
Rangkaian Uji, ICS, dan IXIT yang disetujui BTI (jika diperlukan oleh rilis pemeliharaan)
TCRL yang disetujui BTI dan BQRB (jika diperlukan oleh rilis pemeliharaan)
Laporan yang diselesaikan oleh BSTS bersama dengan BTI mengenai status kesiapan alat (mis., PTS dan alat uji lainnya, Bluetooth Launch Studio) termasuk kasus pengujian apa pun di TCRL yang tidak didukung oleh alat uji, dan penjelasan (jika diperlukan oleh pemeliharaan melepaskan)
Daftar periksa adopsi yang diselesaikan oleh BSTS dan Pemilik Spesifikasi yang menunjukkan bahwa kiriman di bagian ini semuanya telah selesai
Semua informasi lain yang diminta oleh Direksi

Proses rilis pemeliharaan selesai ketika Direksi telah mengadopsi Draf Pemungutan Suara dan kegiatan pasca adopsi berikut telah diselesaikan:

BSTS telah membuat spesifikasi yang diadopsi dan dokumen uji terkait (jika diperlukan oleh rilis pemeliharaan) tersedia untuk umum di Bluetooth SIG weblokasi.
BSTS telah membuat versi pelacakan perubahan informatif dari versi spesifikasi yang diadopsi sebelumnya dengan semua perubahan yang tergabung dalam versi yang baru diadopsi tersedia untuk semua anggota di Bluetooth SIG weblokasi.
BSTS telah mengaktifkan sistem kualifikasi.
BSTS telah memberi tahu semua anggota tentang ketersediaan spesifikasi yang diadopsi dan dokumen pendukung.

Bluetooth SIG berencana untuk menyelesaikan aktivitas pasca-adopsi ini dalam waktu satu minggu setelah adopsi spesifikasi.

Setelah menyelesaikan aktivitas ini, spesifikasi tetap dalam fase Pemeliharaan Spesifikasi hingga spesifikasi tidak digunakan lagi atau ditarik, seperti yang didefinisikan dalam Bagian 8.

8. Spesifikasi Fase Akhir Masa Pakai

Spesifikasi mungkin tidak berlaku lagi atau ditarik ketika digantikan oleh versi yang lebih baru, ditentukan secara teknis tidak mencukupi, atau karena alasan lain. Spesifikasi yang tidak berlaku lagi dan ditarik diarsipkan dan tidak lagi diperbarui. Spesifikasi yang tidak berlaku lagi dan ditarik diperlakukan berbeda dalam Program Kualifikasi Bluetooth.

Setiap anggota, kelompok, atau komite dapat mengajukan rekomendasi untuk menghentikan atau menarik spesifikasi bersama dengan timeline terkait ke BSTS (melalui email ke

spesifikasi.manager@bluetooth.com) kapan saja. BSTS juga dapat merekomendasikan penghentian atau penarikan spesifikasi dan garis waktu terkait. BSTS akan merujuk rekomendasi ke BARB dan kelompok atau komite yang bertanggung jawab untuk memelihara spesifikasi untuk review dan umpan balik.

BARB dan grup atau komite yang bertanggung jawab akan mengevaluasi rekomendasi untuk membatalkan atau menarik spesifikasi dan mempertimbangkan kriteria berikut (tidak lengkap):

Apakah ada fungsionalitas di versi spesifikasi sebelumnya yang sudah usang atau tidak boleh digunakan?
Apakah fungsi wajib baru telah ditambahkan ke versi yang lebih baru?
Apakah ada kekurangan di versi sebelumnya yang mengganggu pengoperasian atau interoperabilitas yang telah diperbaiki di versi yang lebih baru dan diperlukan untuk memajukan skenario pengguna yang ada?
Apakah ada fungsionalitas tambahan di versi yang lebih baru yang diperlukan untuk memajukan skenario pengguna baru?
Apakah ada peningkatan kegunaan dan interoperabilitas di versi yang lebih baru?
Apakah ada peningkatan keamanan di versi yang lebih baru?

BARB dan kelompok atau komite yang bertanggung jawab dapat mengusulkan rekomendasi alternatif.

Setelah menerima umpan balik dari BARB atau kelompok atau komite yang bertanggung jawab untuk memelihara spesifikasi, BSTS akan menyampaikan rekomendasi dan umpan balik kepada Direksi untuk dipertimbangkan. Direksi dapat mengundang kelompok atau komite yang bertanggung jawab untuk menjaga spesifikasi yang terkena dampak untuk bertemu dan membahas rekomendasi. Direksi akan mempertimbangkan rekomendasi dan umpan balik dan dapat menyetujui atau memodifikasi proposal tersebut. Direksi akan meminta BSTS untuk memberi tahu semua anggota tentang proposal untuk tidak menggunakan atau menarik spesifikasi dan jadwal terkait untuk jangka waktu 30 hari.view periode untuk memungkinkan semua anggota memberikan umpan balik tambahan sebelum membuat keputusan akhir.

Direksi akan mempertimbangkan umpan balik yang diterima dari anggota. Setelah Direksi menyetujui penghentian atau penarikan spesifikasi, BSTS akan memberi tahu semua anggota tentang keputusan dan jadwal terkait.

8.1 Penghentian

Setelah spesifikasi tidak digunakan lagi, hal berikut akan terjadi:

Spesifikasi tidak akan diperbarui lagi.
WG yang bertanggung jawab akan review semua ralat luar biasa yang ditulis terhadap spesifikasi usang untuk menentukan apakah mereka berlaku untuk spesifikasi lain. Errata dapat ditolak dalam sistem errata dan ditulis ulang sesuai dengan spesifikasi yang berlaku.
WG atau BSTS akan membuat ralat untuk memperbarui referensi yang diperlukan ke spesifikasi yang tidak berlaku lagi dalam spesifikasi lain.
BTI akan memperbarui dokumen pengujian yang berlaku untuk menunjukkan penghentian spesifikasi.
BSTS akan memperbarui Bluetooth SIG websitus dengan panduan mengenai spesifikasi alternatif yang akan digunakan.
Ralat baru tidak dapat lagi dikirimkan dengan spesifikasi yang sudah usang.
Spesifikasi tidak akan dirujuk dalam spesifikasi mendatang.
BSTS akan mengarsipkan versi spesifikasi yang ditandai sebagai usang untuk diakses anggota untuk tujuan historis.

8.2 Penarikan

Setelah spesifikasi ditarik, selain langkah-langkah yang berlaku untuk penghentian, hal berikut akan terjadi:

BTI akan memperbarui dokumen pengujian yang berlaku untuk menunjukkan penarikan spesifikasi.
BSTS akan memperbarui Bluetooth SIG websitus dengan panduan mengenai spesifikasi alternatif yang akan digunakan.
BSTS akan mengarsipkan versi spesifikasi yang ditandai sebagai ditarik untuk diakses anggota untuk tujuan historis.

Direksi dapat memilih untuk menarik spesifikasi segera tanpa mengurangi spesifikasi terlebih dahulu.

9. Proses kertas putih

Kertas putih dibuat untuk tujuan informasional saja. Proses kertas putih berikut berlaku untuk semua Bluetooth WG, EG, SG, dan komite. Bagian ini tidak berlaku untuk dokumen informasional yang hanya digunakan dalam Bluetooth SIG.

Proses ini diilustrasikan pada Gambar 9.1 di bawah.

Sebelum kelompok atau komite mana pun mulai mengerjakan kertas putih yang mereka inginkan untuk diterbitkan oleh Bluetooth SIG, kelompok atau komite akan mempersiapkan baik pembaruan piagam yang diusulkan yang secara jelas mendefinisikan isi yang diusulkan dari kertas putih dan presentasi proposal kertas putih.

Presentasi proposal kertas putih minimal harus mencakup:

Kebutuhan kertas putih
Ringkasan dari isi yang diusulkan dari kertas putih
Penjelasan mengapa konten tidak direkomendasikan untuk dimasukkan sebagai bagian dari spesifikasi
Penonton yang dituju
Rencana pemeliharaan apa pun (yaitu, perkiraan waktu sebelum rilis berikutnya buku putih ini mungkin diperlukan)
Rekomendasi tentang cara menangani buku putih versi sebelumnya, jika ada (misalnya, pengarsipan)

Pembaruan piagam dan presentasi proposal kertas putih harus diserahkan untuk BARB review. Setelah kembaliview dan persetujuan pembaruan piagam oleh BARB, BSTS akan menyerahkan pembaruan piagam kepada Direksi untuk disetujui bersama dengan presentasi proposal kertas putih pendukung.

Jika Direksi menyetujui pembaruan piagam tersebut, grup atau komite dapat melanjutkan penyusunan buku putih.

Ketika kelompok atau panitia telah menyelesaikan pengembangan white paper, BSTS akan melakukan editorial review untuk konsistensi dengan Pedoman Penyusunan Bluetooth.

Setelah penyelesaian komentar BSTS, kelompok tersebut harus menyerahkan kertas putih kepada BSTS untuk pertimbangan hukumview. Setelah menyelesaikan pemeriksaan hukumview, kelompok dan BSTS akan menyepakati umpan balik yang akan dimasukkan ke dalam kertas putih. Jika ada komentar hukum yang belum terselesaikan dari legal review di atas kertas putih, ketua kelompok dapat meminta waktu dalam agenda Direksi untuk meminta masukan Direksi mengenai resolusi.

Sejalan dengan hukum review, kelompok harus menyerahkan kertas putih ke BARB untuk review. Sebagai bagian dari review, BARB dapat merekomendasikan apakah ada bagian dari white paper yang harus dikeluarkan dari white paper dan dimasukkan ke dalam spesifikasi yang mengikuti proses di Bagian 3. BARB juga dapat memutuskan untuk menyerahkan white paper kepada kelompok atau komite lain untuk ditinjau ulang.view. Setelah menyelesaikan BARB review, grup dan BARB akan menyepakati umpan balik yang akan dimasukkan ke dalam buku putih.

Setelah BARB menyetujui white paper tersebut, white paper yang disetujui BARB akan dipresentasikan oleh kelompok penulis atau komite kepada BoD untuk disetujui.

Proses white paper selesai setelah Direksi menyetujui white paper dan kegiatan pasca-persetujuan berikut telah diselesaikan:

BSTS telah membuat kertas putih yang disetujui tersedia untuk umum di Bluetooth SIG weblokasi.
BSTS memberi tahu semua anggota buku putih yang disetujui.
Jika buku putih merupakan peningkatan dari buku putih yang sudah ada, BSTS akan mengarsipkan versi kertas putih untuk diakses anggota untuk tujuan sejarah.

Bluetooth SIG berencana untuk menyelesaikan aktivitas pasca-persetujuan dalam waktu satu minggu setelah persetujuan kertas putih.

10. Referensi

Dokumen Bluetooth yang direferensikan tersedia dari Bluetooth weblokasi http://www.bluetooth.com.

Panduan Draft Bluetooth (tersedia di halaman Template & Dokumen Kelompok Kerja, di https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Anggaran Rumah Tangga Bluetooth SIG, Inc. (tersedia di halaman Dokumen yang Mengatur, di https://www.bluetooth.com/membership-working-groups/membership-types-levels/membership-agreements)
Dokumen Proses Errata Spesifikasi Bluetooth (tersedia di halaman Template Kelompok Kerja & Dokumen, di https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Dokumen Proses Kelompok Kerja (tersedia di halaman Templat & Dokumen Kelompok Kerja, di https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Strategi Uji dan Terminologi Berakhirview dokumen (tersedia di halaman Persyaratan Tes Kualifikasi, di https://www.bluetooth.com/specifications/qualification-test-requirements)
Spesifikasi BTI Review Daftar Periksa Proses (tersedia di halaman Template & Dokumen Kelompok Kerja, di https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Nomor yang Ditetapkan SIG Bluetooth (https://www.bluetooth.com/specifications/assigned-numbers)
Templat dan Dokumen Kelompok Kerja (tersedia di halaman Templat & Dokumen Kelompok Kerja, di https://www.bluetooth.com/membership-working-groups/working-groups/working-group-templates-documents)
GATT Specification Supplement (GSS) (tersedia di halaman Spesifikasi GATT, di https://www.bluetooth.com/specifications/gatt)
Kirimkan Ide untuk Spesifikasi baru https://www.bluetooth.com/specifications/submit-an-idea-for-a-specification

11. Akronim dan singkatan

Tabel A: Akronim dan singkatan

Lampiran A - Klasifikasi tingkat keparahan erratum

Lampiran ini merangkum pedoman klasifikasi tingkat keparahan untuk spesifikasi erratum. Tabel ini akan ditambahkan ke revisi EPD mendatang, dan kemudian bagian ini akan dihapus.

Baca Selengkapnya Tentang Manual Ini & Unduh PDF:

Spesifikasi Dokumen Proses Manajemen (SMPD) - PDF yang dioptimalkan
Spesifikasi Dokumen Proses Manajemen (SMPD) - PDF asli

Ada pertanyaan tentang Manual Anda? Tulis di kolom komentar!

Referensi

Panduan Pengguna