1028 2008

Standard IEEE untuk Tinjauan Perangkat Lunak dan
Masyarakat Komputer IEEE Audit yang

disponsori oleh Perangkat Lunak Sistem & Engineering Standards Committee
TM
IEEE IEEE Std 1028TM-2008
(Revisi IEEE Std 1028-1997)
berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polcia Nacional
de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor
e.
3 Park Avenue
New York, NY 10016-5997, USA
15 Agustus 20081028 pembatasanpembatasan berlaku.
Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polcia Nacional

e. Pembatasan-pembatasan berlaku.
IEEE Std 1028TM-2008

(Revisi IEEE Std 1028-1997)
standard IEEE untuk Tinjauan Perangkat Lunak dan Perangkat
Lunak Sponsor Audit Sistem & Engineering Komite Standar IEEE Masyarakat Komp
uter
16 Juni 2008 Disetujui
IEEE-SA Standards Board
berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polcia Nacional

Abstrak: Lima jenis ulasan perangkat lunak dan audit, bersama-sama dengan prosed
ur yang diperlukan untuk pelaksanaan masing-masing jenis, didefinisikan dalam st
andar ini. Standar ini hanya memikirkan dengan audit kaji ulang dan prosedur unt
uk menentukan; keperluan ulasan atau audit tidak didefinisikan, dan perangai dar
i hasil kajian audit atau tidak ditetapkan. Termasuk tipe adalah ulasan manajeme
n, ulasan teknis, pemeriksaan, berjalan-terusan, dan proses audit.
Kata Kunci:, pemeriksaan, review audit, berjalan-melalui
Institute of Electrical and Electronics Engineers, Inc.

3 Park Avenue, New York, NY 10016-5997, USA
Hak Cipta 2008 oleh Institute of Electrical and Electronics Engineers, Inc.
Semua hak dilindungi undang-undang. Diterbitkan 15 Agustus 2008. Dicetak di Amer
ika Serikat.
IEEE adalah merek dagang terdaftar di A.S. Paten & Trademark Office, dimilik
i oleh Institute of Electrical and Electronics Engineers, Dimasukkan.

PDF To: ISBN 978-0-7381-5768-995806 STD Mencetak: ISBN 978-0-7381-5769-695806 ST
DPD
Tidak Ada bagian publikasi ini dapat diperbanyak dalam bentuk apa pun, dalam seb
uah sistem pengambilan elektronik atau jika tidak, tanpa izin tertulis sebelumny
a dari penerbit.
Standar IEEE dokumen-dokumen yang dikembangkan dalam masyarakat IEEE dan komite
koordinasi standar IEEE Standards Association (IEEE-SA) Standards Board. Standar
IEEE mengembangkan-melalui proses pembangunan konsensus, disetujui oleh America
n National Standards Institute, yang menyatukan relawan mewakili pandangan berva
riasi dan kepentingan untuk mencapai hasil akhir. Para sukarelawan ini tidak sem
estinya anggota Institut dan melayani tanpa ganti rugi. Sementara IEEE mengelola
proses dan menetapkan peraturan untuk mempromosikan keadilan dalam proses pemba
ngunan konsensus, IEEE tidak secara mandiri mengevaluasi, tes, atau verifikasi a
kurasi informasi apa pun yang atau apa pun yang memburuk peradilan yang terkandu
ng dalam standar.
Penggunaan Standard IEEE yang sepenuhnya secara sukarela. Dalam IEEE menolak ber
tanggung jawab atas setiap cedera pada seseorang, atau properti kerusakan lain,
alam apa pun, apakah KHUSUS, TIDAK LANGSUNG, KONSEKUENSIAL, atau melakukan kompe
nsasi, baik langsung maupun tidak langsung yang dihasilkan dari publikasi, pengg
unaan, atau ketergantungan atas ini atau dokumen standar IEEE lainnya.
Dalam IEEE tidak menjamin atau mewakili akurasi atau isi materi yang terdapat di
sini, dan secara tegas menolak segala bentuk jaminan secara tersurat atau tersi
rat, termasuk semua jaminan TERSIRAT MENGENAI KELAYAKAN PRODUK UNTUK DIPERJUALBE
LIKAN ATAU KESESUAIAN UNTUK TUJUAN TERTENTU, atau bahwa penggunaan bahan-bahan y
ang terkandung di sini adalah bebas dari paten. Standar IEEE dokumen-dokumen yan
g disediakan "SEBAGAIMANA."
keberadaan sebuah standard IEEE ini tidak menyiratkan bahwa tidak ada cara lain
untuk menghasilkan, tes, mengukur, membeli, atau menyediakan pasar, barang-baran
g lain dan jasa yang berkaitan dengan cakupan standard IEEE. Lebih jauh lagi, pa
ndangan menyatakan pada waktu standar yang disetujui dan dikeluarkan ini dapat b
erubah membawa tentang melalui perkembangan-perkembangan dalam keadaan seni dan
komentar yang telah diterima dari pengguna dari standar tersebut. Setiap Standar
d IEEE mengalami untuk meninjau setidaknya setiap lima tahun untuk pembuktian at
au revisi. Saat dokumen lebih dari lima tahun dan belum menegaskan, ia adalah ma
suk akal untuk menyimpulkan bahwa isinya, walaupun masih dari beberapa nilai, ti
dak sepenuhnya mencerminkan keadaan dari pengguna seni untuk mengecek untuk mene
ntukan menginventaris bahwa mereka memiliki edisi terbaru standar IEEE apa pun.
Dalam menerbitkan dan membuat dokumen ini tersedia, IEEE tidak menyarankan atau
rendering professional atau layanan lain untuk, atau atas nama, seseorang atau e
ntitas. Dan tidak adalah IEEE untuk melakukan tugas apa pun berhutang oleh orang
lain atau entitas yang lain. Seseorang memanfaatkan, dan ini standar IEEE lain
dokumen, harus bersandar kepada dirinya dan penghakiman independen dalam latihan
mematuhi care dalam keadaan apa pun atau, yang sesuai, carilah nasihat profesio
nal yang kompeten dalam menentukan informasi mengenai kelayakan suatu standard I
EEE.
Penafsiran: Kadang-kadang pertanyaan-pertanyaan
agian dari 227 standar untuk aplikasi tertentu.
i adalah yang menarik perhatian IEEE, Institute
ediakan respons yang sesuai. Sejak Standar IEEE
mungkin muncul mengenai maksud b

Saat kebutuhan untuk interpretas
akan memulai tindakan untuk meny
mewakili sebuah konsensus kepent
ingan yang bersangkutan, penting untuk memastikan bahwa interpretasi apa pun jug
a telah menerima in concurrence with keseimbangan kepentingan. Untuk alasan ini,
IEEE dan anggota masyarakat dari Komite Koordinasi Standar dan tidak dapat memb
erikan respons instan untuk permintaan penafsiran kecuali dalam kasus-kasus di m
ana hal ini sebelumnya telah menerima pertimbangan formal.
Sebuah pernyataan, ditulis atau lisan, yang tidak diproses sesuai dengan IEEE-SA
Standards Board Manual Operasi tidak akan dianggap posisi resmi IEEE atau dari
komite sekolah, dan tidak akan dianggap sebagai, dan tidak akan bergantung sebag
ai, sebuah penafsiran formal IEEE. Pada kuliah, dinner symposia, seminar, atau k
ursus pendidikan, seorang individu yang menyajikan informasi tentang standar IEE
E akan membuat ia jelas bahawa pandangan atau perempuan itu harus dianggap sebag
ai pandangan-pandangan pribadi yang individu daripada posisi formal, penjelasan,
atau penafsiran IEEE.
Komentar untuk revisi Standar-standar IEEE selamat datang dari pihak tertarik, t
erlepas dari afiliasi keanggotaan dengan IEEE. Saran-saran untuk perubahan dalam
dokumen-dokumen yang harus dalam bentuk suatu usulan perubahan teks, bersama-sa
ma dengan mendukung komentar yang sesuai. Komentar pada standar dan permintaan h
arus diserahkan untuk tafsiran alamat berikut:
sekretaris, IEEE-SA Standards Board
445 Cangkul Lane
Piscataway, kereta NJ 08854
USA
otorisasi untuk fotokopi sebagian dari masing-masing standar untuk penggunaan pr
ibadi atau internal yang diberikan oleh Institute of Electrical and Electronics
Engineers, Inc., asalkan biaya yang sesuai akan dibayarkan untuk Jarak Hak Cipta
Center.
Untuk mengatur untuk pembayaran biaya lisensi, harap hubungi Jarak Hak Cipta, Pu
sat Layanan Pelanggan, 222 Rosewood Drive, Danvers, MA 01923 Amerika Serikat; +1
944 750 8400. Izin untuk fotokopi sebagian dari masing-masing standar untuk kel
as pendidikan menggunakan juga dapat diperoleh melalui Pusat Jarak Hak Cipta.
Introduction
pengenalan ini bukan bagian dari IEEE Std 1028-2008, Standard IEEE untuk Audit K
aji Ulang dan perangkat lunak.
Pengenalan ini menyediakan pengguna dengan rasional dan latar belakang kajian, d
an yang dijelaskan dalam standar ini audit dan hubungan mereka untuk standar IEE
E lainnya.
Tujuan
standar ini mendefinisikan lima jenis ulasan perangkat lunak dan audit, bersamasama dengan prosedur yang diperlukan untuk pelaksanaan masing-masing jenis. Stan
dar ini hanya memikirkan dengan mengkaji dan, ia tidak audit menentukan prosedur
untuk menentukan kebutuhan meninjau atau audit, ia juga tidak menetapkan perang
ai dari hasil kajian atau audit. Jenis peninjauan termasuk ulasan manajemen, ula
san teknis, pemeriksaan, dan berjalan-terusan.
Standar ini dimaksudkan untuk digunakan baik dalam konjungsi dengan standar IEEE
lain teknik perangkat lunak atau sebagai definisi yang berdiri sendiri dari kaj
i ulang perangkat lunak dan prosedur audit. Dalam kasus kemudian, manajemen loka
l harus menentukan peristiwa-peristiwa yang mendahului dan ikuti perangkat lunak
aktual berisi tinjauan dan proses audit.
Kebutuhan untuk audit kaji ulang dan dijelaskan dalam beberapa standar IEEE lain
nya, serta disediakan oleh standar lain standar-organisasi menulis. IEEE Std 102
8-2008 yang dimaksudkan untuk mendukung standar lain ini. Dalam keadaan tertentu
, kajian dan audit yang diperlukan oleh standar yang tercantum dalam Lampiran B
dapat dijalankan dengan menggunakan

prosedur yang dijelaskan di sini. Penggunaan IEEE Std 1044-1993 [B8] adalah mend
orong sebagai bagian dari prosedur pelaporan untuk standar ini.
Tujuan aplikasi umum
standar ini berlaku sepanjang cakupan dari perangkat lunak yang dipilih model si
klus hidup dan menyediakan sebuah standar terhadap perangkat lunak yang meninjau
dan rencana audit dapat diolah dan dikaji. Manfaat Maksimum dapat berasal dari
standar ini oleh aplikasi untuk perencanaan awal dalam siklus hidup proyek.
Standar ini untuk tinjauan perangkat lunak dan ditulis dalam pertimbangan audit
dari kedua perangkat lunak dan lingkungan operasi sistem. Ia dapat digunakan di
mana adalah perangkat lunak sistem total entiti atau di tempat-tempat yang merup
akan bagian dari sistem yang lebih besar. Care harus diambil untuk mengintegrasi
kan perangkat lunak meninjau dan kegiatan audit ke dalam sebarang sistem total p
erencanaan siklus hidup; tinjauan perangkat lunak dan harus ada dalam konser aud
it dengan sistem komputer dan perangkat keras berisi tinjauan audit dan yang aka
n menguntungkan seluruh sistem.
Ulasan dan audit yang dilakukan sesuai dengan standar ini mungkin termasuk kedua
untuk proyek internal personel dan pelanggan atau acquirers produk, menurut pro
sedur lokal. Penyuplai mungkin juga disertakan jika diperlukan.
Informasi yang diperoleh selama ulasan perangkat lunak (khususnya inspeksi) mung
kin bermanfaat untuk meningkatkan perangkat lunak pengguna, akuisisi, pengembang
an, pasokan, dan proses pemeliharaan operasi. Penggunaan data peninjauan untuk p
erbaikan diperlukan untuk proses inspeksi.
Perubahan utama sejarah untuk struktur dan isi IEEE Std 1028 selama menyelesaika
n revisi pada tahun 1997. Versi ini telah menegaskan pada tahun 2001. Sebagai ba
gian dari pembuktian kembali, banyak balloters tanggapan tersimpan. Pembuktian y
ang disetujui oleh IEEE Standards Board dengan keengganan bahwa pembuktian kemba
li komentar diatasi selama revisi berikutnya.
sebuah angka-angka dalam tanda kurung setara dengan orang-orang dari bibliografi
dalam Lampiran B.J
iv
Hak Cipta 2008 IEEE. Semua hak dilindungi undang-undang.
Itu adalah konteks untuk revisi saat ini: kontra ider semua komentar-komentar da
ri suara penegasan kembali.
Perubahan struktural tidak menjadi bagian dari upaya ini. Kelompok Kerja diangga
p semua komentar dari pembuktian kembali, apakah yang menyertai negatif atau men
yetujuinya suara, serta penjelasan tambahan keprihatinan bahwa selama revisi ban
gkit.
Dengan satu pengecualian, tidak terjadi perubahan struktural. Pengecualian yang
dimaksudkan untuk memperjelas perbedaan antara penggeledahan dan berjalan-terusa
n oleh memerlukan perbaikan proses untuk menjadi mandatori pemeriksaan (lihat 6.
9), dan untuk menghilangkan perbaikan proses dari berjalan-terusan. Akibatnya, a
da perkembangan yang jelas dalam formalitas dari kebanyakan audit formal,, diiku
ti oleh manajemen dan ulasan teknis, kemudian ke sedikit formal inspeksi, dan me
nyelesaikan dengan kurangnya formal, berjalan-terusan.
Prosedur pengembangan
standar ini telah dikembangkan oleh Kelompok Kerja Peninjauan Teknik Perangkat L
unak. Seluruh prosedur menulis standar dilaksanakan melalui pesan elektronik.
Pemberitahuan
hukum dan peraturan-peraturan pengguna untuk
pengguna dokumen ini harus konsultasikan semua hukum dan peraturan yang berlaku.
Sesuai dengan ketentuan standar ini tidak menyiratkan kepatuhan terhadap persya
ratan peraturan yang berlaku apa pun.
Dinas dari standar tersebut bertanggung jawab untuk mengamati atau merujuk ke pe
rsyaratan peraturan yang berlaku. IEEE tidak, oleh publikasi dari, bermaksud unt
uk mendesak standar tindakan yang tidak sesuai dengan undang-undang yang berlaku
, dan dokumen ini mungkin tidak boleh ditafsirkan sebagai melakukannya.
Hak cipta
dokumen ini adalah hak cipta antar oleh IEEE. Ia adalah tersedia untuk berbagai
macam baik swasta maupun menggunakan. Ini termasuk kedua menggunakan, dengan mer
ujuk, dalam undang-undang dan peraturan-peraturan, dan menggunakan dalam diri sw
asta-, standardisasi, peraturan dan promosi rekayasa metode dan praktik. Dengan
membuat dokumen ini tersedia untuk menggunakan dan pengangkatan oleh pihak yang
berwenang dan pengguna pribadi, IEEE tidak membatalkan hak-hak yang dalam hak ci
pta untuk dokumen ini.
Memperbarui dokumen IEEE
Pengguna standar IEEE harus menyadari bahwa dokumen ini mungkin diganti kapan sa
ja dengan penerbitan edisi baru atau mungkin akan diamandemen dari waktu ke wakt
u melalui penerbitan amandemen, corrigenda, atau kesalahan. Sebuah dokumen IEEE
resmi di setiap titik waktu terdiri dari dokumen edisi saat ini bersama-sama den
gan semua perubahan, corrigenda, atau errata kemudian berlaku. Untuk menentukan
apakah sebuah dokumen yang diberikan adalah edisi saat ini dan apakah ia telah d
iubah melalui penerbitan amandemen, corrigenda, atau errata, kunjungi situs Web
IEEE Standards Association di http://ieeexplore.ieee.org/xpl/standards.jsp, atau
hubungi IEEE di alamat yang tercantum sebelumnya.
Untuk informasi lebih lanjut tentang IEEE Standards Association atau proses peng
embangan standar IEEE, kunjungi situs Web IEEE-SA di http://standards.ieee.org.
v
Errata
Errata, jika ada, untuk dan semua standar lain ini dapat diakses di URL berikut:
http://standards.ieee.org/reading/ieee/updates/errata/index.html. Para pengguna
didorong untuk memeriksa URL ini untuk errata secara berkala.
Penafsiran
interpretasi saat ini dapat diakses di URL berikut: http://standards.ieee.org/re
ading/ieee/interp/ index.html.
Perhatian adalah dipanggil untuk paten kemungkinan bahwa implementasi standar in
i mungkin memerlukan penggunaan subyek dilindungi oleh hak-hak paten. Oleh pener
bitan standar ini, posisi tidak diambil dengan rasa hormat kepada keberadaan ata
u kesahihan hak-hak paten apa pun dalam mengurus koneksi. Dalam IEEE tidak berta
nggung jawab untuk mengidentifikasi Klaim Patent untuk yang penting lisensi yang
mungkin diperlukan, untuk melakukan pertanyaan mengenai keabsahan hukum atau li
ngkup klaim hak paten atau menentukan apakah ada ketentuan lisensi atau koneksi
yang disediakan dalam dengan kondisi pengiriman surat jaminan, jika ada, atau da
lam perjanjian lisensi apa pun yang masuk akal atau non-diskriminatif. Pengguna
standar ini secara tersurat menyarankan bahwa penentuan kesahihan hak-hak paten
apa pun, dan risiko pelanggaran hak tersebut, adalah sepenuhnya tanggungjawab me
reka sendiri. Informasi lebih lanjut dapat diperoleh dari IEEE Standards Associa
tion.
Peserta
pada waktu standar ini telah disampaikan kepada IEEE-SA Standards Board untuk di
setujui, Kelompok Kerja Kajian Perangkat Lunak telah keanggotaan berikut:

