1028 2008 [PDF]

Citation preview

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 Polícia 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 Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor 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 Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



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. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



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. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



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. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor



e. Pembatasan-pembatasan berlaku.



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. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



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. Hak cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak Audit dan 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak dan 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. Hak cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak Audit dan 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. Hak cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak dan 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Kaji Ulang dan perangkat lunak Perekam 5.2.3 Audit perekam yang akan kelainan dokumen, item tindakan, keputusan-keputusan, dan reko 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak Audit dan 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 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 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak dan 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak Audit dan 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor



e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak Audit dan 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak dan 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak Audit dan 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak Audit dan 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak dan 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak dan 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



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 ti, ini adalah ke kiri untuk prosedur lokal untuk biasanya meresepkan konten tam bahan, persyaratan format, dan media. 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak dan 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak dan 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak dan 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



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 bahan referensi tambahan mungkin disediakan oleh orang-orang yang bertanggung ja 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 b) Menyediakan dana dan fasilitas yang diperlukan untuk merencanakan, mendefinis 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak Audit dan 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



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 ti, ini adalah ke kiri untuk prosedur lokal untuk biasanya meresepkan konten tam bahan, persyaratan format, dan media. 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak dan 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak dan 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak Audit dan 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 perekam yang akan kelainan dokumen, item tindakan, keputusan-keputusan, dan reko 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



Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak dan 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 bahan referensi tambahan mungkin disediakan oleh orang-orang yang bertanggung ja 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 non- conformance 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak Audit dan 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 b) Menyediakan dana dan fasilitas yang diperlukan untuk merencanakan, mendefinis 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak dan 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 non- conformance 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak Audit dan 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak Audit dan 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak dan 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak dan 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.



IEEE Std 1028-2008 Standard IEEE untuk Tinjauan Perangkat Lunak Audit dan 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, Genève 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 Hak Cipta © 2008 IEEE. Semua hak dilindungi undang-undang. Berlisensi yang diizinkan menggunakan terbatas pada: Universidad Polícia Nacional de Kolombia. Download pada bulan Maret 10,2012 pada 00:17:57 UTC dari IEEE Xplor e. Pembatasan-pembatasan berlaku.