J. Dennis Lawrence, Kursi
Edward Addy Edward Dudash T. Scott Ankrun Andrew Fieldsend Jamey Sanders Chris B
agge Gregg Giesler Helmut H. Sandmayr William Bartolomeus Pirooz Joodi Robert Sc
haaf Daud mayor Bowen George Kyle Hans Schaefer Massimo Cardaci Daud J. Leciston
Luca Spotorno Norbert Carte Carol A. Thomas Starai Michael Chonoles Panjang Mic
hael McCaffrey K. S. Subrahmanyam Terry Dietz Miroslav Wolf Pavlovic Douglas Thi
ele Antonio Doria Yohanes Thuywissen
vi
Anggota berikut individu komite pemungutan suara mencoblos pada standar ini. Bal
loters mungkin telah mengundi untuk disetujui, penolakan, atau pantang.
Butch Anton M. Hashmi William Petit Chris Bagge Rutger A. Heunks Ulrich Pohl Pie
ter Botman Richard Hilliard Annette Reilly Daniel Brosnan Werner Hoelzl Michael
Roberts Juan Carreon Robert Holibaugh Robert Robinson Norbert Carte Petrus Hung
Terence Serakkanlah Lawrence Catchpole Mark Jaeger Randall Safier Danila Chernet
sov St. Clair James Jamey Sanders Keith Chow Michael C. Jett Helmut H. Sandmayr
Raul Colcher James Jones Robert Schaaf Paulus Croll Piotr Karocki Hans Schaefer
Geoffrey Darnton Mark Knight Daud Semula Teresa Doran J. Thomas Kurihara Jungwoo
Antonio Doria Bilateral George Kyle Carl Penyanyi Scott Mukasurat Duncan Marc L
acroix Luca Spotorno Kenneth D. Echeberry Claude Y. Laporte Thomas Starai Kamesh
war Eranki J. Dennis Lawrence Walter Struppler Kehidupan Carla Ewart Daud J. Lec
iston Marcy Stutzman Harriet Feldman Yury Makedonov K. S. Subrahmanyam Andrew Fi
eldsend Edward McCall Douglas Thiele Andre Fournier James Moore Yohanes Thywisse
n Daud Friscia Ronald G. Murias Thomas Tullia Yohanes Geldman Rajesh Murthy Vinc
ent J. Tume Gregg Giesler Michael S. Newman Charlene Walrad Lewis Tanda Abu-abu
Paulk Mukasurat Wolfgang Michael Grimley Miroslav Wolf Pavlovic Oren Yuen Yohane
s Harauz Janusz Zalewski
kondisi terakhir untuk memperoleh persetujuan dari standar ini telah bertemu pad
a 16 Juni 2008. Standar ini telah disetujui secara kondisional oleh IEEE-SA Stan
dards Board pada 12 Juni 2008, dengan keanggotaan berikut:
Robert M. tumbuh, Kursi Thomas Prevost, Wakil Ketua Steve M., Masa Lalu Kursi Pa
brik Judith Gorman, Sekretaris
Victor Berman Jim Hughes Ron Jacob Petersen Richard DeBlasio Richard Hulett Chuc
k Kekuatan-kekuatan Andy Drozd Kyun Muda Kim Narayanan Ramachandran Mark Epstein
Yusuf L. Koepfinger Jon Walter Rosdahl Alexander Gelman Yohanes Kulick Anne-Mari
e Sahazizian William Goldbach Daud J. Hukum Thaden Arnie Malcolm Greenspan Glenn
Pendeta Howard angan menjadi manusia serigala Ken Hanus Don Wright
Anggota Emeritus
juga termasuk adalah nonvoting berikut IEEE-SA Standards Board liaisons:
Satish K. Aggarwal, Perwakilan Sesuai anjuran NRC Michael H. Kelley, Perwakilan
NIST
Lisa Perry Standar IEEE Editor Proyek
Malia Zaman Standar IEEE, Manajer Program Program Teknis Development

vii
Isi
1. .............................................................................
....................................................................... ringkasa
n 1
2. Rujukan-rujukan normatif.....................................................
............................................................................. 5
1.1 Cakupan ....................................................................
...............................................................................
1
1,2 Tujuan .....................................................................
........................................................................... 2
1,3 Hubungan dengan IEEE Std 12207-2008.........................................
.................................................... 2
1,4 Conformance ................................................................
....................................................................... 2
1,5 Organisasi..................................................................
............................................. standar ini 3
1,6 Aplikasi standar ini........................................................
......................................................... 3
3. Definisi-definisi............................................................
................................................................................
...... 5
4. Tinjauan Manajemen...........................................................
....................................................................... 6
4.1 Pendahuluan untuk tinjauan manajemen........................................
........................................................... 6
5. Ulasan.......................................................................
.............................................................. Teknis 11
4.2 Tanggung Jawab..............................................................
...................................................................... 7
4.3.............................................................................
........................................................................ Input 9
4.4 Entri kriteria..............................................................
.......................................................................... 9
4.5 Prosedur ...................................................................
........................................................................ 9
4.6 Keluar .....................................................................
................................................................... kriteria 11
4.7.............................................................................
................................................................... Output 11
5.1 Pengenalan Teknik ulasan....................................................
................................................... 11
6. Penggeledahan................................................................
................................................................................
16
5.2 Tanggung Jawab..............................................................
.................................................................... 12
5.3.............................................................................
...................................................................... Input 13
5.4 Entri kriteria..............................................................
........................................................................ 13
5.5 ............................................................................
............................................................. Prosedur 14
5.6 Keluar .....................................................................
................................................................... kriteria 16
5.7.............................................................................
................................................................... Output 16
6.1 pemeriksaan pendahuluan untuk ..............................................
.................................................................. 16
7. Berjalan-terusan.............................................................
............................................................................. 25
6.2 Tanggung Jawab..............................................................
.................................................................... 17
6.3.............................................................................
...................................................................... Input 18
6.4 Entri kriteria..............................................................
........................................................................ 19
6.5 ............................................................................
............................................................. Prosedur 20
6.6 Keluar .....................................................................
................................................................... kriteria 23
6.7.............................................................................
................................................................... Output 23
6.8 Pengumpulan Data............................................................
....................................................................... 23
6,9 Perbaikan...................................................................
................................................................... 25
7.1 Pendahuluan untuk berjalan-terusan .........................................
.................................................................. 25 7.2 Tanggu
ng Jawab........................................................................
.......................................................... 26 7.3...............
................................................................................
.................................................... Input 26
viii
7,4 Entri kriteria..............................................................

........................................................................ 27
8. .............................................................................
......................................... Audit
7,5 Prosedur ...................................................................
...................................................................... 27
7.6 Keluar .....................................................................
................................................................... kriteria 29
7.7.............................................................................
................................................................... Output 29
7,8 rekomendasi.................................................................
..................................... Pengumpulan Data 29
7,9 Perbaikan...................................................................
................................................................... 30
................................. 30
8.1 Pendahuluan untuk melaksanakan audit........................................
................................................................................
. 30
Annex A (informatif) Perbandingan Tipe peninjauan ..............................
..................................................... 38
8.2 Tanggung Jawab..............................................................
.................................................................... 31
8.3.............................................................................
...................................................................... Input 33
8.4 Entri kriteria..............................................................
........................................................................ 33
8.5 ............................................................................
............................................................. Prosedur 34
8,6 Keluar .....................................................................
................................................................... kriteria 36
8.7.............................................................................
................................................................... Output 37
Lampiran B (informatif) Bibliografi.............................................
............................................................... 40
ix

Standard IEEE untuk Tinjauan Perangkat Lunak Audit dan

pemberitahuan penting: standar ini tidak dimaksudkan untuk memastikan keselamata
n, kesehatan, keamanan, atau perlindungan lingkungan dalam semua keadaan. Dinas
dari standar tersebut bertanggung jawab untuk menentukan keselamatan yang sesuai
, keamanan, lingkungan, dan praktik-praktik kesehatan atau persyaratan peraturan
.
Dokumen ini dibuat IEEE ini tersedia untuk menggunakan perihal untuk pemberitahu
an penting dan Sanggahan legal. Pemberitahuan ini dan sanggahan muncul dalam sem
ua publications berisi dokumen ini dan dapat ditemukan di bawah judul "Pemberita
huan Penting" atau "Pemberitahuan penting dan sanggahan Tentang Dokumen IEEE." M
ereka juga dapat diperoleh pada permintaan dari IEEE atau dilihat di http://stan
dards.ieee.org/IPR/disclaimers.html.
1. Tinjauan umum
1.1 Cakupan
standar ini menyediakan persyaratan yang dapat diterima minimum untuk perangkat
lunak sistematis ulasan, di mana "sistematis" mencakup atribut berikut:
partisipasi Tim
Didokumentasikan hasil kajian
Didokumentasikan prosedur untuk me
lakukan kajian
ulasan yang tidak memenuhi standar ini dianggap sebagai non-ulasan sistematis.
Standar tersebut tidak dimaksudkan untuk melemahkan atau melarang penggunaan non
-ulasan sistematis.
Definisi-definisi, persyaratan, dan prosedur untuk lima jenis ulasan berikut tel
ah disertakan dalam standar ini:
sebuah) Tinjauan Manajemen b) ulasan Teknis c) Inspeksi d) berjalan-terusan e Au
dit)
1
IEEE Std 1028-2008 Standard IEEE untuk audit kajian, dan perangkat lunak
ini tidak membentuk standar ini kebutuhan untuk melakukan kajian tertentu; yang
memerlukan didefinisikan oleh perangkat lunak lain standar teknik atau oleh pros
edur lokal. Standar ini menyediakan, persyaratan, dan definisi prosedur yang ber
laku untuk produk-produk pengembangan perangkat lunak peninjauan terhadap sepanj
ang siklus hidup perangkat lunak. Pengguna standar ini akan menetapkan tempat da
n ketika standar ini berlaku dan ditujukan penyimpangan dari standar ini.
Standar ini dapat digunakan dengan perangkat lunak lain standar teknik yang mene
ntukan produk-produk yang akan diulas dalam tulisan, pewaktuan ulasan, dan keper
luan ulasan. Standar ini sejajar erat dengan IEEE Std 1012TM-2004 [B6], tetapi j
uga dapat digunakan dengan IEEE Std 1074TM-2006 [B11], IEEE Std sebesar 730TM 20
02
1 [B2], IEEE Std 12207TM-2008 [B15], dan standar-standar lainnya. Model yang ber
manfaat untuk mempertimbangkan IEEE Std 1028-2008 sebagai subroutine ke standar
lainnya. Oleh itu, jika IEEE Std 1012-2004 [B6] telah digunakan untuk melakukan
verifikasi dan proses validasi, prosedur dalam IEEE Std 1012-2004 [B6] dapat men
gikuti hingga waktu seperti itu sebagai instruksi untuk melaksanakan ditemukan p
eninjauan tertentu. Pada saat itu, IEEE Std 1028-2008 akan "disebut" untuk melak
sanakan kajian, menggunakan jenis peninjauan tertentu yang dijelaskan di sini. S
etelah kaji ulang telah selesai, IEEE Std 1012-2004 [B6] akan "kembali ke" untuk
perangai dari hasil kajian dan tindakan tambahan diperlukan oleh IEEE Std 10122004 [B6].
Standar ini juga dapat digunakan sebagai berdiri sendiri perangkat lunak definis
i meninjau dan prosedur audit. Dalam hal ini, manajemen lokal harus menentukan p
eristiwa-peristiwa yang mendahului dan ikuti perangkat lunak aktual berisi tinja
uan dan proses audit.
Dalam model ini, persyaratan kualitas dan atribut untuk produk perangkat lunak a
dalah "masukan parameter" untuk meninjau dan yang dikenakan oleh "penelepon." Sa
at meninjau selesai, kajian output di "kembali" ke "" untuk bertindak penelepon.
Output peninjauan biasanya termasuk daftar anomali dan daftar item tindakan; pe
nyelesaian kelainan bawaan dan item tindakan adalah tanggungjawab "penelepon."
1,2 Tujuan
Tujuan standar ini adalah untuk menentukan ulasan sistematis audit dan yang berl
aku untuk perangkat lunak akuisisi, operasi, pengembangan, pasokan, dan perawata
n. Standar ini menerangkan cara melakukan kajian. Standar lain atau manajemen lo
kal menentukan konteks di mana suatu tinjauan dilakukan, dan penggunaan yang ter
buat dari hasil-hasil kaji ulang. Ulasan perangkat lunak dapat digunakan untuk m
endukung tujuan-tujuan manajemen proyek, Rekayasa Sistem (misalnya, alokasi fung
sional antara perangkat lunak dan perangkat keras), verifikasi dan validasi, man
ajemen konfigurasi, jaminan kualitas, dan audit. Berbagai jenis ulasan mencermin
kan perbedaan dalam tujuan dari setiap jenis peninjauan. Ulasan sistematis digam
barkan oleh prosedur yang ditentukan mereka, cakupan, dan tujuan.
1,3 Hubungan dengan IEEE Std 12207-2008
standar ini dapat digunakan untuk mencapai hasil-hasil 7.2.6 (Proses Kaji Ulang
Perangkat Lunak) dan 7.2.7 (Proses Audit Perangkat Lunak) IEEE Std 12207-2008 [B
15].
1,4 Conformance
Conformance untuk standar ini untuk jenis peninjauan tertentu dapat diklaim bila
semua tindakan wajib (ditandai dengan "akan") dilakukan yang didefinisikan dala
m standar ini untuk meninjau ketikkan digunakan. Klaim untuk conformance harus p
hrased untuk menunjukkan jenis peninjauan digunakan, misalnya, "menyesuaikan dir
i untuk IEEE Std 1028-2008 untuk inspeksi." Kata "akan" digunakan untuk express
persyaratan, "harus," untuk express saran, dan "mungkin," untuk express atau alt
ernatif metode opsional memuaskan tuntutan.
1 angka-angka dalam tanda kurung setara dengan orang-orang dari bibliografi dala
m Lampiran B.
2
IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak Audit dan
Organisasi 1.5 standar ini
FROM clause 4 untuk FROM clause 8 standar ini menyediakan bimbingan dan keterang
an untuk lima jenis ulasan sistematis ditujukan oleh standar ini. Masing-masing
klausula yang berisi informasi berikut:
sebuah) Pengantar untuk meninjau. Menerangkan tujuan-tujuan peninjauan sistemati
s dan memberikan ringkasan prosedur peninjauan sistematis.
b) Tanggung Jawab. Menentukan peran dan tanggung jawab yang diperlukan untuk pen
injauan sistematik.
c) Input. Menerangkan persyaratan yang dibutuhkan oleh input peninjauan sistemat
is.
d) Entri kriteria. Menerangkan kriteria untuk dapat dipenuhi sebelum memulai, pe
ninjauan sistematis termasuk yang berikut:
1) 2) acara Pemrakarsa Otorisasi
e Prosedur). Rincian prosedur untuk peninjauan sistematis, termasuk yang berikut
:
1) merencanakan meninjau 2) Tinjauan umum tentang prosedur 3) Persiapan Pemeriks
aan 4)/evaluasi hasil rekaman/5) Pengaplingan/tindak lanjut
f) Keluar kriteria. Menerangkan kriteria untuk dapat dipenuhi sebelum peninjauan
sistematik dapat dianggap sebagai selesai.
g) Output. Menerangkan hasil set minimum yang dihasilkan oleh peninjauan sistema
tis.
1,6 Aplikasi standar ini
prosedur dan terminologi yang didefinisikan dalam standar ini berlaku untuk akui
sisi perangkat lunak, operasi, pengembangan, pasokan, dan proses pemeliharaan ya
ng memerlukan kajian sistematis. Ulasan sistematis dilakukan pada produk perangk
at lunak yang diperlukan oleh standar lain atau prosedur lokal.
Istilah "produk perangkat lunak" digunakan dalam standar ini dalam pengertian ya
ng sangat luas. Contoh-contoh produk perangkat lunak termasuk, tetapi tidak terb
atas pada, berikut:
laporan Laporan Audit Anomali rencana pencadangan dan pemulihan Membangun Rencan
a prosedur Kontngensi Kontrak Pelanggan atau keluhan perwakilan pengguna rencana
Bencana rencana performa perangkat keras laporan Inspeksi
3
IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak dan
rencana Instalasi Audit prosedur instalasi manual Pemeliharaan Rencana Pemelihar
aan Laporan Manajemen Operasi dan panduan pengguna Pengadaan dan penularan metod
e laporan perkembangan Catatan Rilis Laporan dan data (misalnya, tinjau audit, s
tatus proyek, anomali, laporan, data-data pengujian) Permintaan untuk rencana ma
najemen risiko proposal rencana jaminan kualitas Perangkat Lunak (lihat IEEE Std
sebesar 730TM 2002 [B2]) konfigurasi perangkat lunak rencana manajemen (lihat I
EEE Std 828TM-2005 [B3]) dokumentasi Uji Software (lihat IEEE Std 829TM-2008 [B4
]) persyaratan perangkat lunak (lihat spesifikasi IEEE Std 830TM 1998 [B5]) veri
fikasi perangkat lunak dan rencana validasi (lihat IEEE Std 1012TM-2004 [B6]) ke
terangan desain Perangkat Lunak (lihat IEEE Std 1016TM 1998 [B7]) rencana manaje
men proyek perangkat lunak (lihat IEEE Std 1058TM 1998 [B9]) dokumentasi penggun
a perangkat lunak (lihat IEEE Std 1063TM-2001 [B10]) Perangkat Lunak rencana kes
elamatan (lihat IEEE Std 1228TM-1994 [B13.]) keterangan arsitektur perangkat lun
ak (lihat IEEE Std 1471TM 2000 [B14]) kode sumber Spesifikasi Standar , peraturan
, panduan, dan Sistem prosedur membangun laporan Kaji Ulang Teknis prosedur doku
men Vendor Berjalan-melalui
ijin standar ini berisi tinjauan tentang laporan yang akan diselenggarakan oleh
berarti selain pertemuan secara fisik di satu lokasi.
Contoh-contoh tersebut meliputi telepon konferensi, konferensi video, konferensi
Web Internet dan sarana lain untuk komunikasi elektronik grup. Pada kasus seper
ti ini, berarti harus komunikasi yang didefinisikan sebagai tambahan ke tempat-t
empat pertemuan, dan semua persyaratan peninjauan lain tetap berlaku.
Untuk menggunakan standar ini untuk melakukan kaji ulang perangkat lunak, memutu
skan tujuan pertama kaji ulang.
Selanjutnya, pilih jenis peninjauan yang sesuai. Kemudian ikuti prosedur yang di
jelaskan dalam klausa yang sesuai (Pasal 4 melalui FROM clause 8) dari standar i
ni.
4.
Hak cipta 2008 IEEE. Semua hak dilindungi undang-undang.
IEEE Std 1028-2008 Standard IEEE untuk Tinjauan perangkat lunak dan
layanan, BIAYA MODAL, jika peristiwa-peristiwa atau audit menimbulkan masalah me
ninjau gagal atau menghentikan, proses kajian harus melaporkan hasil ini ke pros
es menyeru. Proses pelaporan ini harus konsisten dengan proses lain masalah stan
dar pelaporan digunakan oleh organisasi, yang tidak dalam lingkup standar proses
kajian ini.
2. Rujukan-rujukan normatif
dokumen yang direferensikan berikut adalah mustahak untuk aplikasi dari dokumen
ini. Untuk referensi bertanggal, hanya edition dikutip berlaku. Untuk tidak bert
anggal direferensikan, edisi terbaru dari dokumen yang direferensikan (termasuk
semua perubahan atau corrigenda) berlaku.
3 2, IEEE Std 610.12TM 1990, Standard IEEE Khasanah Terminologi Teknik Perangkat
Lunak.
Catatan-standar tambahan yang dapat digunakan untuk menyediakan produk perangkat
lunak yang subjek audit ulasan atau
4 disebutkan dalam bibliografi dalam Lampiran B.
3. Definisi
untuk tujuan-tujuan standar ini, ketentuan dan definisi berikut berlaku. IEEE St
d 610.12-1990 dan Kamus Pembimbing Standar IEEE Istilah [B1] harus dilibatkan un
tuk tidak didefinisikan dalam Ketentuan
5 ini FROM clause.
Catatan 1- Enam istilah-istilah diberikan di sini didefinisikan dalam perangkat
lunak IEEE standar teknik lainnya. Definisi dari istilah "anomali" adalah sama d
engan yang diberikan dalam IEEE Std 1044TM tahun 1993 [B8]. Istilah-istilah "men
gaudit," "pemeriksaan," "meninjau," "produk perangkat lunak," dan "berjalan-mela
lui" di semua didefinisikan dalam IEEE Std 610.12-1990; walau demikian, beberapa
perubahan kecil telah dibuat untuk orang-orang untuk lebih dekat cocok dengan d
efinisi konten dari standar ini, seperti yang dijelaskan dalam berhasil paragraf
.
Catatan 2- IEEE Std 610.12-1990 menggunakan istilah-istilah yang berbeda untuk t
ujuan ulasan: dan ulasan didefinisikan audit di dalamnya dalam istilah "produk k
erja," yang didefinisikan dalam istilah inspeksi "produk pembangunan," dan berja
lan-terusan didefinisikan dalam istilah "dokumentasi segmen atau daftar." "produ
k Kerja" tidak didefinisikan dalam IEEE Std 610.12-1990.
Sejak "produk perangkat lunak" didefinisikan di dalamnya, dan ia yang diinginkan
untuk menggunakan satu istilah ini dalam standar ini, sebuah perubahan dalam te
rminologi dibuat. Sejak produk perangkat lunak dikaji ulang tidak terbatas pada
mereka "yang ditetapkan untuk pengiriman ke pengguna," yang frasa drop dari defi
nisi "produk perangkat lunak." definisi "" telah inspeksi berubah sama sekali.
Anomali: kondisi apapun 3.1 yang menyimpang dari ekspektasi berdasarkan spesifik
asi persyaratan, dokumen desain, dokumen pengguna, dsb., standar, atau dari peng
alaman persepsi atau seseorang.
Catatan-dapat ditemukan selama Kelainan, namun tidak terbatas pada, tinjau, tes,
analisis, kompilasi, atau menggunakan produk perangkat lunak atau dokumentasi y
ang berlaku.
3.2: Sebuah pemeriksaan independen audit dari sebuah produk perangkat lunak, pro
ses perangkat lunak, atau menyetel proses perangkat lunak yang dilakukan oleh pi
hak ketiga untuk menilai sesuai dengan spesifikasi standar, perjanjian kontrak,,
atau kriteria lainnya.
Catatan-audit hasil harus dalam petunjuk yang jelas tentang apakah kriteria audi
t telah terpenuhi.
2 IEEE publikasi ini tersedia dari Institute of Electrical and Electronics Engin
eers, 445 Cangkul Lane, Piscataway, 08854, Amerika Serikat (kereta NJ http://sta
ndards.ieee.org/).
3 standar IEEE produk atau dirujuk dalam klausa ini adalah merek dagang dari Ins
titute of Electrical and Electronics Engineers, Inc.
4 Catatan dalam teks, tabel, dan tokoh-tokoh standar yang diberikan untuk hanya
informasi dan tidak berisi yang dibutuhkan untuk menerapkan standar ini.
5 Informasi tentang rujukan dapat ditemukan dalam FROM clause 2.
5.
3.3 Inspeksi: pemeriksaan visual dari sebuah produk perangkat lunak untuk mendet
eksi dan mengenali kelainan perangkat lunak, termasuk kesalahan dan penyimpangan
dari spesifikasi dan standar.
Catatan-Inspeksi adalah ujian peer dipimpin oleh fasilitator imparsial yang terl
atih dalam teknik inspeksi.
Penentuan atau perbaikan tindakan investigasi untuk suatu anomali adalah elemen
wajib sebuah inspeksi perangkat lunak, meskipun solusi tidak boleh ditentukan da
lam pertemuan inspeksi.
Review Manajemen 3.4: secara sistematis evaluasi produk perangkat lunak atau dil
akukan oleh proses atau atas nama management yang memantau kemajuan, menentukan
status rencana dan persyaratan, mengesahkan jadwal dan alokasi sistem mereka, at
au mengevaluasi efektivitas pendekatan manajemen digunakan untuk mencapai kesesu
aian untuk tujuan tertentu.
3.5 meninjau: sebuah proses atau selama yang rapat produk perangkat lunak, setel
dari produk perangkat lunak, atau sebuah proses perangkat lunak dipersembahkan
kepada personel proyek, manajer, pengguna, pelanggan, perwakilan pengguna, atau
auditor pihak-pihak lain yang tertarik untuk diperiksa, komentar atau disetujui.
Produk perangkat lunak 3.6: (A) set lengkap dari program komputer, prosedur, dan
dokumentasi terkait dan data. (B) satu atau beberapa item individual dalam (A).
3.7: secara sistematis peninjauan teknis evaluasi produk perangkat lunak oleh ti
m teknisi ahli yang mengkaji kesesuaian produk perangkat lunak yang ditujukan un
tuk menggunakan dan mengidentifikasi kesenjangan dari standar dan spesifikasi.
Catatan-ulasan Teknis mungkin juga memberikan rekomendasi alternatif dan pemerik
saan berbagai alternatif.
3.8 berjalan-melalui: Sebuah analisis statis teknik yang seorang perancang atau
programmer membawa anggota tim pengembangan dan pihak-pihak lain yang tertarik m
elalui sebuah produk perangkat lunak, dan para peserta mengajukan pertanyaan-per
tanyaan dan membuat komentar tentang kemungkinan kelainan pelanggaran terhadap s
tandar pengembangan, dan masalah-masalah lain.
4. Tinjauan Manajemen
4.1 Pendahuluan untuk tinjauan manajemen
tujuan manajemen adalah untuk memantau kemajuan, menentukan status jadwal dan re
ncana, atau mengevaluasi efektivitas pendekatan manajemen digunakan untuk mencap
ai kesesuaian untuk tujuan tertentu. Tinjauan Manajemen mendukung keputusan-kepu
tusan tentang tindakan korektif, perubahan dalam alokasi sumber daya, atau perub
ahan pada cakupan proyek.
Tinjauan Manajemen mengenali konsistensi dengan dan penyimpangan dari rencana, a
tau adequacies dan kekurangan-kekurangan prosedur manajemen. Pengetahuan Teknis
mungkin perlu melakukan review manajemen yang sukses. Pemeriksaan mungkin memerl
ukan lebih dari satu pertemuan. Pemeriksaan memerlukan alamat tidak semua aspekaspek produk perangkat lunak atau proses.
Contoh-contoh produk perangkat lunak dikaji oleh manajemen termasuk, tetapi tida
k terbatas pada, berikut:
laporan Laporan Audit
Anomali
rencana pencadangan dan pemulihan
rencana Spesifik
asi Kontngensi
6
Pelanggan
Audit atau keluhan perwakilan pengguna rencana Bencana performa perang
kat keras
rencana rencana Instalasi
Rencana Pemeliharaan Pengadaan dan penularan
Laporan Kemajuan
metode manajemen risiko
rencana rencana pengelolaan konfiguras
i perangkat lunak perangkat lunak rencana manajemen proyek rencana jaminan kuali
tas Perangkat Lunak Perangkat Lunak
rencana keselamatan
verifikasi perangkat lun
ak dan rencana validasi laporan Kaji Ulang Teknis
analisis produk perangkat luna
k verifikasi dan laporan validasi
strategi migrasi dan rencana hasil tes
proses
pengembangan perangkat lunak keterangan
keterangan arsitektur perangkat lunak
contoh-contoh proses perangkat lunak (lihat IEEE Std 12207-2008 [B15]) dikaji ol
eh manajemen termasuk, tetapi tidak terbatas pada, berikut:
dan Akuisisi Proses Pengembangan
pasokan operasi, pemeliharaan dan Dokumentasi
p
roses proses konfigurasi proses manajemen
proses verifikasi
jaminan kualitas, va
lidasi, tinjauan bersama, dan proses audit Proses Penyelesaian Masalah Manajemen
, perbaikan, dan proses infrastruktur

proses Pelatihan
4.2 Tanggung Jawab
ulasan Manajemen dilakukan oleh, atau atas nama, manajemen memiliki tanggung jaw
ab untuk personel sistem. Tinjauan Manajemen akan dilakukan oleh personel yang t
ersedia yang paling layak untuk mengevaluasi proses atau produk perangkat lunak.
7.
peran berikut akan kokoh untuk manajemen:
sebuah) pembuat keputusan b) pemimpin peninjauan c) d) staf Manajemen Perekam e)
Staf Teknis
peran berikut mungkin juga akan didirikan untuk manajemen:
f) anggota tim lainnya g) perwakilan Pelanggan h) perwakilan Pengguna
seseorang mungkin menduduki lebih dari satu peran tetapi tidak pernah semua mere
ka. Peran dapat dilayani oleh lebih dari satu individu.
4.2.1 pembuat keputusan
kepada para pembuat keputusan adalah orang-manajemen dilaksanakan. Pembuat keput
usan akan menentukan apakah tujuan peninjauan telah terpenuhi.
4.2.2 pemimpin peninjauan
pemimpin peninjauan akan memastikan bahwa tugas-tugas administratif yang terkait
dengan pengujian sudah selesai, akan bertanggung jawab untuk perencanaan dan pe
rsediaan seperti yang dijelaskan dalam 4.5.2 dan 4.5.4, akan memastikan bahwa ka
jian tersebut adalah dilakukan dengan tertib dan memenuhi tujuan-, dan akan meng
eluarkan output peninjauan seperti yang dijelaskan dalam 4.7.
Perekam 4.2.3
perekam yang akan kelainan dokumen, item tindakan, keputusan-keputusan, dan reko
mendasi yang dibuat oleh tim kaji ulang.
4.2.4 staf Manajemen
staf Manajemen ditetapkan untuk melaksanakan Tinjauan Manajemen akan berpartisip
asi aktif dalam meninjau.
Bertanggung jawab untuk sistem yang manajer sebagai seluruh mungkin memiliki tan
ggung jawab tambahan yang didefinisikan dalam 4.5.1.
4.2.5 Staf Teknis
staf teknis akan menyediakan informasi yang diperlukan untuk staf manajemen untu
k memenuhi tanggung jawabnya.
Pelanggan 4.2.6 atau perwakilan pengguna
peran pelanggan atau perwakilan pengguna harus ditentukan oleh pemimpin peninjau
an sebelum kaji ulang.
8.
IEEE Std 1028-2008 Standard IEEE untuk Audit Kaji Ulang dan perangkat lunak
4.3
Input Input ke manajemen akan meliputi yang berikut:
sebuah) sebagai pernyataan sasaran manajemen b) produk perangkat lunak atau pros
es ini telah dievaluasi c) rencana manajemen proyek perangkat lunak d), Status r
elatif terhadap rencana-produk perangkat lunak, atau menyelesaikan proses atau s
edang berlangsung e) kelainan saat ini atau daftar masalah f) Didokumentasikan p

rosedur peninjauan g) Daftar aksi dari kajian sebelumnya pada produk perangkat l
unak yang sama atau, jika ada proses
ke Input manajemen juga harus mencakup hal berikut ini:
h) Status, termasuk keuangan, sumber daya yang sesuai saya) Kategori Anomali (li
hat IEEE Std 1044-1993 [B8]) j) laporan penilaian risiko
bahan referensi tambahan mungkin Disediakan oleh orang-orang yang bertanggung ja
wab untuk produk perangkat lunak atau bila diminta oleh proses pemimpin peninjau
an.
4.4 Entri kriteria
Otorisasi 4.4.1
kebutuhan untuk melakukan tinjauan manajemen pada awalnya didirikan dalam dokume
n perencanaan proyek yang sesuai, seperti tercantum dalam 4.1. Di bawah rencana
ini, penyelesaian produk perangkat lunak tertentu, proses, atau mungkin mempraka
rsai sebuah aktivitas proses manajemen. Selain untuk orang-orang yang diperlukan
oleh kajian manajemen rencana tertentu, manajemen lain ulasan dapat diumumkan d
an diselenggarakan pada permintaan dari manajemen kualitas perangkat lunak, mana
jemen fungsional, manajemen proyek, atau pelanggan atau perwakilan pengguna, men
urut prosedur lokal.
4.4.2 Prasyarat
review manajemen yang akan dilakukan hanya bila kedua dari kondisi berikut telah
dipenuhi:
sebuah) sebuah pernyataan tujuan untuk meninjau akan dibentuk oleh personel mana
jemen bagi mereka telah meninjau sedang dilakukan.
b) masukan peninjauan yang diperlukan tersedia dengan jangka waktu pemberitahuan
yang diperlukan untuk mengaktifkan semua peserta untuk menjadi benar-benar meny
adarinya.
4.5 Prosedur
Manajemen 4.5.1
Manajer persiapan akan memastikan bahwa kaji ulang ini dilakukan sebagai diperlu
kan oleh standar yang berlaku dan prosedur dan persyaratan oleh diamanatkan oleh
hukum, kontrak, atau kebijakan lainnya. Untuk akhir ini, manajer akan melakukan
yang berikut:
9
sebuah) waktu Rencana Audit dan sumber daya yang diperlukan untuk ulasan, termas
uk fungsi dukungan, seperti yang diperlukan dalam IEEE Std 1058-1998 [B9] atau s
tandar lainnya yang
b) Menyediakan dana dan fasilitas yang diperlukan untuk merencanakan, mendefinis
ikan, menjalankan, dan mengelola ulasan c) menyediakan pelatihan dan orientasi p
ada prosedur peninjauan berlaku untuk proyek d) memastikan tingkat yang sesuai k
eahlian dan pengetahuan yang cukup untuk memahami produk perangkat lunak atau di
bawah review proses
e) memastikan bahwa rencana ulasan yang dilakukan f) UU rekomendasi tim kaji ula
ng secara tepat waktu
4.5.2 merencanakan meninjau
pemimpin peninjauan akan bertanggung jawab untuk kegiatan berikut:
sebuah) mengidentifikasi, dengan dukungan manajemen yang sesuai, tim kaji ulang
b) Khusus Menetapkan Tanggung jawab anggota tim kaji ulang c) menjadwalkan perte
muan dan mengumumkan d) mendistribusikan materi peninjauan untuk peserta, sehing
ga cukup waktu untuk persiapan mereka e) Setel sebuah jadwal untuk distribusi ma
teri peninjauan, kembali komentar-komentar, dan penerusan komentar kepada penuli
s untuk perangai
4.5.3 Ringkasan Prosedur peninjauan
orang yang berpengalaman harus ada ringkasan sesi bagi tim kaji ulang saat dimin
ta oleh pemimpin peninjauan. Ringkasan ini mungkin terjadi sebagai bagian dari r
eview meeting (lihat 4.5.5) atau sebagai pertemuan terpisah.
4.5.4
setiap anggota tim kaji ulang Persiapan akan memeriksa produk perangkat lunak at
au masukan peninjauan lain dan proses sebelum pertemuan kaji ulang. Kelainan baw
aan terdeteksi selama pemeriksaan ini harus mendokumentasikan dan dikirim ke pem
impin peninjauan. Pemimpin peninjauan harus memastikan bahwa kelainan bawaan ini
diklasifikasikan sehingga waktu rapat reviu digunakan paling efektif. Pemimpin
peninjauan harus meneruskan kelainan bawaan untuk penulis dari produk perangkat
lunak atau pemilik proses perangkat lunak untuk disposisi.
Pemeriksaan 4.5.5
review manajemen yang terdiri dari satu atau beberapa pertemuan-pertemuan tim ka
ji ulang. Pertemuan-pertemuan tersebut akan mencapai tujuan-tujuan berikut:
sebuah) Meninjau tujuan-tujuan manajemen b) mengevaluasi produk perangkat lunak
atau di bawah meninjau terhadap proses tujuan peninjauan c) Mengevaluasi status
proyek, termasuk status jadwal dan d) rencana kelainan peninjauan dikenalpasti o
leh tim kaji ulang sebelum meninjau e) Membuat daftar item tindakan, menekankan
risiko f) Dokumen pertemuan
10
IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak Audit dan pertem
uan
-pertemuan tersebut harus mencapai tujuan-tujuan berikut yang sesuai:
g) Mengevaluasi dan mengelola risiko masalah yang mungkin membahayakan keberhasi
lan proyek h) alokasi sumber daya perubahan dan pengalihan proyek dan replanning
saya) Konfirmasi persyaratan perangkat lunak dan alokasi sistem mereka j) menen
tukan arah tindakan yang akan diambil atau rekomendasi tindakan untuk mengenali
masalah lain k) yang harus ditangani
Pemandangannya 4.5.6/tindak lanjut
pemimpin peninjauan akan memverifikasi bahwa tindakan yang ditetapkan dalam pert
emuan item telah ditutup.
4.6 Keluar
review manajemen-kriteria akan dianggap lengkap saat kegiatan yang tercantum dal
am 4.5.5 telah digenapi dan output yang dijelaskan dalam 4.7 ada.
4.7 Output
output dari manajemen akan menjadi bukti yang mengidentifikasi didokumentasikan
berikut:
sebuah) produk atau proses ini telah dikaji b) tim kaji ulang anggota c) tujuan
peninjauan d) masukan tertentu untuk meninjau e) status item Tindakan (buka, dit
utup), kepemilikan dan tanggal target (jika terbuka), atau tanggal penyelesaian
(jika ditutup)
f) daftar kelainan bawaan yang diidentifikasi oleh tim kaji ulang yang akan ditu
jukan untuk proyek untuk memenuhi tujuan-tujuannya
Walaupun Standar ini mengatur persyaratan minimum untuk isi didokumentasikan buk
ti, ini adalah ke kiri untuk prosedur lokal untuk biasanya meresepkan konten tam
bahan, persyaratan format, dan media.
Output peninjauan akan dikirimkan ke pembuat keputusan atau bertanggung jawab la
in seperti yang ditentukan oleh manajemen prosedur lokal. Output peninjauan juga
akan dikirimkan ke personel proyek yang terpengaruh.
5. Ulasan teknis
5.1 Pengenalan Teknik ulasan

tujuan dari sebuah kajian teknis adalah untuk mengevaluasi produk perangkat luna
k oleh tim personil yang memenuhi syarat untuk menentukan kelayakannya untuk pen
ggunaan yang dimaksudkan dan mengenali kesenjangan dari standar dan spesifikasi.
Ia menyediakan bukti untuk mengkonfirmasi management dengan status teknis dari
proyek.
Ulasan teknis mungkin juga memberikan rekomendasi dan pengkajian berbagai altern
atif, yang mungkin memerlukan lebih dari satu pertemuan. Pemeriksaan memerlukan
alamat tidak semua aspek-aspek produk.
11
IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak dan contoh
-contoh produk perangkat lunak Audit perihal teknis untuk meninjau termasuk, tet
api tidak terbatas pada, berikut:
persyaratan perangkat lunak desain perangkat lunak
spesifikasi description
dokum
entasi perangkat lunak tes perangkat lunak dokumentasi pengguna
manual Pemelihar
aan Sistem membangun prosedur instalasi
prosedur Catatan Rilis
proses pengembang
an perangkat lunak Spesifikasi keterangan
keterangan arsitektur perangkat lunak
5.2 Tanggung Jawab
peran berikut akan kokoh untuk peninjauan teknis:
sebuah) pembuat keputusan b) pemimpin peninjauan c) d) Teknis Perekam reviewer
peran berikut mungkin juga akan didirikan untuk peninjauan teknis:
e) staf Manajemen f) anggota tim lainnya g) para pemangku kepentingan lainnya se
perti manajer TI, Staf Teknis, pelanggan, dan pengguna
individu para peserta Mungkin bertindak dalam lebih dari satu peran, tetapi tida
k ada pribadi harus bertindak dalam semua peran-peran.
5.2.1 pembuat keputusan
kepada para pembuat keputusan adalah orang-kajian teknis dilakukan. Pembuat kepu
tusan akan menentukan apakah tujuan peninjauan telah terpenuhi.
5.2.2 pemimpin peninjauan
pemimpin peninjauan akan bertanggung jawab untuk meninjau. Tanggung jawab ini te
rmasuk melakukan tugas-tugas administratif yang terkait dengan pengujian, memast
ikan bahwa kajian tersebut adalah dilakukan dengan tertib, dan memastikan bahwa
meninjau memenuhi tujuan-tujuan mereka. Pemimpin peninjauan masalah akan output
peninjauan seperti yang dijelaskan dalam 5.7.
12
IEEE Std 1028-2008 Standard IEEE untuk Kaji Ulang dan perangkat lunak
Perekam 5.2.3 Audit
mendasi yang dibuat oleh tim kaji ulang.
5.2.4
Staf reviewer Teknis peran teknis akan berpartisipasi secara aktif dalam kaji ul
ang dan evaluasi produk perangkat lunak.
5.2.5
Staf staf Manajemen dalam peran manajemen dapat berpartisipasi dalam kajian tekn
is untuk tujuan mengidentifikasi masalah yang memerlukan resolusi manajemen.

Pelanggan 5.2.6 atau perwakilan pengguna
pemimpin peninjauan harus menentukan kebutuhan untuk pelanggan atau perwakilan p
engguna dengan menghormati ke peninjauan tertentu, dan menentukan cakupan perwak
ilan seperti dalam peran ini saat peninjauan.
5.3
ke Input Input kajian teknis akan meliputi yang berikut:
sebuah) sebuah pernyataan tujuan untuk peninjauan teknis b) produk perangkat lun
ak yang diteliti c) kelainan saat ini atau daftar masalah untuk produk perangkat
lunak d) Didokumentasikan meninjau
Input prosedur ke peninjauan teknis juga harus mencakup hal berikut ini:
e) laporan kaji ulang yang relevan f) ada peraturan, standar-standar, panduan, r
encana-rencana, spesifikasi, dan prosedur yang produk perangkat lunak harus dipe
riksa
g) meninjau materi dukungan seperti bentuk, checklist penting, peraturan, dan ka
tegorisasi anomali (lihat IEEE Std 1044- 1993 [B8])
bahan referensi tambahan mungkin disediakan oleh orang-orang yang bertanggung ja
wab untuk produk perangkat lunak saat diminta oleh pemimpin peninjauan.
5.4 Entri kriteria
Otorisasi 5.4.1
kebutuhan untuk melakukan kajian teknis dari sebuah produk perangkat lunak akan
ditentukan oleh dokumen-dokumen proyek, seperti rencana proyek, rencana jaminan
kualitas, rencana keselamatan, dll. Selain yang ulasan teknis yang diperlukan ol
eh sebuah paket tertentu, kajian teknis lain mungkin akan diumumkan dan diseleng
garakan di atas oleh manajemen fungsional, otorisasi manajemen proyek, manajemen
kualitas perangkat lunak sistem, engineering, atau software engineering menurut
prosedur lokal. Ulasan teknis mungkin diperlukan untuk mengevaluasi dampak dari
pihak ketiga atau perangkat keras kelainan produk atau kekurangan pada produk p
erangkat lunak.
13
prasyarat 5.4.2
sebuah kajian teknis akan dilakukan hanya bila diperlukan review input sudah ter
sedia dan orang-orang yang ditetapkan ke peran-peran telah terpasang dengan bena
r dilatih.
Prosedur
Manajemen 5.5.1 5.5
Manajer persiapan harus memastikan bahwa kajian tersebut adalah dilakukan sepert
i yang diperlukan oleh standar yang berlaku dan prosedur dan persyaratan oleh di
amanatkan oleh hukum, kontrak, atau kebijakan lainnya. Untuk akhir ini, manajer
harus melakukan yang berikut:
Sebuah Rencana) waktu dan sumber daya yang diperlukan untuk ulasan, termasuk fun
gsi dukungan, seperti yang diperlukan dalam IEEE Std 2299- 1998 [B9] atau standa
r lainnya yang
ikan, menjalankan, dan mengelola ulasan c) menyediakan pelatihan dan orientasi p
ada prosedur peninjauan berlaku untuk proyek d) memastikan bahwa penilai terkesa
n tersedia dengan tingkat yang tepat dari keterampilan, pengetahuan dan keahlian
, cukup untuk memahami produk perangkat lunak di bawah meninjau.
Catatan-pemimpin peninjauan bertanggung jawab untuk memilih penilai terkesan, da
n manajemen yang bertanggung jawab untuk membuat mereka tersedia.
e) memastikan bahwa rencana ulasan yang dilakukan f) UU rekomendasi tim kaji ula
ng secara tepat waktu

5.5.2 merencanakan meninjau
pemimpin peninjauan akan bertanggung jawab untuk kegiatan berikut:
sebuah) mengidentifikasi, dengan dukungan manajemen yang sesuai, tim kaji ulang
b) Menetapkan tanggung jawab khusus untuk anggota tim kaji ulang c) Menjadwalkan
dan mengumumkan tempat pertemuan d) mendistribusikan materi peninjauan untuk pe
serta, sehingga cukup waktu untuk persiapan mereka e) Setel sebuah jadwal untuk
distribusi materi peninjauan, kembali komentar-komentar, dan penerusan komentar
kepada penulis untuk perangai
sebagai bagian dari prosedur perencanaan, tim kaji ulang akan menentukan jika Al
ternatif-alternatif yang akan dibahas pada review meeting. Alternatif mungkin di
bahas pada review meeting, kemudiannya dalam pertemuan yang terpisah, atau ke ki
ri untuk penulis dari produk perangkat lunak untuk mengatasi.
5.5.3 tinjauan umum tentang prosedur peninjauan
orang yang berpengalaman harus ada ringkasan prosedur peninjauan untuk tim kaji
ulang saat diminta oleh pemimpin peninjauan. Ringkasan ini mungkin terjadi sebag
ai bagian dari review meeting (lihat 5.5.6) atau sebagai pertemuan terpisah.
14
Tinjauan 5.5.4 Audit produk perangkat lunak
secara teknis yang berkualitas harus ada ringkasan produk perangkat lunak untuk
tim kaji ulang saat diminta oleh pemimpin peninjauan. Ringkasan ini mungkin terj
adi baik sebagai bagian dari review meeting (lihat 5.5.6) atau sebagai pertemuan
terpisah.
5.5.5
setiap anggota tim kaji ulang Persiapan akan memeriksa produk perangkat lunak da
n masukan peninjauan lain sebelum pertemuan kaji ulang. Kelainan bawaan terdetek
si selama pemeriksaan ini harus mendokumentasikan dan dikirim ke pemimpin peninj
auan.
Pemimpin peninjauan harus menggolongkan kelainan bawaan untuk memastikan bahwa w
aktu rapat reviu digunakan paling efektif.
Pemimpin peninjauan harus meneruskan kelainan bawaan untuk penulis dari produk p
erangkat lunak untuk disposisi.
Pemimpin peninjauan akan memverifikasi bahwa anggota tim itu bersedia untuk meni
njau pertemuan. Jika sebuah reviewer telah tidak bersedia terpasang dengan benar
, pemimpin peninjauan akan mengambil tindakan korektif, seperti menemukan sebuah
dalam, menetapkan pembahas tugas-penilai terkesan, atau lainnya ke rapat. penja
dwalan
Pemeriksaan 5.5.6
Selama kajian teknis, tim kaji ulang akan pegang salah satu atau lebih pertemuan
. Pertemuan-pertemuan tersebut akan mencapai tujuan-tujuan berikut:
sebuah) memutuskan dalam agenda untuk mengevaluasi produk perangkat lunak dan ke
lainan bawaan b) menentukan jika
1) produk perangkat lunak selesai 2) produk perangkat lunak sesuai dengan peratu
ran-peraturan, standar-standar, panduan, rencana-rencana, spesifikasi, spesifika
si, dan prosedur yang berlaku untuk proyek
3) Jika berlaku, perubahan pada produk perangkat lunak dilaksanakan secara benar
dan mempengaruhi hanya daerah yang ditetapkan
4) perangkat lunak yang cocok untuk produk dimaksudkan menggunakan 5) perangkat
lunak siap untuk produk aktivitas berikutnya 6) temuan-temuan mengharuskan perub
ahan dalam jadwal proyek 7) perangkat lunak bawaan ada dalam elemen-elemen siste
m lain seperti perangkat keras atau perangkat lunak yang saling melengkapi/ekste
rnal
c) mengidentifikasi dan kelainan memutuskan criticality mereka
catatan-Penetapan Item tindakan yang ditinggalkan untuk management tindak lanjut
.
d) Membuat daftar item tindakan, menekankan risiko e) Dokumentasikan
setelah pertemuan produk perangkat lunak tersebut telah diulas, dokumentasi akan
dibuat untuk mendokumentasikan pertemuan, kelainan daftar ditemukan dalam produ
k perangkat lunak, dan menerangkan rekomendasi-rekomendasi untuk manajemen.
Ketika kelainan bawaan ini cukup dingin kritis atau banyak, pemimpin peninjauan
harus merekomendasikan bahwa sebuah pemeriksaan tambahan akan diterapkan pada pr
oduk perangkat lunak dimodifikasi. Hal ini, minimal, harus menutupi kawasan prod
uk diubah untuk mengatasi kelainan bawaan serta efek samping dari perubahan-peru
bahan tersebut.
15
pemandangannya 5.5.7/tindak lanjut
pemimpin peninjauan akan memverifikasi bahwa tindakan yang ditetapkan dalam pert
emuan item telah ditutup.
5.6 Keluar Dari
kajian teknis kriteria akan dianggap lengkap saat kegiatan yang tercantum dalam
5.5.6 telah digenapi dan output yang dijelaskan dalam 5.7 ada.
Output 5,7
output dari kajian teknis akan terdiri dari bukti yang mengidentifikasi didokume
ntasikan berikut:
sebuah) Proyek dikaji ulang b) tim kaji ulang anggota c) Dalam produk perangkat
lunak ditinjau d) masukan tertentu untuk meninjau e) Meninjau tujuan dan apakah
mereka bertemu f) daftar produk perangkat lunak bawaan g) daftar belum terselesa
ikan atau kelainan perangkat keras sistem atau item tindakan spesifikasi h) daft
ar masalah manajemen saya) status item Tindakan (buka, ditutup), kepemilikan dan
tanggal target (jika terbuka), atau tanggal penyelesaian (jika ditutup)
j) rekomendasi-rekomendasi yang dibuat oleh tim kaji ulang pada bagaimana untuk
membuang masalah belum terselesaikan dan kelainan bawaan
k) apakah produk perangkat lunak memenuhi peraturan yang berlaku, standar-standa
r, panduan, rencana-rencana, spesifikasi, dan Prosedur
Standar ini, walaupun penyimpangan tanpa menetapkan persyaratan minimum untuk is
i didokumentasikan bukti, ini adalah ke kiri untuk prosedur lokal untuk biasanya
meresepkan konten tambahan, persyaratan format, dan media.
6.
6.1 Pendahuluan untuk pemeriksaan inspeksi
tujuan sebuah inspeksi adalah untuk mendeteksi dan mengidentifikasi produk peran
gkat lunak bawaan. Sebuah inspeksi adalah sebuah pemeriksaan peer yang sistemati
s melakukan salah satu atau lebih dari yang berikut:
sebuah) Memverifikasi bahwa produk perangkat lunak memuaskan spesifikasi-b) Memv
erifikasi bahwa produk perangkat lunak berpameran ditetapkan atribut kualitas c)
Memverifikasi bahwa produk perangkat lunak sesuai dengan peraturan yang berlaku
, standar-standar, panduan, rencana-rencana, spesifikasi, prosedur dan
d) mengidentifikasi penyimpangan dari item ketentuan a), item b), dan c) e) meng
umpulkan data teknik perangkat lunak (misalnya, upaya anomali dan data)
16
f) menyediakan perangkat lunak yang dikumpulkan oleh engineering data yang dapat
digunakan untuk meningkatkan proses inspeksi dirinya sendiri dan dokumentasi pe
ndukung (misalnya, checklist penting)
g) atau tidak kena hibah permintaan untuk pelanggaran terhadap di mana adjudicat
ion standar dari tipe dan sejauh mana pelanggaran yang telah ditetapkan pada yur
isdiksi inspeksi
h) menggunakan data input sebagai manajemen proyek keputusan-keputusan yang sesu
ai (misalnya, untuk membuat trade-off antara pemeriksaan tambahan versus penguji
an tambahan)
Inspeksi terdiri dari dua sampai enam peserta (termasuk penulis). Sebuah inspeks
i adalah dipimpin oleh imparsial fasilitator terlatih yang telah dilatih dalam t
eknik inspeksi. Penentuan atau perbaikan tindakan investigasi untuk suatu anomal
i adalah elemen wajib sebuah inspeksi perangkat lunak, walaupun tidak terjadi da
lam resolusi dalam pertemuan inspeksi. Pengumpulan data untuk tujuan peningkatan
dan analisis teknik perangkat lunak prosedur tersebut elemen mandatori pemeriks
aan perangkat lunak.
Contoh-contoh produk perangkat lunak perihal untuk inspeksi termasuk, tapi tidak
terbatas pada, berikut:
persyaratan perangkat lunak perangkat lunak
keterangan desain spesifikasi kode s
umber perangkat lunak
dokumentasi perangkat lunak
tes dokumentasi pengguna manua
l Pemeliharaan Sistem
membangun prosedur instalasi prosedur
Catatan Rilis
model
perangkat lunak proses pengembangan perangkat lunak
Spesifikasi keterangan kebij
akan, strategi, dan rencana pemasaran
dan dokumen publikasi
keterangan arsitektu
r perangkat lunak
6.2 Tanggung Jawab
peran berikut akan kokoh untuk inspeksi:
sebuah) pemimpin Inspeksi b) Recorder c) Reader d) Penulis e) Inspektur
semua peserta dalam inspeksi adalah perwira. Penulis tidak harus bertindak sebag
ai pemimpin inspeksi dan tidak akan bertindak sebagai perekam atau pembaca. Pera
n lain yang dapat dipakai bersama di antara anggota tim. Masing-masing peserta m
ungkin bertindak dalam lebih dari satu peran.
17
individu memegang posisi manajemen Audit atas anggota tim inspeksi tidak akan be
rpartisipasi dalam inspeksi.
6.2.1 pemimpin Inspeksi
pemimpin inspeksi harus bertanggung jawab untuk merencanakan dan tugas-tugas org
anisasi yang terkait dengan pemeriksaan, akan menentukan bagian-bagian/komponenkomponen produk perangkat lunak dan dokumen sumber untuk diperiksa selama pertem
uan (bersama dengan penulis), akan bertanggung jawab untuk perencanaan dan perse
diaan seperti yang dijelaskan dalam 6.5.2 dan 6.5.4, akan memastikan bahwa inspe
ksi adalah dilakukan dengan tertib dan memenuhi tujuan-, akan memastikan bahwa d
ata inspeksi yang dikumpulkan, dan akan mengeluarkan output inspeksi seperti yan
g dijelaskan dalam 6.7.
Perekam 6.2.2
perekam yang akan kelainan dokumen, item tindakan, keputusan-keputusan, tidak ke
na rekomendasi dan, oleh tim inspeksi. Perekam yang harus merekam data inspeksi
yang diperlukan untuk analisis proses. Pemimpin inspeksi mungkin perekam.
Pembaca 6.2.3
pembaca akan memimpin tim inspeksi melalui produk perangkat lunak dalam komprehe
nsif dan fashion logis, menterjemahkan bahagian-bahagian bekerja (misalnya, umum
nya kelompok-kelompok Jangan pukuli 1 untuk 3 garis), dan menyorot aspek penting
. Produk Perangkat lunak dapat dibagi menjadi bagian logis dan ditetapkan ke pem
baca yang berbeda untuk mengurangi waktu pengolahan yang diperlukan.
6.2.4 Penulis
penulis akan bertanggung jawab untuk produk perangkat lunak memenuhi kriteria en
tri inspeksi, untuk memberikan kontribusi untuk berdasarkan inspeksi pemahaman k
husus dari produk perangkat lunak, dan untuk melakukan apa yang diperlukan untuk
membuat pemandangannya produk perangkat lunak memenuhi kriteria keluar inspeksi
.
6.2.5
Inspektur Inspektur akan mengidentifikasi dan menerangkan dalam produk perangkat
lunak bawaan. Perwira akan dipilih berdasarkan keahlian mereka dan harus dipili
h untuk mewakili pandangan yang berbeda pada pertemuan (misalnya, sponsor, persy
aratan, pengguna akhir, desain, daftar, keselamatan, tes, tes independen, manaje
men proyek, manajemen kualitas, dan teknik perangkat keras). Hanya orang-orang y
ang dipertikaikan yang berhubungan dengan produk-inspeksi harus hadir.
Beberapa perwira harus ditetapkan topik tertentu untuk memastikan jangkauan efek
tif. Misalnya, seorang petugas pengawas dapat memfokuskan pada test conformance
dengan standar tertentu atau standar, sintaks lainnya pada atau akurasi angka-an
gka, dan yang lain untuk konsistensi secara keseluruhan. Pandangan ini harus dib
erikan oleh pemimpin inspeksi saat merencanakan, sebagai yang disediakan dalam i
nspeksi item b) dari 6.5.2.
6.3
Input Input untuk inspeksi yang akan mencakup hal berikut ini:
sebuah) sebagai pernyataan sasaran inspeksi yang b) produk perangkat lunak(s) un
tuk diperiksa c) Didokumentasikan prosedur inspeksi d) bentuk pelaporan Inspeksi
18
e) atau kelainan daftar masalah f) Dokumen Sumber spesifikasi seperti perangkat
lunak dan masukan produk yang melayani sebagai dokumen yang telah digunakan oleh
penulis sebagai masukan untuk pengembangan produk perangkat lunak
untuk Input mungkin inspeksi juga meliputi yang berikut:
g) checklist penting h) Inspeksi kriteria kualitas untuk memerlukan perangkat lu
nak reinspection saya) pendahulunya produk yang sebelumnya telah telah diperiksa
, menyetujui, atau ditetapkan sebagai awal (baseline
j) ada peraturan, standar-standar, panduan, rencana-rencana, spesifikasi, dan pr
osedur yang produk perangkat lunak adalah untuk diperiksa
k), perangkat keras atau perangkat lunak lainnya, instrumentasi spesifikasi prod
uk l) data kinerja m) Anomali kategori (lihat IEEE Std 1044-1993 [B8])
bahan referensi tambahan mungkin dibuat Tersedia oleh orang-orang yang bertanggu
ng jawab untuk produk perangkat lunak saat diminta oleh pemimpin inspeksi.
6.4 Entri kriteria
6.4.1
Pemeriksaan otorisasi akan direncanakan dan didokumentasikan dalam dokumen peren
canaan proyek yang sesuai (misalnya, rencana proyek, rencana jaminan kualitas pe
rangkat lunak, atau verifikasi perangkat lunak dan rencana validasi).
Pemeriksaan tambahan mungkin akan dilakukan selama akuisisi, pengembangan, pasok
an operasi, dan pemeliharaan produk perangkat lunak pada permintaan dari manajem
en proyek, manajemen kualitas, atau penulis, menurut prosedur lokal.
6.4.2 Prasyarat
akan dilakukan inspeksi hanya ketika masukan inspeksi yang relevan yang tersedia
.
6.4.3 kriteria entri Minimum
Inspeksi tidak akan dilaksanakan sampai semua kejadian berikut ini telah terjadi
, kecuali jika ada didokumentasikan rasional, diterima oleh manajemen, untuk pen
gecualian dari peruntukan-peruntukan ini:
sebuah) pemimpin inspeksi menentukan bahwa produk perangkat lunak untuk diperiks
a selesai dan sesuai dengan standar-standar proyek untuk format.
b)-kesalahan otomatis mendeteksi tools (seperti ejaan checkers dan compiler) tel
ah digunakan untuk mengenali dan melenyapkan kesilapan sebelum inspeksi.
c) sebelum tonggak bersejarah yang produk perangkat lunak tergantung kenyang sep
erti yang telah diidentifikasi dalam dokumen perencanaan yang sesuai.
d) diperlukan dokumentasi pendukung tersedia.
e) Untuk sebuah reinspection, semua item diperhatikan pada anomali daftar yang m
empengaruhi produk perangkat lunak di bawah inspeksi adalah teratasi.
19
Prosedur
persiapan manajemen 6.5.1 6.5
akan memastikan bahwa manajemen inspeksi adalah dilakukan seperti yang diperluka
n oleh standar yang berlaku dan prosedur dan persyaratan oleh diamanatkan oleh h
ukum, kontrak, atau kebijakan lainnya. Untuk akhir ini, manajer akan melakukan y
ang berikut:
Sebuah Rencana) waktu dan sumber daya yang diperlukan untuk inspeksi, termasuk f
ungsi dukungan, seperti yang diperlukan dalam IEEE Std 1058-1998 [B9] atau stand
ar lainnya yang
b) Menyediakan dana, infrastruktur, dan fasilitas yang diperlukan untuk merencan
akan, mendefinisikan, menjalankan, dan mengelola
c) menyediakan pelatihan inspeksi dan orientasi pada prosedur inspeksi yang berl
aku untuk proyek d) memastikan bahwa anggota tim inspeksi memiliki tingkat sesua
i keahlian dan pengetahuan yang cukup untuk memahami produk perangkat lunak di b
awah
e) memastikan bahwa inspeksi inspeksi direncanakan, dan bahwa pemeriksaan direnc
anakan dilakukan f) UU rekomendasi tim inspeksi secara tepat waktu
6.5.2 merencanakan
penulis akan inspeksi pasang bahan inspeksi untuk pemimpin inspeksi. Bahan-bahan
inspeksi termasuk produk perangkat lunak untuk diperiksa, standar-standar dan d
okumen yang telah digunakan untuk mengembangkan produk perangkat lunak, dan seba
gainya.
pemimpin inspeksi harus bertanggung jawab untuk kegiatan berikut:
sebuah) mengidentifikasi, dengan dukungan manajemen yang sesuai, tim inspeksi
catatan-Memastikan bahwa anggota tim inspeksi memiliki tingkat sesuai keahlian d
an pengetahuan yang cukup untuk memahami produk perangkat lunak untuk diperiksa
serta dokumen-dokumen yang digunakan oleh penulis untuk mengembangkan produk per
angkat lunak.
b) Menetapkan tanggung jawab khusus untuk anggota tim inspeksi c) menjadwalkan p
ertemuan tanggal dan waktu, pilih tempat pertemuan, dan memberitahu tim inspeksi
d) mendistribusikan materi inspeksi untuk peserta, dan izinkan waktu yang memad
ai untuk persiapan mereka e) Setel sebuah jadwal untuk distribusi Dari bahan ins
peksi dan untuk kembali komentar-komentar dan penerusan komentar kepada penulis
untuk perangai
f) Menetapkan cakupan, termasuk prioritas inspeksi bagian dari dokumen-dokumen y
ang harus diperiksa
pemimpin inspeksi harus bertanggung jawab untuk aktivitas berikut:
g) Menubuhkan diantisipasi laju inspeksi untuk persiapan pertemuan dan
catatan-Dalam banyak kasus, laju inspeksi adalah antisipasi elemen penting dari
perencanaan inspeksi. Tabel berikut menyediakan panduan untuk inspeksi tipikal a
nomali dan internet, internet dalam istilah rekaman dari halaman-halaman atau ba
ris kode per jam:
20
jenis dokumen audit diperiksa
Arsitektur suku bunga Inspeksi 2 PPH untuk 3 PPH (lihat catatan 1) 2 PPH, persya
ratan untuk 3 PPH desain awal 3 PPH untuk 4 PPH desain terperinci 3 PPH untuk 4
kode sumber PPH 100 PPH 200 LPH (lihat catatan 2) Rencana Tes 5 PPH untuk 7 PPH
perbaikan dan perubahan 50 PPH untuk 75 LPH Dokumentasi Pengguna 8 PPH untuk 20
PPH
catatan 1- halaman per jam.
Catatan 2- Baris (kode) per jam.
6.5.3 gambaran umum tentang
peran prosedur inspeksi akan ditetapkan oleh pemimpin inspeksi. Pemimpin inspeks
i akan menjawab pertanyaan-pertanyaan mengenai setiap checklist penting dan pene
tapan peran dan harus ada data inspeksi seperti waktu persiapan minimal, dianjur
kan laju inspeksi, dan jumlah tipikal ditemukan dalam inspeksi sebelumnya kelain
an dari produk serupa.
6.5.4 gambaran umum tentang produk inspeksi
penulis harus ada ringkasan produk perangkat lunak untuk diperiksa. Ringkasan in
i harus digunakan untuk memperkenalkan para perwira ke produk perangkat lunak. G
ambaran umum yang mungkin dihadiri oleh personel proyek lainnya yang dapat keunt
ungan dari presentasi.
6.5.5
setiap anggota tim inspeksi Persiapan akan memeriksa produk perangkat lunak dan
masukan lainnya sebelum pertemuan kaji ulang. Kelainan bawaan terdeteksi selama
pemeriksaan ini akan dicatat dan dikirimkan ke pemimpin inspeksi. Pemimpin inspe
ksi harus menggolongkan kelainan bawaan seperti yang dijelaskan dalam 6.8.1 untu
k menentukan apakah mereka menjamin pembatalan rapat inspeksi, dan dalam rencana
untuk menggunakan waktu yang efisien dalam pertemuan inspeksi. Jika pemimpin in
speksi menentukan bahwa sejauh mana atau kesungguhan kelainan bawaan waran, pemi
mpin inspeksi dapat membatalkan, meminta inspeksi nanti ketika produk perangkat
lunak inspeksi memenuhi kriteria entri minimal dan secara masuk akal bebas cacat
. Pemimpin inspeksi harus meneruskan kelainan bawaan untuk penulis dari produk p
erangkat lunak untuk disposisi.
Pemimpin inspeksi atau akan menetapkan cocok pembaca urutan produk perangkat lun
ak akan diperiksa (seperti, berurutan aliran data, hierarki, aliran kontrol, baw
ah ke atas, atau bagian atas ke bawah). Pembaca(s) akan mempersiapkan yang cukup
untuk dapat mempresentasikan produk perangkat lunak pada pertemuan inspeksi.
Pemimpin inspeksi akan memverifikasi bahwa perwira itu bersedia untuk inspeksi.
Pemimpin inspeksi akan menjadwalkan kembali pertemuan jika para perwira tidak te
rpasang dengan benar siap. Pemimpin inspeksi harus mengumpulkan individu waktu p
engolahan dan catat total dalam dokumentasi inspeksi.

Pemeriksaan 6.5.6
pertemuan inspeksi akan mengikuti acara seperti yang dijelaskan dalam 6.5.6.1 me
lalui 6.5.6.5.
21
6.5.6.1 Audit Memperkenalkan pertemuan
pemimpin inspeksi akan memperkenalkan peserta dan menerangkan peran mereka. Pemi
mpin inspeksi negara akan tujuan dan inspeksi harus mengingatkan para perwira un
tuk memusatkan upaya-upaya mereka untuk deteksi anomali, resolusi tidak. Pemimpi
n inspeksi akan mengingatkan para perwira untuk pernyataan mereka langsung ke da
n untuk komentar hanya perekam pada produk perangkat lunak, tidak penulisnya. Da
pat mengajukan pertanyaan untuk para inspektur penulis mengenai produk perangkat
lunak. Pemimpin inspeksi akan menyelesaikan prosedur khusus pertanyaan yang dia
jukan oleh para perwira. Diskusi luas tentang masalah-masalah yang harus ditunda
untuk akhir pertemuan atau untuk rapat yang terpisah.
6.5.6.2 Meninjau
Kelainan item umum merujuk kepada produk perangkat lunak secara umum (dan dengan
itu tidak boleh dipertalikan dengan instance tertentu atau lokasi:) akan disamp
aikan kepada para perwira dan dicatat.
6.5.6.3 Meninjau produk perangkat lunak dan kelainan rekaman
pembaca akan mempresentasikan produk perangkat lunak ke tim inspeksi. Tim inspek
si akan memeriksa produk perangkat lunak secara objektif dan secara saksama, dan
pemimpin inspeksi akan fokus pertemuan bagian ini pada membuat daftar anomali.
Perekam yang akan masuk setiap anomali, lokasi, keterangan, dan pada daftar anom
ali klasifikasi. IEEE Std 1044-1993 [B8] mungkin digunakan untuk mengklasifikasi
kan kelainan bawaan. Selama waktu ini, penulis akan menjawab pertanyaan tertentu
dan memberikan kontribusi untuk deteksi anomali berdasarkan pada pemahaman penu
lis produk perangkat lunak. Jika terdapat perselisihan tentang suatu anomali, an
omali potensi akan di-log dan ditandai untuk resolusi pada akhir pertemuan.
6.5.6.4 Tinjau daftar anomali
pada akhir pertemuan inspeksi, pemimpin inspeksi akan memiliki daftar anomali di
tinjau dengan tim untuk memastikan kelengkapan dan akurasi. Pemimpin inspeksi ha
rus membolehkan waktu untuk mendiskusikan setiap saat terjadi perselisihan anoma
li. Pemimpin inspeksi tidak akan mengizinkan diskusi untuk fokus pada mengatasi
anomali, tetapi pada mengklarifikasi apa yang dimaksud anomali tersebut. Jika ke
tidaksepakatan sebagai untuk keberadaan atau keseriusan suatu anomali tidak dapa
t diselesaikan dengan cepat selama pertemuan, yang akan perselisihan didokumenta
sikan dalam laporan anomali tersebut.
6.5.6.5 membuat keputusan keluar
tujuan keputusan keluar adalah membawa penutupan berwibawa ke pertemuan inspeksi
. Keputusan keluar akan menentukan apakah produk perangkat lunak memenuhi kriter
ia kualitas dan keluar inspeksi. Sebagai bagian dari keputusan ini, pengaplingan
sesuai dan verifikasi apa pun akan ditetapkan. Khususnya, tim inspeksi akan men
gidentifikasi produk perangkat lunak perangai sebagai salah satu dari yang berik
ut:
sebuah) menerima dengan tidak ada verifikasi atau dengan verifikasi pemandangann
ya. Produk Perangkat Lunak ini diterima sebagai adalah atau dengan hanya sedikit
pengaplingan (misalnya, yang akan tidak memerlukan verifikasi lebih lanjut).
b) menerima dengan verifikasi pemandangannya. Produk Perangkat Lunak diterima se
telah pemimpin inspeksi atau anggota yang ditentukan dari tim inspeksi (selain p
enulis) memverifikasi.
c) Reinspect pemandangannya. Produk Perangkat Lunak tidak dapat diterima. Kelain

an bawaan telah diselesaikan sekali sebuah reinspection harus dijadwalkan untuk
memverifikasi pemandangannya. Minimal, sebuah reinspection akan memeriksa daerah
produk perangkat lunak diubah untuk mengatasi kelainan bawaan dikenalpasti dala
m inspeksi terakhir, serta efek samping dari perubahan-perubahan tersebut.
6.5.7 Pengaplingan/tindak lanjut
pemimpin inspeksi akan memverifikasi bahwa tindakan yang ditetapkan dalam pertem
uan item telah ditutup.
22
IEEE Std 1028-2008 Standard IEEE untuk Kaji Ulang dan perangkat lunak
6.6 Keluar kriteria Audit
Pemeriksaan akan dianggap lengkap saat kegiatan yang tercantum dalam 6.5 telah d
iselesaikan, dan output yang dijelaskan dalam 6.7 ada.
Output 6.7
output dari akan didokumentasikan inspeksi yang mengidentifikasi bukti berikut:
sebuah) proyek yang menciptakan produk perangkat lunak inspeksi di bawah b) angg
ota tim inspeksi c) Durasi rapat inspeksi d) produk perangkat lunak diperiksa e)
Ukuran bahan-bahan diperiksa (misalnya, jumlah halaman teks) f) masukan tertent
u ke g) inspeksi sasaran inspeksi dan apakah mereka bertemu h) anomali, yang ber
isi setiap anomali, daftar lokasi:, keterangan, dan aku) memang benar, klasifika
si dari produk perangkat lunak j) tidak kena apa pun yang diberikan atau yang di
minta tidak kena k) Individu dan waktu pengolahan total dari tim inspeksi l) tot
al waktu pemandangannya
output inspeksi harus mencakup hal berikut ini:
m) anomali inspeksi rangkuman Kode jumlah dikenali oleh masing-masing kelainan k
ategori anomali
n) perkiraan dari upaya pemandangannya dan pengaplingan tanggal penyelesaian, ji
ka upaya pemandangannya diharapkan untuk bermakna
output inspeksi meliputi yang berikut:
Hai) Perkiraan dengan mengikat simpanan item yang ditemukan dalam pemeriksaan, d
ibandingkan dengan biaya mereka untuk memperbaiki jika kemudian dikenal
meskipun Standar ini mengatur persyaratan minimum untuk isi didokumentasikan buk
6.8
Pemeriksaan Pengumpulan Data akan menyediakan data untuk analisis terhadap kuali
tas produk perangkat lunak, efektivitas akuisisi, pengembangan, pasokan, proses
operasi dan pemeliharaan, dan efektivitas dan efisiensi sendiri inspeksi. Untuk
menjaga efektivitas inspeksi, data dari penulis inspektur dan tidak akan digunak
an untuk mengevaluasi performa individu-individu. Untuk mengaktifkan analisa, ke
lainan bawaan yang diidentifikasi pada sebuah pertemuan inspeksi akan diklasifik
asikan sesuai dengan 6.8.1, 6.8.2, dan 6.8.3.
Data inspeksi akan berisi identifikasi dari produk perangkat lunak, tanggal dan
waktu pemeriksaan, tim inspeksi, persiapan dan inspeksi kali, volume bahan-bahan
diperiksa, dan
23
watak-Audit diperiksa produk perangkat lunak. Penangkapan informasi ini akan dig
unakan untuk mengoptimalkan petunjuk lokal untuk inspeksi.
Pengelolaan data inspeksi memerlukan kemampuan untuk masuk, menyimpan, mengakses
, memperbarui, meringkas, laporan dan diklasifikasikan kelainan bawaan. Frekuens
i dan jenis-jenis laporan analisis inspeksi, dan distribusi mereka, di kiri ke s
tandar local dan prosedur.
Anomali 6.8.1
Klasifikasi klasifikasi produk perangkat lunak bawaan akan berakhir, misalnya, m
enggunakan IEEE Std 1044- 1993 [B8] skema klasifikasi. Anomali memfasilitasi ter
minologi standar klasifikasi untuk dalam atau antara proyek-proyek kelainan dan
organisasi. IEEE Std 1044-1993 [B8] mendefinisikan sejumlah kategori-kategori da
lam yang dapat diklasifikasikan kelainan bawaan. Kategori sebuah proyek dapat me
milih bergantung pada banyak faktor, termasuk produk perangkat lunak dan tahap s
iklus hidup.
Anomali 6.8.2
Kategori kategori mewakili berbagai sifat-sifat suatu anomali untuk klasifikasi
kelompok-kelompok yang dimiliki. Anomali kategori yang dapat mewakili ketika ano
mali ditemukan, hasil penyelidikan, dampaknya, kegiatan resolusi, dan watak akhi
r.
Misalnya, sebuah dokumentasi perangkat lunak nonconformance-kategori jenis klasi
fikasi meliputi yang berikut:
Hilang (berlebihan) Ekstra Membingungkan tidak konsisten tidak menyesuaikan diri
standar yang cenderung risiko, iaitu, kajian menemukan bahwa, walaupun sebuah i
tem tidak ditunjukkan sebagai "salah," pendekatan yang diambil melibatkan resiko
(dan diketahui adanya metode alternatif yang lebih aman) Unachievable (misalnya
salah, karena sistem, waktu, atau keterbatasan teknis)
Anomali 6.8.3 Editorial
Kelainan peringkat akan menduduki peringkat oleh kemungkinan pengaruh pada produ
k perangkat lunak, misalnya, sebagai berikut:
sebuah) Bencana. Kelainan bawaan yang akan menyebabkan kegagalan perangkat lunak
dengan konsekuensi kubur, seperti kehilangan nyawa, kegagalan misi, atau ekonom
i yang sangat besar atau kerugian sosial; tidak mungkin mitigasi.
b) Sangat Penting. Kelainan bawaan yang akan menyebabkan kegagalan perangkat lun
ak dengan konsekuensi utama, seperti cedera, sistem utama penurunan, kegagalan m
isi sebagian, atau ekonomi utama atau kerugian sosial; partial untuk menyelesaik
an mungkin mitigasi.
c) Marginal. Kelainan bawaan yang akan menyebabkan kegagalan perangkat lunak den
gan konsekuensi kecil; menyelesaikan mungkin mitigasi.
d) sangat minim. Kelainan bawaan yang tidak akan menyebabkan kegagalan perangkat
lunak; tidak perlu mitigasi.
24
6,9 Perbaikan
data inspeksi audit akan dianalisis secara teratur untuk meningkatkan proses ins
peksi sendiri, dan harus digunakan untuk meningkatkan kegiatan yang digunakan un
tuk menghasilkan produk perangkat lunak. Sering-sering terjadi akan kelainan dis
ertakan dalam checklist penting inspeksi atau penetapan peran. Dalam checklist p
enting sendiri juga akan diperiksa secara teratur untuk berlebihan atau menyesat
kan pertanyaan. Secara konsisten diberikan atau tidak kena diminta akan dianalis
a untuk menentukan jika standar yang perlu diubah. Waktu persiapan, kali pertemu
an, dan jumlah peserta akan dianalisa untuk menentukan koneksi antara (memeriksa
) bunga persiapan pertemuan, tukar, dan jumlah dan keparahan kelainan bawaan yan
g ditemukan. Manfaat penghematan () dicapai harus dikaji secara teratur, dan pro
ses inspeksi harus terus-menerus diadaptasi untuk mencapai lebih efektifitas pad
a efisiensi maksimum
7. Berjalan-terusan
7.1 Pendahuluan untuk berjalan-terusan
tujuan secara sistematis berjalan-melalui adalah untuk mengevaluasi produk peran
gkat lunak. Berjalan-melalui dapat diselenggarakan untuk tujuan untuk mendidik p
enonton mengenai produk perangkat lunak. Tujuan utama adalah sebagai berikut:
sebuah) menemukan kelainan bawaan b) meningkatkan produk perangkat lunak c) meng
anggap implementasi alternatif d) Mengevaluasi conformance ke standar dan spesif
ikasi e) Mengevaluasi kegunaan dan aksesibilitas produk perangkat lunak
tujuan penting lainnya dari berjalan-melalui termasuk pertukaran teknik-teknik,
style variasa, dan peserta pelatihan. Berjalan-melalui mungkin menunjukkan kekur
angan (misalnya, efisiensi dan mudah dimengerti masalah dalam produk perangkat l
unak, modularity masalah-masalah dalam desain atau kode, atau spesifikasi untest
able).
Contoh-contoh produk perangkat lunak perihal untuk berjalan-terusan termasuk, te
tapi tidak terbatas pada, berikut:
persyaratan perangkat lunak perangkat lunak
keterangan desain spesifikasi kode s
umber perangkat lunak
rencana tes dan prosedur dokumentasi pengguna perangkat lu
nak manual Spesifikasi
Pemeliharaan Sistem
membangun prosedur instalasi
prosedur
catatan rilis Lisensi Perangkat Lunak
proses pengembangan perangkat lunak
keter
angan keterangan arsitektur
25
Tanggung Jawab 7.2
-Audit peran berikut akan kokoh untuk berjalan-melalui:
sebuah) berjalan-melalui pemimpin Perekam b) c) Penulis d) anggota tim
untuk meninjau harus dipertimbangkan secara sistematis berjalan-melalui, sebuah
tim yang terdiri dari sekurang-kurangnya dua anggota (termasuk penulis) akan ber
kumpul. Peran-peran yang dapat dipakai bersama di antara anggota tim. Gerak jala
n-melalui pemimpin atau penulis dapat melayani sebagai perekam. Gerak jalan-mela
lui mungkin pemimpin penulis.
Individu yang memegang posisi manajemen atas anggota tim yang berjalan-melalui t
idak akan berpartisipasi dalam berjalan-melalui.
7.2.1 Berjalan-melalui
gerak jalan-pemimpin pemimpin melalui akan melakukan berjalan-melalui, akan mena
ngani tugas-tugas administratif yang berhubungan dengan berjalan-melalui (sepert
i mendistribusikan dan mengatur pertemuan dokumen), dan akan memastikan bahwa be
rjalan-melalui dilaksanakan secara teratur. Gerak jalan-melalui akan menyiapkan
pernyataan pemimpin tujuan panduan untuk tim melalui berjalan-melalui. Gerak jal
an-melalui akan memastikan bahwa pemimpin tiba di sebuah keputusan tim atau diid
entifikasi untuk masing-masing item diskusi tindakan, dan akan mengeluarkan berj
alan-output melalui seperti yang dijelaskan dalam 7.7.
7.2.2
perekam yang akan perekam catatan semua keputusan dan diidentifikasi tindakan-ti
ndakan yang timbul selama berjalan-melalui pertemuan. Selain itu, harus perekam
catatan semua komentar-komentar yang dibuat sewaktu berjalan-melalui yang ditemu
kan, mengajukan pertanyaan-pertanyaan kelainan style, kekurangan, kontradiksi, s
aran-saran perbaikan, atau pendekatan alternatif.

7.2.3 Penulis
penulis harus ada produk perangkat lunak dalam berjalan-melalui.
7.2.4anggota Tim
Berjalan-melalui anggota tim akan terpasang dengan benar mempersiapkan diri dan
berpartisipasi secara aktif dalam berjalan-melalui.
Anggota tim akan mengidentifikasi dan menerangkan dalam produk perangkat lunak b
awaan.
7.3
Input Input ke berjalan-melalui akan meliputi yang berikut:
sebuah) sebuah pernyataan tujuan untuk berjalan-melalui b) produk perangkat luna
k yang diteliti c) Standar yang secara berkesannya untuk akuisisi, pengembangan,
pasokan, pengoperasian, dan/atau pemeliharaan produk perangkat lunak
26
IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak dan audit
yang Input melalui mungkin juga meliputi yang berikut:
d) ada peraturan, standar-standar, panduan, rencana-rencana, spesifikasi, dan pr
osedur yang produk perangkat lunak adalah untuk dievaluasi
e) Anomali kategori (lihat IEEE Std 1044-1993 [B8]) f) berjalan-melalui checklis
t penting
wab untuk produk perangkat lunak saat diminta oleh berjalan-melalui pemimpin.
7,4 Entri kriteria
Otorisasi 7.4.1
kebutuhan untuk melakukan berjalan-terusan akan kokoh dalam dokumen perencanaan
proyek yang sesuai.
Berjalan-terusan tambahan mungkin akan dilakukan selama akuisisi, pengembangan,
pasokan operasi, dan pemeliharaan produk perangkat lunak pada permintaan dari ma
najemen proyek, manajemen kualitas, atau penulis, menurut prosedur lokal.
Prasyarat 7.4.2
berjalan-melalui akan dilakukan hanya bila semua kondisi berikut telah dipenuhi:
sebuah) sebuah pernyataan tujuan untuk meninjau didirikan.
b) masukan peninjauan yang diperlukan tersedia.
c) standar apa pun yang diperlukan untuk mengevaluasi produk perangkat lunak ter
sedia.
Prosedur
Manajemen 7.5.1 7,5
Manajer persiapan atau orang yang bertanggung jawab untuk berjalan-melalui akan
memastikan bahwa berjalan-melalui dilakukan seperti yang diperlukan oleh standar
yang berlaku dan prosedur dan persyaratan oleh diamanatkan oleh hukum, kontrak,
atau kebijakan lainnya. Untuk tujuan ini, mereka akan melakukan yang berikut:
Sebuah Rencana) waktu dan sumber daya yang diperlukan untuk berjalan-terusan, te
rmasuk fungsi dukungan, seperti yang diperlukan dalam IEEE Std 1058-1987 [B9] at
au standar lainnya yang
ikan, menjalankan, dan mengelola berjalan-melalui c) menyediakan pelatihan dan o
rientasi pada berjalan-melalui prosedur yang berlaku untuk proyek d) memastikan
bahwa berjalan-melalui anggota tim memiliki tingkat sesuai keahlian dan pengetah
uan yang cukup untuk memahami produk perangkat lunak
e) memastikan bahwa direncanakan berjalan-terusan dilakukan f) UU berjalan-melal
ui rekomendasi tim secara tepat waktu
7.5.2 sampai merencanakan berjalan-melalui
berjalan-pemimpin melalui akan bertanggung jawab untuk kegiatan berikut:

sebuah) Mengenali berjalan-tim melalui
27
b) menjadwalkan pertemuan dan pilih tempat pertemuan c) mendistribusikan materi
input yang diperlukan untuk peserta, dan izinkan waktu yang memadai untuk persia
pan mereka
Ringkasan 7.5.3
ringkasan presentasi dapat dilakukan oleh penulis sebagai bagian dari berjalan-m
elalui pertemuan.
7.5.4 Persiapan
berjalan-melalui akan mendistribusikan perangkat lunak pemimpin dan produk perte
rmuan berjalan-melalui pertemuan. Anggota tim akan menyiapkan pertemuan dengan m
enguji produk perangkat lunak dan menyiapkan sebuah daftar item untuk diskusi pa
da pertemuan. Item ini harus dibagi menjadi dua kategori: tertentu dan umum. Ite
m umum berlaku untuk seluruh produk; item tertentu berlaku untuk sebahagian dari
padanya.
Masing-masing berjalan-melalui anggota tim akan memeriksa produk perangkat lunak
dan masukan peninjauan lain sebelum pertemuan kaji ulang. Kelainan bawaan terde
teksi selama pemeriksaan ini akan dicatat dan dikirimkan ke berjalan- melalui pe
mimpin. Gerak jalan-melalui harus menggolongkan kelaianan bawaan pemimpin untuk
memastikan bahwa berjalan-melalui waktu pertemuan digunakan secara efektif. Gera
k jalan-melalui harus meneruskan kelainan bawaan pemimpin untuk penulis dari pro
duk perangkat lunak untuk disposisi.
Penulis atau berjalan-melalui akan menetapkan cocok pemimpin urutan produk peran
gkat lunak akan dievaluasi (seperti, berurutan aliran data, hierarki, aliran kon
trol, bawah ke atas, atau bagian atas ke bawah).
Pemeriksaan 7.5.5
gerak jalan-melalui akan memperkenalkan peserta pemimpin dan menerangkan peran m
ereka. Gerak jalan-melalui pemimpin negara akan tujuan berjalan-melalui dan haru
s bertindak sebagai fasilitator untuk memastikan bahwa setiap orang yang mempuny
ai kesempatan untuk komentar dan harus meminta komentar dari peserta untuk memas
tikan bahwa semua mendengar suara-suara. Gerak jalan-melalui harus mengingatkan
tim pemimpin anggota untuk komentar hanya pada produk perangkat lunak, tidak pen
ulisnya. Anggota tim dapat mengajukan pertanyaan untuk penulis mengenai produk p
erangkat lunak. Gerak jalan-pemimpin akan menyelesaikan masalah melalui prosedur
khusus pertanyaan yang diajukan oleh anggota tim.
Penulis mungkin ada ringkasan produk perangkat lunak di bawah meninjau. Ini haru
s diikuti oleh sebuah diskusi umum selama anggota tim yang meningkatkan item umu
m mereka. Setelah diskusi umum, penulis menyajikan produk perangkat lunak secara
terperinci (dengan itu nama "berjalan-melalui") dengan menggunakan urutan diten
tukan sebagai bagian dari persiapan. Anggota tim mengangkat item tertentu ketika
penulis mencapai mereka dalam presentasi. Item baru mungkin muncul selama perte
muan. Gerak jalan-melalui koordinat pemimpin diskusi dan memandu pertemuan untuk
sebuah keputusan atau dikenali pada setiap item tindakan. Catatan perekam yang
semua rekomendasi tindakan yang diperlukan dan.
Selama berjalan-melalui pertemuan
dengan seorang) penulis atau berjalan-melalui harus membuat ringkasan pemimpin p
resentasi dari produk perangkat lunak di bawah diperiksa.
b) berjalan-melalui diskusi mengkoordinasi akan pemimpin dari kelainan umum kekh
awatiran.
c) penulis atau berjalan-melalui perangkat lunak harus mempersembahkan pemimpin
produk, menggambarkan setiap bagiannya.

d) anggota tim akan meningkatkan kelainan tertentu sebagai penulis mencapai bagi
an dari produk perangkat lunak yang kelainan bawaan berkaitan.
e) akan perekam catatan rekomendasi dan tindakan-tindakan yang timbul dari disku
si di atas tiap-tiap anomali.
28
IEEE Std 1028-2008 Standard IEEE untuk Audit Kaji Ulang dan Perangkat Lunak
setelah berjalan-melalui pertemuan, berjalan-melalui akan mengeluarkan berjalan
pemimpin-melalui merinci kelainan keputusan-keputusan output, tindakan, dan info
rmasi lain yang menarik. Persyaratan konten minimum untuk berjalan-melalui outpu
t di disediakan dalam 7.7.
7.5.6 Pengaplingan/menindaklanjuti
berjalan-melalui akan memverifikasi bahwa pemimpin item tindakan ditetapkan dala
m pertemuan tertutup.
7.6 Keluar
yang berjalan-kriteria melalui akan dianggap lengkap saat
sebuah) Tujuan menyatakan dalam sebuah item) 7.3 telah bertemu.
b) rekomendasi dan tindakan yang diperlukan telah direkam.
c) berjalan-output melalui telah selesai.
Output 7,7
output dari berjalan-melalui akan menjadi bukti yang mengidentifikasi didokument
asikan berikut:
sebuah) proyek yang berjalan-melalui dilakukan b) berjalan-melalui anggota tim c
) produk perangkat lunak yang diteliti d) pernyataan sasaran yang harus diselesa
ikan selama berjalan-melalui pertemuan ini dan apakah mereka bertemu
e) anomali, yang berisi setiap anomali, daftar lokasi: dan description f) daftar
rekomendasi yang dibuat mengenai setiap anomali g) daftar tindakan-tindakan, Ta
nggal Selesai, dan orang-orang yang bertanggung jawab h) rekomendasi-rekomendasi
yang dibuat oleh berjalan-melalui tim pada bagaimana untuk membuang defisiensi
dan belum terselesaikan kelainan bawaan
saya) Setiap proposal-proposal yang dibuat oleh berjalan-melalui tim untuk tinda
k lanjut berjalan-terusan
Walaupun Standar ini mengatur persyaratan minimum untuk Isi didokumentasikan buk
7.8 Pengumpulan Data rekomendasi
berjalan-terusan harus menyediakan data untuk analisis terhadap kualitas produk
perangkat lunak, efektivitas akuisisi, pengembangan, pasokan, pengoperasian, dan
proses pemeliharaan, dan efisiensi dalam gerak jalan-melalui sendiri. Untuk men
jaga efektivitas berjalan-terusan, data tidak boleh digunakan untuk mengevaluasi
performa individu-individu.
Berjalan-melalui data harus berisi identifikasi dari produk perangkat lunak, tan
ggal dan waktu berjalan- melalui, berjalan-melalui, persiapan dan pemimpin berja
lan-melalui kali, volume bahan-bahan yang berjalan melalui, dan perangai dari pr
oduk perangkat lunak. Penangkapan informasi ini dapat digunakan untuk mengoptima
lkan petunjuk lokal untuk berjalan-terusan.
29
pengelolaan berjalan Audit-melalui data memerlukan kemampuan untuk menyimpan, ma
sukkan, mengakses, memperbarui, meringkas, laporan dan dikategorikan kelainan ba
waan. Frekuensi dan jenis-jenis berjalan-melalui laporan analisis, dan distribus
i mereka, di kiri ke standar local dan prosedur.
Kelainan bawaan dikenalpasti selama berjalan-terusan dapat diklasifikasikan sesu
ai dengan IEEE Std 1044-1993 [B8].
7,9 Perbaikan
Berjalan-melalui data harus dianalisis secara teratur untuk meningkatkan berjala
n-melalui proses sendiri dan untuk meningkatkan kegiatan perangkat lunak yang di
gunakan untuk menghasilkan produk perangkat lunak. Sering-sering terjadi kelaina
n bawaan mungkin disertakan dalam berjalan-melalui checklist penting atau peneta
pan peran. Dalam checklist penting diri mereka juga harus dievaluasi secara tera
tur untuk berlebihan atau menyesatkan pertanyaan. Waktu persiapan, kali pertemua
n, dan jumlah peserta harus dianalisa untuk menentukan koneksi antara laju persi
apan pertemuan, tukar, dan jumlah dan keparahan kelainan bawaan yang ditemukan.
8.
8,1 Pendahuluan untuk audit audit
tujuan audit perangkat lunak adalah untuk memberikan evaluasi independen dari pr
oduk perangkat lunak kepatuhan dan proses untuk peraturan yang berlaku, standarstandar, panduan, rencana-rencana, spesifikasi, dan prosedur.
Contoh-contoh produk perangkat lunak perihal untuk mengaudit termasuk, tetapi ti
dak terbatas pada, berikut:
rencana pencadangan dan pemulihan
Kontngensi Kontrak
rencana pelanggan atau kelu
han perwakilan pengguna
rencana Bencana
rencana performa perangkat keras rencana
Instalasi prosedur instalasi
Rencana Pemeliharaan Laporan Manajemen Operasi
dan
panduan pengguna
Pengadaan dan penularan Laporan
metode dan data (misalnya, tin
jau audit, status proyek, anomali, laporan, data-data pengujian) Permintaan untu
k rencana manajemen risiko proposal
konfigurasi perangkat lunak rencana manajeme
n (lihat IEEE Std 828-2005 [B3]) keterangan desain Perangkat Lunak (lihat IEEE S
td 1016-1998 [B7]) kode sumber
30
Unit Audit folder pengembangan perangkat lunak rencana manajemen proyek (lihat I
EEE Std 1058-1998 [B9]) rencana jaminan kualitas Perangkat Lunak (lihat IEEE Std
730-2002 [B2]) persyaratan perangkat lunak (lihat spesifikasi IEEE Std 830-1998
[B5]) Perangkat Lunak rencana keselamatan (lihat IEEE Std 1228-1994 [B13.]) dok
umentasi Uji Software (lihat IEEE Std 829-2008 [B4]) dokumentasi pengguna perang
kat lunak (lihat IEEE Std 1063-2001 [B10]) verifikasi perangkat lunak dan rencan
a validasi (lihat IEEE Std 1012-2004 [B6]) keterangan arsitektur perangkat lunak
(lihat IEEE Std 1471-2000 [B14]) Standar , peraturan, panduan, rencana-rencana,
spesifikasi, prosedur dan Sistem membangun laporan Kaji Ulang Teknis prosedur do
kumen Vendor Berjalan-melalui laporan media 2000-2004 (perekat seperti dan diske
t)
Proses-proses perangkat lunak contoh-contoh perihal untuk mengaudit termasuk, te
tapi tidak terbatas pada, pengembangan perangkat lunak proses siklus hidup keter
angan
pemeriksaan harus dimulai dengan sebuah pertemuan pembukaan selama yang diaudit
mengkaji organisasi dan auditor dan setuju pada pengaturan untuk audit.
Ketika yang ditetapkan dalam rencana audit, para audtior mungkin membuat rekomen
dasi. -harus dilaporkan secara terpisah.
8.2 Tanggung Jawab
peran berikut akan kokoh untuk audit:
sebuah) auditor memimpin b) c Auditor) Perekam(s) d) Inisiator e) Diaudit
auditor yang memimpin organisasi dapat bertindak sebagai bendahara negara. Inisi
ator tidak bertindak sebagai auditor memimpin. Auditor tambahan yang harus diser
takan dalam tim audit; walau demikian, audit oleh satu orang yang diizinkan.
8.2.1 Memimpin
auditor yang memimpin auditor akan bertanggung jawab untuk audit. Tanggung jawab
ini mencakup tugas-tugas administratif yang berhubungan dengan audit, memastika
n bahwa audit yang dilakukan secara teratur, dan memastikan bahwa memenuhi tujua
n-audit. Auditor yang memimpin bertanggung jawab untuk hal-hal berikut:
sebuah) menyiapkan rencana audit (lihat 8.5.2)
31
b) berkumpul tim audit c) mengelola tim audit d) membuat keputusan-keputusan men
genai pelaksanaan audit e) membuat keputusan-keputusan mengenai pengamatan audit
apa pun f) Menyiapkan laporan audit (lihat 8.7) g) melaporkan pada ketidakmampu
an atau ketidakmampuan jelas sebarang individu yang terlibat dalam untuk memenuh
i tanggung jawab mereka audit
h) apa pun atau inkonsistensi kesenjangan perundingan dengan inisiator yang dapa
t mengganggu kemampuan untuk memenuhi kriteria keluar (lihat 8.6)
saya) menyarankan tindakan korektif
auditor yang memimpin akan bebas dari bias dan mempengaruhi yang dapat mengurang
i kemampuan untuk membuat tujuan, independen evaluasi.
Perekam 8.2.2
mendasi yang dibuat oleh tim audit.
Auditor 8.2.3
para audtior produk akan mengkaji, sebagaimana dijelaskan dalam rencana audit. M
ereka akan pengamatan mereka dokumen.
Auditor semua itu akan bebas dari bias dan mempengaruhi yang dapat mengurangi ke
mampuan mereka untuk membuat tujuan, independen evaluasi, atau mereka akan menge
nali bias mereka, dan lanjutkan dengan penerimaan dari inisiator.
8.2.4 Inisiator
inisiator akan bertanggung jawab untuk kegiatan berikut:
sebuah) memutuskan di atas perlu untuk audit b) memutuskan di atas Tujuan dan li
ngkup audit-c) memutuskan produk perangkat lunak atau proses yang akan diaudit d
) memutuskan kriteria penilaian, termasuk peraturan-peraturan, standar-standar,
panduan, rencana-rencana, spesifikasi, dan prosedur yang akan digunakan untuk ev
aluasi
e) memutuskan yang akan melaksanakan audit-f) Tinjau laporan audit g) memutuskan
apa yang akan tindak diperlukan h) mendistribusikan laporan audit
inisiator mungkin menjadi manager dalam organisasi yang telah diaudit, pelanggan
atau perwakilan pengguna dari organisasi yang telah diaudit, atau pihak ketiga.
8.2.5 organisasi yang telah diaudit
diaudit akan menyediakan sebuah organisasi penghubung bagi para audtior dan akan
menyediakan semua informasi yang diminta oleh para audtior. Bila telah selesai,
audit organisasi yang telah diaudit harus melaksanakan tindakan korektif dan re
komendasi.
32

masukan Input 8.3 Audit audit yang akan dicantumkan dalam rencana audit dan akan
meliputi yang berikut:
sebuah) dan cakupan tujuan mengaudit b) informasi latar belakang tentang organis
asi yang telah diaudit c) produk perangkat lunak atau proses yang akan diaudit d
) kriteria evaluasi, termasuk peraturan yang berlaku, standar-standar, panduan,
rencana-rencana, spesifikasi, dan prosedur yang akan digunakan untuk evaluasi
e) kriteria Dampak (misalnya, "diterima," "memerlukan perbaikan," "tidak dapat d
iterima," "tidak mendapat peringkat")
masukan untuk audit juga harus mencakup hal berikut ini:
f) Catatan audit sejenis sebelumnya
wab untuk produk perangkat lunak atau bila diminta proses oleh pemimpin audit.
8.4 Entri kriteria
Otorisasi 8.4.1
pemrakarsa yang memutuskan di atas perlu untuk audit. Keputusan ini mungkin akan
diminta oleh sebuah acara rutin, seperti ketibaan di sebuah proyek tonggak bers
ejarah, atau non-acara rutin, seperti kecurigaan atau penemuan nonconformance
utama.
Inisiator memilih sebuah organisasi audit yang dapat melakukan evaluasi independ
en. Inisiator menyediakan para audtior dengan informasi yang menentukan tujuan,
produk perangkat lunak audit atau proses yang akan diaudit, dan kriteria penilai
an. Inisiator harus meminta para audtior untuk membuat rekomendasi. Auditor yang
memimpin menghasilkan sebuah rencana audit, dan para audtior bersedia untuk aud
it.
Kebutuhan untuk audit yang dapat ditetapkan oleh satu atau lebih dari kejadian b
erikut ini: (
a) organisasi pemasok memutuskan untuk memverifikasi sesuai dengan peraturan yan
g berlaku, standar-standar, panduan, rencana-rencana, spesifikasi, dan prosedur
(keputusan ini mungkin telah dilakukan ketika merencanakan proyek).
b) pelanggan memutuskan untuk memastikan kepatuhan organisasi dengan peraturan-p
eraturan yang berlaku, standar-standar, panduan, rencana-rencana, spesifikasi, d
an prosedur.
c) pihak ketiga, seperti sebuah badan peraturan atau penilaian tubuh, memutuskan
di atas perlu audit, organisasi untuk memastikan kepatuhan pemasok dengan perat
uran-peraturan yang berlaku, standar-standar, panduan, rencana-rencana, spesifik
asi, dan prosedur.
Dalam setiap kasus, inisiator akan mengizinkan audit.
Prasyarat 8.4.2
audit akan dilakukan hanya bila semua kondisi berikut telah dipenuhi:
sebuah) di audit telah disahkan oleh otoritas yang sesuai.
b) sebuah pernyataan tujuan audit yang terbentuk.
c) audit yang diperlukan input sudah tersedia.
33
Prosedur 8,5
8.5.1
Manajer persiapan manajemen akan memastikan bahwa audit dilakukan sebagai diperl
ukan oleh standar yang berlaku dan prosedur dan persyaratan oleh diamanatkan ole
h hukum, kontrak, atau kebijakan lainnya. Untuk akhir ini, manajer akan melakuka
n yang berikut:
Sebuah Rencana) waktu dan sumber daya yang diperlukan untuk audit, termasuk fung
si dukungan, seperti yang diperlukan dalam IEEE Std 1058-1998 [B9], hukum atau p
eraturan atau dokumen, standar lainnya yang
ikan, menjalankan, dan mengelola audit-c) menyediakan pelatihan dan orientasi pa
da prosedur audit yang berlaku untuk proyek d) memastikan tingkat yang sesuai ke
ahlian dan pengetahuan yang cukup untuk memahami produk perangkat lunak yang dia
udit
e) memastikan bahwa audit direncanakan dilakukan f) UU rekomendasi tim audit sec
ara tepat waktu
Perencanaan 8.5.2 audit
, rencana audit akan menerangkan berikut:
sebuah) dan cakupan tujuan mengaudit b) Diaudit organisasi, termasuk manajemen d
an lokasi C) produk perangkat lunak harus diaudit d) kriteria evaluasi, termasuk
peraturan yang berlaku, standar-standar, panduan, rencana-rencana, spesifikasi,
dan prosedur yang akan digunakan untuk evaluasi
e), tanggung jawab Auditor f) kegiatan Pemeriksaan (misalnya, staf wawancara, me
mbaca dan mengevaluasi dokumen, mengamati menguji) g) kebutuhan sumber daya akti
vitas Audit h) jadwal kegiatan Audit saya) Persyaratan untuk kerahasiaan (misaln
ya, rahasia perusahaan, informasi dibatasi, informasi)
j) checklist penting k) format laporan l) distribusi laporan m) yang diperlukan
aktivitas tindak lanjut,
Di Mana digunakan, pengambilan sampel secara statistik metode pengambilan sampel
yang sah akan digunakan untuk menetapkan kriteria pemilihan dan ukuran contoh.
Rencana audit akan disetujui oleh inisiator. Rencana audit harus mengizinkan unt
uk perubahan berdasarkan informasi yang dikumpulkan selama proses audit, subjek
persetujuan oleh inisiator.
8.5.3 Membuka bertemu dengan orang
yang membuka pertemuan antara tim audit dan diaudit akan terjadi di organisasi p
ermulaan fasa pemeriksaan audit. Pembukaan agenda pertemuan akan meliputi yang b
erikut:
34
tujuan yang) dan Audit lingkup audit b) produk perangkat lunak atau proses yang
diaudit c) prosedur Audit output dan d) diharapkan dari sumbangan organisasi yan
g telah diaudit untuk audit (misalnya, banyak orang yang diwawancarai, fasilitas
meeting)
e) jadwal Audit f) akses ke informasi, fasilitas, dan dokumen yang diperlukan
Persiapan 8.5.4
inisiator akan memberitahu diaudit manajemen organisasi dalam menulis sebelum au
dit dilakukan, kecuali untuk audit tanpa pemberitahuan terlebih dahulu. Pemberit
ahuan yang akan menentukan tujuan dan lingkup audit, mengenali apa yang akan dia
udit, mengidentifikasi para audtior, dan mengenali jadwal audit. Tujuan adalah u
ntuk mengaktifkan pemberitahuan diaudit untuk memastikan bahwa organisasi rakyat
dan bahan yang akan diperiksa dalam audit yang tersedia.

Akan mempersiapkan untuk auditor mengaudit dengan mempelajari berikut:
sebuah) rencana Audit b) Diaudit c) Produk-produk organisasi atau proses yang ak
an diaudit d) peraturan yang berlaku, standar-standar, panduan, rencana-rencana,
spesifikasi, dan prosedur yang akan digunakan untuk evaluasi
e) kriteria Evaluasi
Selain, auditor memimpin akan membuat pengaturan yang diperlukan untuk hal-hal b
erikut:
f) orientasi Tim pelatihan dan g) Bahan-bahan, dokumen, dan peralatan yang diper
lukan oleh prosedur audit h) kegiatan Pemeriksaan
8.5.5
Pemeriksaan Pemeriksaan akan terdiri dari koleksi bukti dan analisis dengan rasa
hormat kepada kriteria audit, sebuah menutup pertemuan antara para audtior dan
organisasi yang telah diaudit, serta mempersiapkan laporan audit.
8.5.5.1 koleksi bukti para audtior kumpulkan bukti conformance dan non-test conf
ormance dengan mewawancarai diaudit staf organisasi, mempelajari dokumen, dan me
nyaksikan proses. Para audtior harus mencoba semua kegiatan penelitian didefinis
ikan dalam rencana audit. Mereka akan melakukan kegiatan investigasi tambahan ji
ka mereka menganggap kegiatan-kegiatan seperti yang diperlukan untuk menentukan
seberapa luasnya conformance atau non-test conformance.
Semua dokumen akan auditor pengamatan non-test conformance dan teladan conforman
ce. Pengamatan merupakan pernyataan yang dibuat pada kenyataannya selama audit y
ang valid oleh bukti tujuan. Contoh-contoh nonconformance adalah sebagai berik
ut:
peraturan yang berlaku, standar-standar, panduan, rencana-rencana, spesifikasi,
dan tidak digunakan pada semua prosedur peraturan yang berlaku, standar-standar,
panduan, rencana-rencana, spesifikasi, prosedur dan tidak digunakan dengan bena
r
35
harus dikategorikan sebagai pengamatan besar atau kecil. Pengamatan seharusnya d
igolongkan sebagai jika utama akan kemungkinan non-kepatuhan yang memiliki dampa
k yang berarti pada kualitas produk, biaya proyek, atau jadwal proyek.
Pengamatan utama sering disebut sebagai "penemuan-penemuan."
Semua pengamatan yang akan dapat diverifikasi oleh membahas mereka dengan organi
sasi yang telah diaudit sebelum menutup pertemuan audit.
8.5.5.2 menutup pertemuan
auditor yang memimpin akan pertermuan menutup pertemuan dengan diaudit manajemen
organisasi. Pertemuan penutupan harus tinjau ulang hal berikut ini:
sebuah) sejauh sebenarnya dari pelaksanaan rencana audit b) masalah yang dialami
dalam rencana pelaksanaan audit, jika ada c) pengamatan yang dibuat oleh para a
udtior d) kesimpulan awal para audtior e) auditor rekomendasi-rekomendasi awal f
) penilaian audit secara keseluruhan (misalnya, apakah diaudit berhasil lulus or
ganisasi kriteria audit)
Komentar dan isu-isu yang diangkat oleh organisasi yang telah diaudit harus dipe
cahkan. Perjanjian-perjanjian harus mencapai selama menutup pertemuan audit dan
harus selesai sebelum laporan audit ini difinalisasi.
8.5.5.3 melaporkan
memimpin akan mengolah auditor laporan audit, seperti yang dijelaskan dalam 8.7.
Laporan audit harus bersedia segera setelah audit. Komunikasi apa pun antara pa
ra auditor dan organisasi yang telah diaudit dibuat di antara menutup pertemuan
dan isu laporan harus melewati auditor memimpin.
Auditor yang memimpin akan mengirim laporan audit untuk inisiator dan ke diaudit
organisasi. Inisiator harus mendistribusikan laporan audit di dalam organisasiaudit.
8.5.6
Pemandangannya Tindak Lanjut, jika ada, akan menjadi tanggung jawab inisiator da
n organisasi-audit dan akan meliputi yang berikut:
sebuah) menentukan apa tindakan korektif diperlukan untuk menghapus atau mencega
h non-kepatuhan b) mengusulkan tindakan korektif
8,6 Keluar Dari
audit kriteria akan dianggap lengkap saat
sebuah) laporan audit telah diserahkan kepada inisiator.
b) Semua penemuan organisasi audit disertakan dalam lingkup audit yang dibuka at
au teratasi dan disetujui ditutup.
36
Output 8.7
output dari adalah laporan audit audit. Laporan audit akan berisi berikut:
sebuah) dan cakupan tujuan mengaudit b) Diaudit organisasi, termasuk Lokasi:, li
aison, manajemen dan staf c) Identifikasi produk perangkat lunak atau proses-pro
ses diaudit d) peraturan yang berlaku, standar-standar, panduan, rencana-rencana
, spesifikasi, dan prosedur yang digunakan untuk evaluasi
e) kriteria Evaluasi f) Ringkasan organisasi auditor g) Ringkasan Kegiatan pemer
iksaan h) Ringkasan rencana kegiatan pemeriksaan tidak dilakukan saya), yang dik
elaskan sebagai daftar pemerhatian (utama menemukan) atau minor j) Ringkasan dan
penafsiran temuan audit termasuk kunci barang-barang non-test conformance k) je
nis dan pewaktuan kegiatan tindak lanjut audit
Selain itu, ketika ditetapkan oleh rencana audit, rekomendasi akan diberikan kep
ada organisasi-audit atau inisiator. Rekomendasi akan dilaporkan secara terpisah
dari hasil.
Walaupun Standar ini mengatur persyaratan minimum untuk isi laporan, dibiarkan u
ntuk standar lokal untuk biasanya meresepkan konten tambahan, persyaratan format
laporan, dan media.
37
Annex A (sepaket Audit)
Perbandingan Tinjau
tabel tipe A.1 membandingkan lima jenis ulasan dalam beberapa karakteristik just
u berlawanan. Hal ini dimaksudkan untuk merupakan indikasi dari cara-cara jenis
peninjauan sama dengan atau berbeda dari satu sama lain.
Tabel A.1-Perbandingan Tipe peninjauan
Karakteristik Manajemen Inspeksi peninjauan Teknis Berjalan-melalui tujuan penin
jauan Audit memantau kemajuan, mengevaluasi Menemukan; Menemukan kelainan bawaan
, kelainan secara mandiri setel, konfirmasi, atau conformance verifikasi. Selidi
kilah resolusi mengevaluasi mengubah; untuk memverifikasi spesifikasi tujuan alt

ernatif produk; conformance mengubah rencana dan; menilai kualitas produk mening
katkan; dengan alokasi tujuan perubahan forum integritas untuk standar belajar s
umber daya dan keputusan peraturan- tim Manajemen Tim Kaji Ulang Tim setuju diau
dit membuat permintaan carta-carta tim memilih perubahan pada organisasi, tindak
an yang telah ditentukan sebelumnya untuk produk manajemen; dibuat, acquirer pem
rakarsa dorong, keputusan yang dibuat atau technical susunannya; oleh penulis pe
langgan, atau user pada rapat atau kelainan kepemimpinan harus sebagai hasil dar
i untuk uu akan dihapus rekomendasi-rekomendasi Mengubah Pemimpin memverifikasi
Pemimpin memverifikasi memverifikasi pemimpin pemimpin memverifikasi tanggung ja
wab yang item aksi verifikasi bahwa tindakan item yang item tindakan tindakan ya
ng diaudit tertutup yang item; perubahan ditutup; perubahan ditutup; perubahan d
itutup; mengubah verifikasi kiri verifikasi organisasi verifikasi kiri verifikas
i kiri ke kiri untuk proyek lainnya untuk proyek lainnya untuk proyek lainnya un
tuk kontrol proyek lainnya kontrol kontrol kontrol disarankan dua atau lebih tig
a atau lebih tiga hingga enam dua untuk tujuh Satu untuk lima group size orang o
rang orang orang orang Manajemen Grup, teman-teman sebaya Teknis bertemu dengan
Auditor Teknis; kehadiran kepemimpinan teknis dan mendokumentasikan kepemimpinan
dan diaudit kepemimpinan, dan campuran peer to peer mencampur, kehadiran; mungk
in organisasi didokumentasikan didokumentasikan didokumentasikan dapat dipanggil
hadir hadir hadir untuk memberikan Bukti Biasanya Grup biasanya memimpin Fasili
tator fasilitator terlatih atau memimpin kepemimpinan auditor bertanggung jawab
engineer penulis manager sedang hingga tinggi Volume, moderat, untuk tinggi, rel
atif rendah- relatif rendah, sedang atau tinggi material tergantung pada tergant
ung pada apapun yang tergantung pada pertemuan tertentu pertemuan tertentu diper
iksa dalam audit tertentu tujuan tujuan hari tunggal; tujuan besar volume telah
dibagi Presenter pemimpin peninjauan pemimpin peninjauan sebuah reader Auditor P
enulis mengumpulkan menentukan menentukan dan mengkaji presenter presenter infor
masi yang diberikan oleh organisasi yang telah diaudit
38
Tabel Audit A.1-Perbandingan Tipe peninjauan (sambungan)
Karakteristik Manajemen Inspeksi peninjauan Teknis Berjalan-melalui peninjauan A
udit
pengumpulan data yang diperlukan tidak diperlukan formal tidak disarankan secara
resmi oleh kebijakan proyek proyek yang berlaku, persyaratan persyaratan
standar., atau mungkin dilakukan rencana dapat dilakukan secara lokal. secara lo
kal.
Manajemen Output Anomali peninjauan teknis, daftar daftar Anomali, dokumentasi p
eninjauan audit Formal, anomali item tindakan, dokumentasi;; termasuk laporan ri
ngkasan, keputusan-keputusan, observasi, termasuk spesifikasi yang inspeksi pene
muan tindak lanjut, tindakan spesifikasi, dengan proposal dokumentasi item tinda
kan kekurangan, dengan tanggungjawab-tanggungjawab item dan tanggal untuk dan ta
nggal untuk resolusi resolusi Ya, biasanya Formal Ya, biasanya Ya, untuk semua Y
a, biasanya Ya (fasilitator formal terbatas pada terbatas pada peserta terbatas
pada pelatihan audit) pelatihan meninjau pemimpin peninjauan pemimpin berjalan-m
elalui pemimpin didefinisikan Ya Ya Ya Ya Ya peran peserta penggunaan anomali Op
sional biasanya tidak Opsional Ya Opsional checklist penting Tidak Yes apabila M
anajemen Tidak Ada; namun tidak ikut bukti manajemen manajemen atau mungkin yang
disebut mungkin di atas untuk memberikan resolusi Diperlukan bukti Opsional Ops
ional Pelanggan Tidak Opsional, namun opsional atau pelanggan pengguna atau perw
akilan perwakilan pengguna berpartisipasi mungkin diminta untuk memberikan bukti

39
Lampiran B
(informatif) Bibliografi
[B1] IEEE 100 TM, Kamus Pembimbing IEEE Ketentuan Standar, Edisi Ketujuh. New Yo
rk:
6, Institute of Electrical and Electronics Engineers, Inc. 7
[B2] IEEE Std 2002 sebesar 730TM, Standard IEEE untuk rencana jaminan Kualitas P
erangkat Lunak.
[B3] IEEE Std 828TM-2005, Standard IEEE Untuk Konfigurasi Perangkat Lunak Rencan
a Manajemen.
[B4] IEEE Std 829TM-2008, Standard IEEE untuk Dokumentasi Tes Perangkat Lunak.
[B5] IEEE Std 830TM 1998, IEEE disarankan untuk spesifikasi persyaratan perangka
t lunak praktik.
[B6] IEEE Std 1012TM-2004, Standard IEEE untuk Verifikasi Perangkat Lunak dan va
lidasi.
[B7] IEEE Std 1998, IEEE 1016TM amalan yang disarankan untuk keterangan Desain P
erangkat Lunak.
[B8] IEEE Std 1044TM tahun 1993, Standard IEEE klasifikasi bagi Kelainan Perangk
at Lunak.
[B9] IEEE Std 1058TM 1998, Standard IEEE untuk Rencana Manajemen Proyek Perangka
t Lunak.
[B10] IEEE Std 1063TM-2001, Standard IEEE untuk Dokumentasi Pengguna Perangkat L
unak.
[B11] IEEE Std 1074TM-2006, Standard IEEE untuk mengembangkan sebuah proses Sikl
us Hidup Perangkat Lunak.
[B12] IEEE Std 1220TM-2005, Standard IEEE untuk aplikasi dan sistem manajemen pr
oses Teknik.
[B13.] IEEE Std 1228TM-1994, Standard IEEE untuk Rencana Keselamatan Perangkat L
unak.
[B14] IEEE Std 1471TM-2000 Sistem, dan Software Engineering-amalan yang disarank
an untuk keterangan tentang Sistem Software-Intensive Arsitektur.
[B15] IEEE Std 12207 8 TM-2008, Sistem dan teknik perangkat lunak perangkat luna
k-proses siklus hidup.
[B16] IEEE Std 14764TM-2006, standar untuk Software Engineering-Proses Siklus Hi
dup Perangkat Lunak- Perawatan.
[B17] 9 ISO 9001:2000, sistem manajemen kualitas persyaratan-.
[B18] ISO 19011:2002, Panduan untuk kualitas dan/atau sistem manajemen lingkunga
n audit.
[B19] ISO 90003:2004/IEC, Software engineering-pedoman untuk penerapan ISO 9001:
2000 untuk perangkat lunak komputer.
6 IEEE publikasi ini tersedia dari Institute of Electrical and Electronics Engin
eers, 445 Cangkul Lane, Piscataway, 08854, Amerika Serikat (kereta NJ http://sta
ndards.ieee.org/).
7 standar IEEE produk atau dirujuk dalam klausa ini adalah merek dagang dari Ins
titute of Electrical and Electronics Engineers, Inc.
8 IEEE Std 12207-2008 juga dikenal sebagai ISO/IEC 12207:2008.
9 ISO publikasi ini tersedia dari ISO Secretaria Tengah t, Postale Kasus 56, 1 r
ue de Varemb, CH-1211, Genve 20, Switzerland/Suisse (http://www.iso.ch/). ISO publ

ikasi ini juga tersedia di Amerika Serikat dari Departemen Penjualan, American N
ational Standards Institute, 25 Barat jalan ke-43, Lantai 4, New York, NY 10036,
Amerika Serikat (http://www.ansi.org/).
40

1028 2008

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

1028 2008

Diunggah oleh

Hak Cipta:

Format Tersedia

Standard IEEE untuk Tinjauan Perangkat Lunak dan

Masyarakat Komputer IEEE Audit yang

Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polcia Nacional

IEEE Std 1028TM-2008

berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polcia Nacional

Institute of Electrical and Electronics Engineers, Inc.

i oleh Institute of Electrical and Electronics Engineers, Dimasukkan.

mungkin muncul mengenai maksud b

dapat dijalankan dengan menggunakan

setujui, Kelompok Kerja Kajian Perangkat Lunak telah keanggotaan berikut:

Malia Zaman Standar IEEE, Manajer Program Program Teknis Development

7,4 Entri kriteria..............................................................

Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polcia Nacional

Standard IEEE untuk Tinjauan Perangkat Lunak Audit dan

, perbaikan, dan proses infrastruktur

edang berlangsung e) kelainan saat ini atau daftar masalah f) Didokumentasikan p

5.1 Pengenalan Teknik ulasan

is untuk tujuan mengidentifikasi masalah yang memerlukan resolusi manajemen.

ng secara tepat waktu

engolahan dan catat total dalam dokumentasi inspeksi.

c) Reinspect pemandangannya. Produk Perangkat Lunak tidak dapat diterima. Kelain

aran-saran perbaikan, atau pendekatan alternatif.

berjalan-pemimpin melalui akan bertanggung jawab untuk kegiatan berikut:

produk, menggambarkan setiap bagiannya.

Hak Cipta 2008 IEEE. Semua hak dilindungi undang-undang.

dan bahan yang akan diperiksa dalam audit yang tersedia.

kilah resolusi mengevaluasi mengubah; untuk memverifikasi spesifikasi tujuan alt

akilan perwakilan pengguna berpartisipasi mungkin diminta untuk memberikan bukti

ue de Varemb, CH-1211, Genve 20, Switzerland/Suisse (http://www.iso.ch/). ISO publ

Anda mungkin juga menyukai