PROSES TESTING

PROSES TESTING

oleh: Tumar

Proses testing proyek pengembangan piranti lunak adalah siap untuk dilaksanakan. Termasuk kegiatan rencana tes dan tes implementasi program. Maksud dari rencana aktivitas tes adalah untuk menentukan cara yang resmi didemonstrasikannya piranti lunak komputer sampai memuaskan hasilnya berdasarkan perjanjian dan menurut kinerjanya Persyaratan Spesifikasi Piranti Lunak telah disetujui. Aktivitas ini adalah bagian dari rancangan, tapi dilakukan bersamaan dengan aktivitas rancangan pendahuluan dan sangat bergantung pada rancangannya. Elemen yang esensial pada rencana tes adalah difinisi pada awal tes itu harus sukses dilaksanakan untuk penerimaan produk piranti lunak – produk diterima pada tes akhir. Tes ini dan persyaratan penerimaan yang lain akan didifinisikan dan yang telah disetujui sampai dengan awal pelanggan ( prioritas untuk PDR jika mungkin, tentu saja prioritas untuk CDR).
Perencanaan dan prosedur untuk testing / uji coba adalah pada awal tulisan dalam siklus pengembangan dan dibawa selama implementasi. Suatu tes / uji coba mempunyai tiga tujuan utama yaitu :
1. Verifikasi produk kinerja piranti lunak seperti yang ditentukan dalam dokumentasi rancangan.
2. Verifikasi produk kinerja piranti lunak yang memuaskan seluruh persyaratan yang ditentukan dalam Spesifikasi Persyaratan Piranti Lunak, dan
3. Asalkan Manajemen Proyek dengan status laporan proyek kecermatan implementasi piranti lunak.

Proses tes konsisten pada dua tahap tes dan empat tingkatan tes yaitu :

1. Tes / uji coba Pengembangan
   a. Program Unit Tes
   b. Modul Tes Integrasi,
2. Tes Validasi
   a. Verifikasi Tes,
   b. Tes diterima,

Tes Pengembangan pada program komputer adalah didifinisikan yang prosesnya interaktiv ditentukan apakah setiap langkah pada suatu Jenis Konfigurasi Program Komputer (a Computer Program Cunfiguration Item / CPCI) penyelesaian proses pengembangan seluruhnya pada persyaratan menurut langkah sebelumnya. Kinerja piranti lunak didemonstrasikan seperti yang ditetapkan dalam dokumentasi rancangan dan kinerjanya proses implementasi adalah cermat. Aktivitas tes pengembangan terutama adalah kontrol oleh organisasi pengembangan piranti lunak.

Definisi validasi adalah evaluasi, intergrasi dan aktivitas tes mengangkat keluar tingkat sub sistem piranti lunak hingga memastikan pengembangan piranti lunak itu memuaskan persyaratan kinerjanya dan kriteria rancangannya memuaskan dalam Persyaratan Spesifikasi Piranti Lunak. Validasi piranti lunak terutama adalah kontrolnya oleh organisasi penjamin kualitas. Catatan tes itu dukungan organisasi tersendiri, di bawah pengawasan proyek, utilitas boleh untuk validasi tes yang telah didiskusikan dalam modul 4. Pada modul ini, bagaimanapun, fungsinya kami terima adalah kinerjanya leh organisasi penjamin kualitas.
Hasil tes/uji coba adalah dgunakan sebagai laporan selama kejadian penting pada implementasi piranti lunak. Kejadian penting adalah mudah didifinisikan oleh kesuksesan yang lengkap sebuah definisi tes dan secara lengkap didokumentasikan dalam laporan hasil tes / uji coba.
Proses tes / uji coba, kumpulan dokumentasi, dan tinjauan program formal adalah digambarkan dalam bagian yang berturut-turut.


8.1 PROSES TES

Proses tes / uji coba adalah kinerja menjelaskan tahap pengembangan piranti lunak dan konsisten terhadap tiga (3) dasar aktivitas antara lain :

1. generasi rencana tes secara rinci dan prosedurnya,
2. kinerja pada aktivitas tes/uji coba, termasuk resolusinya dan tes ulang pada kekurangan piranti lunak, dan
3. dokumentasi hasil tes / uji coba untuk mengikuti jejak laporan.

Gambar 8.1 diilustrasikan waktu yang relativ pada tiga aktivitas ini dalam tahap proyek, produk dokumentasi, dan tinjauan persyaratan sampai pada verifikasi hasilnya proses tes / uji coba.
Rencana Tes / Uji Coba digambarkan lengkap program tes / uji coba piranti lunak dan basis dalam Persyaratan Spesifikasi Piranti Lunak. Ini adalah disampaikan dalam format pendahuluan dan tinjauan pada PDR . Selama Tahap Rancangan Rinci, komentar dari PDR dalam rencana

Tes Pendahuluan adalah yang tergabung kedalam Rencana Tes / Uji Coba, dan tambahan rinci mengenai konfigurasi tes uji coba, piranti lunak tes / uji coba dan tes/uji coba khusus adalah pengembangan dan tergabung kedalam dokumen. Rencana Tes / Uji Coba disampaikan dalam format akhir pada CDR. Setelah CDR Rencana Tes / Uji Coba di bawah konfigurasi formal kontrol dirubah. Pada basis Rencana Tes dan Dokumen Rancangan Rinci, Prosedur Tes Pendahuluan adalah tertulis dan ditinjau pada Tinjauan Prosedur Tes ( The Test Prosedure Review/ TPR). Prosedur Tes / Uji Coba adalah diperbarui dalam basis TPR dan disampaikan dalam format akhir lebih dulu sampai tes/ uji coba formal. Selama proses tes / uji coba, Prosedur Tes / Uji Coba adalah di bawah kontrol konfigurasi, tapi dapat dimodifikasi jika berdasarkan ketidak tepatan. Laporan Tes / Uji Coba adalah turunan selama proses tes / uji coba dan tinjauan pada Penyerahan Tinjauan Piranti Lunak (Software Acceptance Review/ SAR).
Multi organisasi adalah termasuk di dalam proses tes/ uji coba, keduanya dalam grup yang memproduksi piranti lunak yang dihasilkan dan digunakannya. Yang berikutnya dalam diskusi, organisasi pemakai bertanggung jawab untuk diterimanya produk akhir piranti lunak akan sebagai referensi pemakai. Organisasi ini biasanya konsisten pada keduanya personil penjaminan kualitas dan aktual sistem mudah digunakan.

Sebagaian besar berpengaruh pada organisasi dalam proses tes/uji coba adalah organisasi penjamin kualitas untuk grup produksi piranti lunak. Sejumlah metoda verifikasi dikerjakan itu untuk menguji organisasi. Pilihan di mana metoda verifikasi pada penggunaannya akan tergantung pada kebutuhan itu yang dibuktikan dan tingkatan pengujian dilakukan. Uji organisasi, dengan metoda verifikasi, dan bagian tingkatan test yang diuraikan sebagai berikut :

8.1.1 Jaminan Kualitas (Quality Assurance-QA)
Dalam rangka memaksimalkan efektivitas penjaminan kualitas (QA) program, personil QA harus tidak terikat pada organisasi yang bertanggung jawab untuk pengembangan produk. Ini dapat terpenuhi dengan penetapan organisasi QA itu yang secara langsung di bawah pengendalian manajemen perusahaan, bukannya di bawah manajemen proyek piranti lunak. Bagian yang berikut menguraikan suatu program jaminan mutu dan suatu alternatif ke QA formal.

Tanggung Jawab Penjamin Kualitas dan Otoritas (Quality Assurance Responsibility and Authority)
Mutu Tanggung jawab Penjaminan Dan Otoritas. Organisasi QA dilibatkan dalam semua tahap pengembangan program, dari persiapan proposal sampai penyerahan dan penerimaan akhir. Otoritas Dan Tanggung jawab yang spesifiknya diringkas gambar 8.2. Kemerdekaan QA yang organisatoris meyakinkan bahwa pengecekkan dan keseimbangan yang penting bagi suatu QA program sukses yang tidak bisa dipisahkan di dalam struktur manajemen. Karena tanggung jawab yang terakhir untuk produk yang disampaikan pada umumnya terletak di tangan organisasi pengembangan itu, QA yang mandiri menyediakan suatu saluran laporan terpisah untuk monitoring kemajuan pengembangan. Organisasi QA mempunyai otoritas untuk menerima atau menolak semua produk bisa disampaikan, seperti halnya untuk melakukan audit yang sedang dikerjakan dan tinjauan ulang. Dalam hal konflik antara QA dan organisasi pengembang, resolusi harus terpenuhi di tingkatan manajemen perusahaan.

Penjamin Kualitas Piranti lunak (Software Quality Assurance)
Mutu hanya dapat dibangun ke dalam piranti lunak oleh para programmer dan para perancangnya, tetapi tinjauan ulang mandiri dapat berperan untuk mutu piranti lunak dengan menemukan dan melaporkan permasalahan, atau permasalahan potensial, dan dengan berikut yang berdasar pada resolusi. Seperti permasalahan. Dengan penggunaan teknik pemrograman yang modern dan mencakup personil QA di dalam tinjauan ulang teknis sering, kesalahan dapat terbongkar lebih awal dan yang dikoreksi sebelum efek air terjun kecil mereka sampai pada sistem. Sepert yang dibahas pada bab 9, manajemen konfigurasi piranti lunak di dalam memelihara melalui suatu Perpustakaan Program Komputer (CPL). Piranti lunak personil penjamin kualitas menggunakan CPL itu yang melaporkan prosedur permasalahan dokumen piranti lunak dan perubahan jejak untuk mengoreksi kesalahan. Piranti lunak Grup QA adalah bertanggung jawab untuk:

1. Melihara Pengendalian yang tegas atas spesifikasi, dokumentasi disain, kode piranti lunak, dan konfigurasi test untuk meyakinkan capaian dan persyaratan disain yang disatukan dan kemampuan jejak persyaratan itu ke spesifikasi tingkat yang lebih tinggi didokumentasikan.
2. Tinjauan ulang disain piranti lunak sebelum coding.
3. Ambil bagian audit dan tinjauan ulang teknis disain dan aktivitas pengembangan.
4. Melaksanakan tinjauan ulang untuk memastikan kesetiaan ke standard dan prosedur piranti lunak.
5. Melaporkan permasalahan piranti lunak dan pertentangan dan monitoring tindakan korektif.
6. Tinjauan ulang dan rencana test kecakapan yang disetujui dan memeriksa prosedur.
7. Melakukan monitoring test untuk memastikan bahwa prosedur diikuti dan semua ukuran-ukuran sukses dicukupi.

Piranti lunak QA Test Tinjauan ulang memeriksa prosedur untuk memastikan bahwa mereka adalah konsisten dengan rencana pengujian piranti lunak dan arus dokumentasi, yang mereka uji itu semua kebutuhan, dan bahwa mereka berisi ukuran-ukuran penerimaan dan cukup sukses. Kecakapan menguji piranti lunak mendorong ke arah penerimaan program yang dimonitor oleh piranti lunak QA untuk memastikan bahwa:

1. Uji prosedur disetujui sebelum start pengujian.
2. Uji perangkat keras dan lunak adalah dikendalikan dan bisa diterima.
3. Semua test yang diselenggarakan sesuai dengan prosedur pemeriksaan dan memenuhi test.
4. Semua piranti lunak dan definisi test yang ditemukan dalam pengujian direkam.
5. Semua koreksi piranti lunak ddikoreksi kembali.
6. Semua data test direkam dan yang mencerminkan penemuan nyata perjanjian
7. Semua dokumentasi test dirawat untuk mengijinkan pengulangan kemampuan test itu.
8. Status uji laporan dirawat dengan teliti.
9. Uji laporan yang mencerminkan persyaratan perjanjian
10. Semua dokumentasi disain diperbaharui untuk mencerminkan perubahan buat yang menguji.
11. Semua pengujian adalah lengkap, permasalahan dipecahkan, dan piranti lunak adalah bisa diterima untuk tahap yang berikutnya menguji atau untuk penyerahan.

Di dalam melakukan dari tiap test, pengukuran, pengamatan, dan keluaran untuk prosedur test yang direkam dan dibuktikan oleh QA. Laporan Test ditinjau dan bersertifikat oleh QA untuk memastikan korelasi antara sasaran hasil test dan hasil. Piranti lunak QA meninjau ulang dokumentasi piranti lunak yang berikut dengan konsistensi, kelengkapan, pemenuhan dengan standard, dan informasi perubahan perusahaan :

1. Merancang Rencana
2. Spesifikasi Kebutuhan piranti lunak.
3. Menghubungkan Spesifikasi
4. Dokumen Rancangan Fungsional
5. Pengujian rencana
6. Pengujian prosedur
7. Pengujianlaporan
8. Dokumen Rancangan Rinci
9. Dokumen Instruksi Operasi
10. Dokumen Uraian Versi

Semua program komputer bisa menyampaikan oleh perangkat lunak QA yang bersertifikat. Sertifikasi ini dibuat sebelum diedarkan kepada pemakai itu. Perangkat lunak CPCI secara formal bersertifikat ketika kondisi-kondisi yang berikut ini dicukupi:

1. Semua dokumen relevan dan pekerjaan yang digambarkan adalah lengkap, sekarang, dan di bawah pengendalian perubahan.
2. Tembusan arsip QA dikendalikan menurut format prosedur yang telah mapan.
3. Semua pengujian kecakapan diselesaikan, dokumentasi test diperbaharui dan dilepaskan ketika diperlukan.
4. Semua laporan masalah piranti lunak telah tertutup.

Alternatif ke QA formal

Proyek lebih kecil, dengan suatu staff piranti lunak kurang dari appromimately 20 orang-orang, dapat dengan sukses diatur tanpa jaminan mutu formal, seperti yang telah diuraikan di atas. Suatu penyelamatan biaya substansiil adalah mungkin dengan memodifikasi prosedur QA yang formal seperti yang diuraikan sebagai berikut:

1. Manager proyek, bukannya suatu QA organisasi QA yang mandiri, memberi hak penyerahan dokumen dan piranti lunak.
2. Tidak ada tinjauan ulang mandiri atau monitoring kemajuan teknis pekerjaan.
3. Tidak ada jejak audit QA yang diproduksi.
4. Tinjauan ulang material terpenuhi melalui pengamatan tinjauan ulang dan tinjauan ulang manajemen proyek.

8.1.2 Metoda Verifikasi (Verification Method)

Verifikasi harus dilakukan untuk semua kebutuhan subsistem perangkat lunak oleh penggunaan satu atau lebih metoda yang diperkenalkan di bawah:

1. Inspection. Metoda ini digunakan untuk memverifikasi bahwa piranti lunak menemukan kebutuhan yang tidak bisa dipertunjukkan melalui pengujian operasional. Itu meliputi pengujian hirarki piranti lunak dan diagram alir fungsional, program yang terdaftar, Bahasa Disain Program (Program Design Language (PDL)), dan berhubungan uraian naratif. Kebutuhan ini meliputi format perangkat keras dan piranti lunak dan kesetiaan bagi pemmrogram dan standard disain.
2. Comparison. Metoda ini membandingkan pelaksanaan unsur piranti lunak yang baru dengan suatu program baku yang dikenal, diikuti oleh hasil analisa.
3. Analysis. Metoda ini meliputi suatu analisa keluaran program untuk mengevaluasi capaian algoritma pada berbagai langkah-langkah proses. Itu digunakan untuk mengesahkan logika dan apa yang dihasilkan persamaan yang kompleks tidaklah secara langsung dihubungkan dengan masukan. Analisa terdiri dari perhitungan yang mandiri dari hasil yang diharapkan dan membandingkannya hasil ini dengan hasil program yang sebenarnya.
4. Prior Kecakapan. Metoda ini didasarkan pada suatu demonstrasi bahwa unsur-unsur CPCI sudah lulus lewat kecakapan di dalam sistem lain pemakai.
5. Demonstration. Metoda ini meliputi pengamatan atas capaian sistem di dalam suatu lingkungan yang dikendalikan. Itu menyediakan verifikasi dalam real-time dari fungsi yang terpisah, seperti memasang cahaya atau mulai, membunyikan alarm, warna display yang bervariasi, dan seterusnya.
6. Usage. Metoda ini melibatkan pelaksanaan yang diulangi bersama piranti lunak dengan satu atau lebih metoda uraikan di atas.
7. Test. Metoda ini terpenuhi dengan pelaksanaan satu rangkaian test dengan masukan yang dikenal perlu menghasilkan keluaran dikenal. Hasil percobaan harus mampu untuk menyelesaikan pengujian setelah test.

8.1.3 Menguji Tingkatan (Test Levels)

Pengujian Unit Program dilakukan oleh programmer dan adalah yang diharapkan untuk memverifikasi unit program yang dilaksanakan tunggal itu menurut rancanngan yang diharapkannya. Pengujian pengintegrasian modul dilakukan oleh pengembang organisasi dan dimaksudkan untuk memverifikasi unit program yang individu itu menghubungkan satu sama lain dengan tepat dan bahwa, sebagai kelompok, mereka melaksanakan fungsi yang menggambarkan dokumentasi disain. Pengujian Verifikasi dilakukan oleh organisasi penjamin kualitas dan yang diharapkannya untuk memverifikasi bahwa "as-built" sistem yang dibuat memuaskan kebutuhan seperti yang ditetapkan dalam dokumentasi kebutuhan, Tiga tingkatan ini dilakukan di lokasi pengembangan, yang sering berbeda dengan lokasi operasional itu.

Pengujian Penerimaan dilakukan di lingkungan operasional pemakai, sebagai usaha yang dihubungkan antara organisasi penjamin kualitas dan pemakai, dan yang dimaksudkan untuk menyediakan jaminan yang akhir pemakai itu dengan yang sistemnya dilaksanakan seperti yang ditetapkan dalam lingkungan yang diharapkan. gambar 8.3 menguraikan yang empat tingkatan test piranti lunak yang dibahas pada paragraph yang berikut.

Unit Program Pengujian (Program Unit Testing)
Tujuan Pengujian Unit Program adalah untuk memverifikasi bahwa "as-built" unit program yang dilaksanakan seperti yang ditetapkan pada Dokumentasi Rancangan rinci. Suatu unit yang digambarkan sebagai program komputer tunggal yang dapat diuraikan dalam kaitannya dengan masukan, proses, dan keluaran. Sebagai contoh, di dalam unit Fortran akan sesuai dengan suatu program utama atau suatu subroutine. Test formal merencanakan, memeriksa prosedur, dan menghasilkan untuk Pengujian Unit Program yang tidak dihasilkan kecuali jika test unit memverifikasi bahwa piranti lunak tidak menemukan suatu kebutuhan yang kemudian membuktikan dalam program test.

Test informal merencanakan, memeriksa prosedur, dan hasil dihasilkan oleh programmer ketika perancangan dan coding unit program adalah yang didokumentasikan sesuaian dengan pola unit Pengembangan. Masukan yang utama kepada rencana test dan prosedur adalah Dokumen Rancangan Rinci. Pengujian Unit Program dilakukan secara terpisah dari uji coba unit lain dan terdiri dari dua tahap. Tahap yang pertama melibatkan penyusunan unit itu dan ia mengoreksi kesalahan yang ditandai oleh compiler itu.

Ini menggunakan yang meliputi penggunaan compiler lain yang membantu, seperti daftar referensi silang, untuk memverifikasi bahwa tidak ada definisi variabel kesalahan telah dibuat. Tahap yang kedua dimaksudkan untuk menemukan apapun kesalahan logika di dalam unit itu. Tujuannya adalah untuk memverifikasi bahwa masing-masing cabang program, masing-masing persamaan, dan arus logika dengan baik dieksekusi. Pengujian dilanjutkan sampai semua mengetahui kesalahan telah dihapus dan logika unit program yang disainnya kode matematika.Rancangan tak efisien mempengaruhi dokumentasi yang disampaikan harus ditangani sesuai standar jaminan kualitas yang digambarkan. Secara umum, rancangan yang tak efisien tidak mempengaruhi fungsi selain dari yang ada dalam sistem piranti lunak kodenya dikoreksi, dan perubahannya adalah " red-lined" di dalam suatu salinan Bagian Dokumen Rancangan Rinci yang sesuai, yang mana adalah Folder Pengembangan Unit terpelihara. Ketika kekurangan rancangan yang mempengaruhi antarmuka dengan lain organisasi atau memerlukan suatu spesifikasi perubahan, proses perubahan yang formal dimulai dengan seketika.

Walaupun pengujian adalah informal yaitu, diselenggarakan tanpa prosedur tertulis formal, ini merupakan suatu aktivitas yang direncanakan. Perencanaan adalah yang penting bagi penggunaan komputer yang efisien dan waktu programmer itu. Perencanaan yang diperlukan meliputi penjelasan apa yang programmer berniat untuk memenuhi test yang ditentukan, masukan apa yang diperlukan, keluaran apa yang diharapkan, dan bagaimana test akan jadi diselenggarakan. Program-mer perlu mempersiapkan daftar test untuk dilaksanakan untuk unit masing-masing dan memelihara daftar ini di dalam folder. Test Unit Program diselesaikan sebagai berikut:

1. ketika programmer telah menyelesaikan program test yang direncanakannya dan dicukupi kode yang memenuhi disain itu,
2. ketika semua mengetahui kesalahan telah dihapuskan, dan
3. ketika kode telah ditinjau oleh suatu tim tinjauan ulang melalui kode yang sedang berjalan.

Tinjauan ulang Tim dapat terdiri dari satu atau banyak penulis resensi buku, dengan beberapa di antara mereka terutama lebih disukai dari tim pengembangan. Terkecuali menemukan finding bug. Di dalam kode, tinjauan ulang mempunyai keuntungan tambahan yang menyediakan para programmer lain dengan pengetahuan cukup untuk mengambil alih lebih lanjut uji coba modul jika siapa programmer yang menulis program itu adalah memberikan beberapa alasan dari sesuatu yang tersedia. Suatu daftar nama untuk mengkonfirmasikan bahwa Pengujian Unit Program adalah lengkap meliputi yang berikut:

1. Masing-Masing persamaan telah diuji menggunakan semua parameter yang bisa diterapkan dengan nilai nominal, nilai di batas yang ditetapkan, dan nilai di luar batas itu di mana jika sesuai. Persamaan ini perlu meliputi persamaan pengulangan yang dikendalikan.
2. Tiap-Tiap program cabang telah dieksekusi.
3. Semua mengetahui persandian dan kesalahan disain telah dikoreksi.
4. Semua test yang sukses telah direkam di dalam folder Pengembangan Unit.
5. Hasil percobaan dari test sukses telah diselamatkan.
6. Semua pekerjaan tulis menulis untuk perubahan disain telah diaktipkan.

Sekali ketika Pengujian Unit Program diselesaikan, programmer mengisi suatu Format Pengiriman Perpustakaan Program Komputer (Computer Program Library Transmittal Form (CTF)) dan menyampaikan CTF itu dan kode kepada pustakawan program komputer (lihat bab 9). Unit kemudian adalah mengkombinasikan dengan Pengintegrasian Modul dan unit terkait yang mulai menguji.

Menguji Pengintegrasian Modul (Module Integration Testing)
Menguji Pengintegrasian Modul yang konsis diri dari membangun keseluruhan subsistem perangkat lunak dengan menambahkan pengulangan-pengulangan unit program, kemudian ketika unit program terintegrasi, pengujian untuk memastikan bahwa subsistem piranti lunak yang diterapkan memenuhi satu yang diuraikan dokumentasi disain. ( Pengintegrasian Modul Pengujian adalah juga dikenal sebagai Modul yang diuji, Menguji Pengintegrasian atau Kualifikasi Uji Pendahuluan). Jika perangkat lunak yang penggunaannya diterapkan adalah suatu pendekatan top-down, Menguji Pengintegrasian Modul yang terdiri dari mengintegrasikan unit program yang tertinggi yang pertama dan penggunaan modul yang diuji sebagai bingkai yang bekerja untuk menguji masing-masing unit program secara berurutan.
Menguji Pengintegrasian Modul yang digunakannya adalah suatu building-block yang mengintegrasikan mendekati dan membangun program komputer itu dan, jika bisa diterapkan, subsistem piranti lunak. Modul yang hirarkinya tertinggi yang dulu subsistem piranti lunaknya terintegrasi. Pengintegrasian maju langkah demi langkah menurut suatu jadual berdasarkan pada fungsi itu untuk dilakukan oleh modul, inter ketergantungan mereka, ketersediaan mereka, dan data antarmuka masukan. Potongan yang digantikan untuk rutin tingkat bawah untuk mengisolasikan fungsi itu di bawah Potongan perjanjian uang digantikan langkah demi langkah oleh modul yang nyata sampai subsistem perangkat lunak adalah lengkap. Suatu keuntungan yang utama top-down pengintegrasian dan menguji pendekatan adalah bahwa alat penghubung subsistem yang utama digambarkan pada suatu tingkat tinggi hirarki, dan kemudian dibuktikan pada awal proyek itu. Sekali ketika alat penghubung dibuktikan, implementasinya dan diuji coba subsistem yang berbeda bisa dilakukan dengan bebas. Tujuan Pengujian Pengintegrasian Modul adalah untuk memverifikasi bahwa:

1. Unit Program yang individu menghubungkan satu sama lain dengan tepat untuk membentuk modul itu yang diuraikan dalam Dokumen Disain Rinci.
2. Modul telah menjadi dengan baik coded, sedemikian sehingga semua persamaan berfungsi dengan baik dan semua alur logika beroperasi seperti yang dirancang.
3. Modul menghubungkan satu sama lain untuk membentuk subsistem perangkat lunak itu yang diuraikan dalam Dokumen Disain Rinci.
4. Ada suatu kemajuan rapi ke arah kemampuan piranti lunak yang akhirnya akan jadi dibuktikan menguji Verifikasi.

Prosedur Test formal disiapkan bersama-sama oleh pengembangan software dan perusahaan penjaminan kualitas piranti lunak dan didokumentasikan, ditinjau, dan disetujui. Perusahaan penjaminan kualitas piranti lunak perlu melaksanakan suatu tinjauan ulang prosedur sebelum penggunaan mereka oleh organisasi pengembangan software. QA piranti lunak perlu memastikan bahwa semua test yang diselenggarakan sesuai dengan prosedur yang terpenuhi didokumentasikan. Apapun penyimpangan harus didokumentasikan.

Test Pengintegrasian Modul diselenggarakan menggunakan data masukan dinamis dan yang statis diperlukan untuk melaksanakan inter modul dan eksekutip yang menghubungkan dan untuk berlatih fungsi operasional. Itu adalah yang diinginkan untuk mempunyai akses pada kenyataan atau pengolah target selama Pengujian Pengintegrasian Modul. Dalam posisi ini, sistem operasi harus secara penuh mampu untuk mendukung test ini. Di mana jika Sistem Pengintegrasian Modul yang diselenggarakan penggunaannya adalah suatu simulasi pengolah target, target pengolah harus dibuat bertahap ke dalam pengujian yang secepat itu menjadi tersedia. Test kembali cukup harus terpenuhi untuk memastikan kecocokan penuh.
Suatu komplemen matematika yang penuh dan rutin digunakan, mencakup test dan bantuan debugging, harus tersedia untuk Menguji Pengintegrasian Modul. Test Perangkat keras yang diperlukan meliputi semua sekeliling keperluan: terminal pemakai, pencetak garis, disk dan pengontrol tape dan pengarah, operator menghibur, dan seterusnya. Test ini lengkap di lingkungan yang tidak mungkin diperlukan sepanjang langkah-langkah awal pengujian, tetapi akan diperlukan ketika menguji kemajuan.

Masukan Test Data yang diperlukan datang dari perangkat keras/ piranti lunak yang nyata menghubungkan, jika tersedia. Cara lainnya, masukan data harus mewakil contoh antarmuka yang nyata itu. Pengarah Test dan lain program test yang memerlukan untuk memverifikasi dan Penerimaan Pengujian harus digunakan Pengujian Pengintegrasian Modul. Ini disahihkan untuk menggunakan Verifikasi formal yang menguji sebagai hasil operasi sukses selama Menguji Pengintegrasian Modul. Menguji Pengintegrasian Modul terdiri dari dua unsur-unsur: Menguji Pengintegrasian dan Menguji Verifikasi Fungsional.

Menguji Pengintegrasian yang memverifikasi ketepatan antarmuka program dengan pengujian bahwa masing-masing program dapat dipanggil dan dihubungi oleh program itu menghubungkan dengan, dan lewat parameter dengan baik. Tujuan Pengujian Pengintegrasian Modul yang utama adalah :

1. untuk menetapkan kecocokan antara modul dan program komputer saling berinteraksi, dan
2. untuk menetapkan kecocokan program dengan antar muka eksternal mereka.

Menguji Verifikasi Fungsional yang terdiri dari menguji koleksi unit program telah diterapkan dan pengujian untuk melihat bahwa mereka berfungsi sebagai suatu modul yang terintegrasi dan melaksanakan fungsi itu yang ditugaskan kepada mereka di dalam Dokumen Disain Rinci. Menguji Verifikasi Fungsional yang terdiri dari menguji koleksi unit program yang telah diterapkan dan pengujian untuk melihat bahwa mereka berfungsi sebagai suatu modul yang terintegrasi dan melaksanakan fungsi itu yang ditugaskan kepada mereka di dalam Dokumen Disain Rinci. Pengujian Verifikasi Fungsional pada umumnya dilakukan betapapun unit program yang berisikan suatu modul, suatu yang digambarkan pada dokumentasi disain, sudah lulus lewat Pengujian Pengintegrasian.

Penyelesaian Pengintegrasian Modul yang memuaskan pengujian yang menetapkan bahwa perangkat lunak yang diterapkan dengan baik melaksanakan fungsi itu menetapkan dokumentasi disain dan adalah menyisiapkannya untuk dibuktikan melawan terhadap kebutuhan yang ditetapkan Kebutuhan spesifikasi perangkat lunak.
Menguji Verifikasi (Verification Testing)
Menguji Verifikasi yang terdiri dari test, demonstrasi, dan melakukan analisa untuk mengkonfirmasikan bahwa piranti lunak membuat puas semua kebutuhan terasang permanen dan yang diperoleh dari Spesifikasi Persyaratan Piranti lunak. Spesifikasi Disain Rinci, yang digunakan pengujian lebih awal, hanya suatu permainan peran pelajaran pelengkap di dalam menguji verifikasi. Sebagai gantinya, awal dokumen yang menyatakan kebutuhan sistem atau perangkat lunak dan sasaran hasil produk atau misi itu adalah sumber yang utama dari kasus test yang diperoleh. Suatu korelasi antara Spesifikasi Persyaratan Piranti lunak dan Rencana Test Verifikasi disiapkan dalam bentuk Rencana Test. Prosedur Dan Rencana Test formal tertulis untuk Verifikasi pengujian. Analisa dilakukan untuk kebutuhan adalah terlalu mahal untuk memverifikasi dengan pengujian atau demonstrasi.
Test Verifikasi diselenggarakan di lingkungan test yang sama sebagai Test Pengintegrasian Modul, Penggunaan komplemen piranti lunak pendukungnya penuh, perangkat keras sekelilingnya, dan alat operator, lebih pengolah target, dengan kemampuan sistem operasi penuh dan perangkat keras nyata atau realistis menghubungkan data.
Sebelum dimulai Pengujian Verifikasi, program komputer daftar harus dilepaskan, kode program komputer harus di bawah pengendalian konfigurasi formal di dalam Program Komputer Perpustakaan , dan test prosedur harus disetujui semuanya. Semua Pengujian Verifikasi diselenggarakan di bawah pengawasan proyek yang digolongkan pejamin kualitas. Oleh karena pengujian yang luas mendahului test ini, itu diharapkan bahwa secara relatif sedikit kesalahan yang terjadi akan terbongkar dan terbuka pada Pengujian Verifikasi.
Pengulangan test dan pengujian yang berlebih-lebihan harus dengan bebas dihindarkan. Disimpulkan dari test ini, semua kebutuhan yang dapat dibuktikan pada tingkatan ini akan dibuktikan dan hasil percobaan dianalisa dan melepaskan. Test memverifikasi antarmuka eksternal, mempertunjukkan bahwa program komputer membuat kepuasan fungsional yang ditetapkan dan kebutuhan tercapai, dan mempertunjukkan capaian program komputer di bawah yang menirukan kondisi-kondisi operasional yang serupa bagi mereka yang mengharapkan operasi nyata. Ke tiga tingkatan test diuraikan di atas yang diterapkan serial berkenaan dengan unit program tertentu , tetapi dilakukan secara serempak pada seluruh tahap pengujian proyek itu. Suatu unit program masuk Pengujian Pengintegrasian Modul itu yang tahapannya secepat itu telah lulus lewat Pengujian Unit Program. Pada setiap waktu selama implementasi piranti lunak, suatu Verifikasi Test mungkin adalah dijumpai. Yang dipertunjukan bahwa tujuannya tercapai pada keseluruhan kebutuhan subsistem piranti lunak.

Pengujian Penerimaan
Banyak dari Test Verifikasi yang diulangi Pengujian Penerimaan untuk memverifikasi bahwa perangkat lunak yang dilaksanakan di lingkungan yang operasionalnya sebagai di dalam lingkungan test. Di dalam kejadiannya banyak orang, Pengujian Penerimaan adalah satu-satunya pengujian di mana perangkat lunak beroperasi dengan alat penghubung eksternal yang nyata, dibandingkannya dengan perangkat lunak test dan perangkat keras. Pada PDR persetujuan harus dicapai dengan pemakai bahwa pelaksanaan dari kasus test ini di dalam suatu cara menguraikan Test yang menggunakan rencana suatu data base yang disetujui dan memproduksi hasil percobaan yang mencukupi penerimaan yang digambarkan kriteia yang akan mengakibatkan penerimaan terhadap sistem perangkat lunak

Disimpulkan Menguji Penerimaan dan setelah Test Laporan telah tertulis, Tinjauan ulang Penerimaan perangkat lunak (Software Acceptance Review ( SAR)) dipegang. Pada tinjauan ulang ini produk perangkat lunak, kode, dokumen, dan hasil percobaan ditinjau. Jika semua materi adalah memuaskan dan sesuai penerimaan yang merencanakan tercakup di Test perencanaannya, perangkat lunak diterima. Kebutuhan SAR diuraikan bagian 8.3.3.
Dokumentasi akhir harus direncanakan untuk penyerahan setelah pelaksanaan sukses dari semua Test Penerimaan sedemikian rupa sehingga koreksi yang diharuskan oleh kesalahan yang terdeteksi akhirnya di dalam program test yang formal dapat dimasukkan.

Alternatif adalah untuk menyampaikan dokumen itu yang lebih awal dan mempunyai biaya dan tidak menyenangkan untuk mengeluarkan lembaran kesalahan yang tertulis atau halaman perubahan. Pendekatan yang belakangan tidaklah direkomendasikan. Oleh karena itu, pada waktu penerimaan, yang akhir itu "asbuilt" Dokumen Disain Rinci yang harus disiapkan dan Dokumen instruksi beroperasi harus diselesaikan. Dengan penyerahan masing-masing perangkat lunak, suatu Uraian Versi Dokumen adalah juga diperlukan.

8.1.4 Pengendalian Tes (Test Control)
Pengujian Unit Program dilakukan dan dikendalikan oleh programmer siapa yang menerapkan unit itu. Sebelum persandian unit, programmer perlu mepelajari Uraian Dokumen Disain Rinci unit program dan siapkan rencana test informal dan memeriksa prosedur. Ini disatukan pada Folder Pengembangan Unit. Sekali ketika unit lewat Menguji Unit Program, itu disampaikan kepada Perpustakaan Program Komputer. Unit kemudian adalah mengintegrasikan ke dalam sistem, dan Pengujian Pengintegrasian modul dilakukan oleh kelompok pengembangan, yang dibantu oleh QA organisasi. Bila ada permasalahan yang ditemukan, mereka didokumentasikan pada suatu Laporan Masalah Perangkat lunak (Software Problem Report ( SPR)) Format ( lihat bab 9) dan unit itu dikembalikan ke programmer untuk dimodifikasi dan unit program yang berikutnya diuji kembali.

Jika Pengujian Pengintegrasian Modul untuk suatu program yang membongkar suatu masalah di dalam program yang telah duji , program ini harus dipindahkan dari tempat alas test ( koleksi dari modul perangkat lunak yang diuji) dan dikembalikan ke programmer itu untuk dimodifikasi dan diuji. Masalahmya tergantung pada kesungguhan hati, semua dari bagian dari Pengujian Pengintegrasian Modul harus diulangi yang melibatkan program yang salah/cacat itu. Keputusan dari apa yang telah ditest perlu untuk pengulangan adalah dibuat oleh organisasi pengembangan software. Sekali melengkapi program;menyudahi Pengujian Pengintegrasian Modul itu yang menjadi bagian dari dasar test sistem yang dan digunakan sebagai bagian dari bingkai yang bekerja untuk menguji lain program.
Ketika keseluruhan sub system perangkat lunak telah lulus lewat Pengujian Pengintegrasian Modul, Pengujian Verifikasi dilakukan. Pemakai harus dilibatkan sedapat sebanyak mungkin di dalam Uji Verifikasi agar supaya menjadi terbiasa dengan operasi perangkat lunak. Organisasi Penjamin kualitas melaksanakan Pengujian Verifikasi. Bila ada permasalahan yang terbongkar / terbuka, mereka mendokumentasikan adalah suatu Laporan Masalah Perangkat lunak ( lihat bab 10), dan programnya salah/cacat terisolasi dan dikembalikan ke para programmer itu. Program harus ditetapkan;perbaiki dan diuji kembali menurut prosedur itu seperti yang ditetapkan di atas. Verifikasi yang gagal test kemudian adalah diulangi sampai masalahnya terpecahkan.
Itu adalah tanggung jawab penjamin kualitas yang perorangan untuk memutuskan penyelesaian Verifikasi Test yang perlu untuk diulangi untuk tidak memastikan bahwa apapun efek samping adalah disebabkan oleh perubahan perangkat lunak yang dibuat untuk memecahkan permasalahan yang dikenali itu. Perangkat lunak harus dirancang untuk yang memerlukan saling ketergantungan minimal antara modul, sedemikian rupa sehingga perubahan satu modul tidak akan mempengaruhi lain modul. Ini akan mengijinkan pengujian untuk dilanjutkan ke area yang tidak bertalian dengan perangkat lunak yang sedang ada permasalahan ditetapkan diperbaiki. Pengujian Penerimaan diselenggarakan oleh organisasi penjamin kualitas dan pemakai di dalam lingkungan yang operasional itu. Bila ada permasalahan yang ditemukan, pemakai mempunyai hak untuk meminta bahwa keseluruhan Prosedur Test Penerimaan dimulai kembali ( kecuali jika lain prosedur yang telah ditetapkan pada Rencana Test).
Pengendalian Proses Pengujian oleh dokumentasi test yang berikut:

1. Rencana Test Unit Program informal dan Meriksa prosedur Folder Pengembangan Unit dan
2. Rencana Test formal dan Prosedur untuk Pengujian Pengintegrasian Modul, Pengujian Verifikasi, dan Pengujian Penerimaan.

Itu adalah tanggung jawab organisasi penjamin kualitas untuk memastikan bahwa semua pengujian adalah sesuai dengan dokumen ini dan bahwa semua hasil didokumentasikan. Pengendalian konfigurasi yang menempatkan pada dokumen ini diuraikan bab 9.


8.2 PROSES TEST DOKUMENTASI (TEST PROCESS DOCUMENTATION)

Tujuan aktivitas perencanaan test adalah bermakna untuk menetapkan untuk secara formal yang mempertunjukkan bahwa perangkat lunak komputer untuk dikirimkan membuat kepuasan kebutuhan yang susuai kontrak dan kinerjanya menurut Spesifikasi Persyaratan Piranti lunak yang telah disetujui.
Produk aktivitas perencanaan test adalah dokumentasi test. Dokumentasi Test formal yang diperlukan terdiri dari suatu Rencana Test, Menguji Prosedur Documen, dan Menguji Laporan. gambar 9.4 menyediakan suatu ringkasan parameter yang berhubungan dengan dokumentasi test yang formal.
Tujuan Rencana Test adalah untuk menetapkan kebutuhan terperinci, ukuran-ukuran, metoda umum, tanggung-jawab, dan perencanaan menyeluruh untuk mengkonfirmasikan bahwa "sebab yang dibangun" sistem memenuhi kebutuhan yang ditetapkan Spesifikasi Persyaratan Piranti lunak. Itu menggambarkan aktivitas test itu untuk dilakukan oleh pengembang piranti lunak untuk mencapai penerimaan piranti lunak oleh pemakai. Tujuan Prosedur Test adalah untuk menggambarkan secara detil prosedur yang nyata untuk dipekerjakan untuk melaksanakan test itu yang menggambarkan Test itu direncanakan. Dokumen Laporan Test hasil proses pengujian dan digunakan untuk secara formal untuk meyakinkan pemakai bahwa sistem yang beroperasi seperti yang ditetapkan.
Muatan yang terperinci dari tiap dokumen ini adalah mungkin ditemukan Catatan tambahan B.

8.2.1 Rencana Tes (Test Plan).
Rencana Test menguraikan program test piranti lunak yang lengkap. Itu menggambarkan pengujian pengembangan apa yang akan dilakukan oleh programmer, Pengintegrasian Modul apa, Verifikasi, dan Test Penerimaan akan dieksekusi, dan kondisi-kondisi di bawah masing-masing unsur-unsur program test yang mana akan terpenuhi.

Rencana Test yang menggambarkan bentuk wujud test itu, menguji jadual, dan test mengukur, mengidentifikasi peralatan test diperlukan suatu test piranti lunak, menggambarkan peran berbagai organisasi di dalam memproses test, menggambarkan pengendalian konfigurasi itu untuk diterapkan pada tingkatan masing-masing pengujian, dan mengidentifikasi kasus test untuk dieksekusi pada tingkatan test masing-masing. Uraian yang terperinci kasus test disiapkan dalam bentuk Prosedur Test itu. Yang secara rinci, Rencana Test menguraikan:

1. Tanggung-Jawab yang organisatoris untuk berbagai tugas di dalam program test.
2. Metoda untuk dipekerjakan untuk meninjau ulang rencana test dan prosedur, monitor dan pengendalian pelaksanaan test, laporan dan mengoreksi pertentangan test, melaporkan hasil percobaan, dan menentukan kesiap-siagaan untuk penerimaan.
3. Tujuan Dan Konsep yang tertinggi untuk pengembangan dan Pengujian Penerimaan dan strategi untuk memenuhi tujuan ini, mencakup suatu uraian test mengukur dan filosofi pengembangan.
4. Generator Data, menguji pengarah, simulator lingkungan dan program analisa test memerlukan untuk masing-masing tingkatan yang diuji. (Catatan : Seluruh pengujian piranti lunak harus dibuktikan dan di bawah konfigurasi pengendalian sebelum penggunaannya untuk verifikasi formal.)
5. Konsep Dan Metoda menekankan piranti lunak ( e.g., dengan sibuk dan jika tidak ada data masukan tidak sempurna, atau dengan data puncak yang mengisi) selama tingkatan pengujian masing-masing.
6. Jadual Test, Yang menyediakan suatu uraian yang terperinci urutan dari semua aktivitas test. Jadual Test harus dibentuk mapan untuk memastikan bahwa pengujian yang diperlukan akan diselesaikan di dalam periode waktu yang dibagikan. Jadual Test harus kompatibel dengan:
   (a) Ketersediaan fasilitas komputer.
   (b) Ketersediaan piranti lunak untuk diuji
   (c) Ketersediaan pendukung piranti lunak test
   (d) Ketersediaan intefacing piranti lunak dan perangkat keras
   (e) Ketersediaan dari peralatan test khusus
   (f) Keseluruhan proyek menguji jadual
7. Lingkungan Test, mencakup bentuk wujud perangkat keras, menguji konfigurasi piranti lunak, dan memerlukan pembuktian unsur-unsur piranti lunak baru. Lingkungan Test harus dibentuk mapan sebagai bagian dari proses perencanaan test di depan kasus test dapat digambarkan. Diagram blok, mempertunjukkan kemajuan pengujian konfigurasi, yang harus disiapkan untuk masing-masing tingkatan pengujian.
8. Test yang individu untuk dilakukan untuk mempertunjukkan pemenuhan dengan kebutuhan. Uraian dari tiap kasus test meliputi kebutuhan itu untuk dibuktikan,konfigurasi test untuk digunakan, dan piranti lunak test yang diperlukan. Prosedur Test akan disiapkan yang kemudiannya untuk masing-masing mengenali kasus test.
9. Suatu subset kasus test yang menggambarkan Test direncanakan. Test ini harus dikenali seperti Kasus Test Penerimaan untuk menyediakan tujuan penerimaan piranti lunak. Kasus ini harus disetujui dengan pelanggan ketika Rencana Test Penerimaan.

Sebagai contoh table untuk Perencanaan Pengujian/Test adalah disediakan pada gambar 8.5.

8.2.2 Prosedur Pengujian (Test Procedures)

Test Dokumen Prosedur dikembangkan untuk menguraikan Pengintegrasian Modul itu, Verifikasi, dan Prosedur Test Penerimaan. Prosedur ini mungkin adalah dikombinasikan ke dalam satu dokumen untuk program komputer kecil, satu dokumen untuk prosedur pada masing-masing menguji tingkatan, atau, karena sistem besar, volume tambahan terpisah.
Karena masing-masing kasus test mengenali Test yang direncanakan, Prosedur Test menggambarkan bentuk wujud test itu, test yang dilakukan, dan hasil percobaan. Bentuk wujud Test menetapkan material test yang spesifik, masukan data, test rutin, dan konfigurasi perangkat keras. Test yang dilakukan itu menguraikan secara bertahap berurutan diikuti untuk melakukan penyelenggaraan test, bagaimana dan kapan menguji data yang diharapkan untuk masuk, dan mengharapkan hasil. Hasil yang diharapkan meliputi toleransi yang bisa diterima dan suatu pendukung diskusi bagaimana hasil ini menunjukkan bahwa sasaran test telah dicukupi. Di mana jika informasi tambahan bisa dilaksanakan pada pilihan program dan yang diperkirakan waktu dijalankan harus dikenali. Suatu tabel contoh isi Dokumen Prosedur Test ditunjukkan pada gambar 8.6.

Di mana seperti Rencana Test yang memberi suatu ikhtisar program test, Dokumen Prosedur Test memberinya secara bertahap prosedur yang terperinci yang diperlukan untuk menguji perangkat lunak itu. Karena sejak Rencana Test dikirimkan format akhir pada CDR, itu tidak bisa meliputi suatu uraian yang terperinci dari semua pemakai yang memerlukan hubungan. Prosedur Test berisi acuan kepada Test yang direncanakan, di mana jika sesuai, untuk menghindari duplikasi informasi. Mereka mempunyai banyak dari bagian yang sama sebagai Rencana Test, tetapi berisi yang lebih detil tentang kenyataan perancangan test itu.
Karena merampas perkerjaan mengikuti jalan dan dokumen itu menguji proses, masing-masing tingkatan test dapat dipecah ke dalam tahap test. Di dalam Pengujian Pengintegrasian Modul, tahap test ini menghadirkan peristiwal fungsional yang utama di dalam proses pengembangan. Di dalam Verifikasi Dan Pengujian Penerimaan, tahap ini menghadirkan peristiwa yang utama utama di dalam menguji proses itu. Tahap yang dapat digambarkan oleh modul yang diselesaikan atau oleh peristiwa fungsional di dalam satu subsistem ketika suatu kemampuan yang bisa menguji baru ditambahkan kepada subsistem itu. Test bertahap harus yang cukup kecil untuk pengujian terpenuhi dua sampai empat jam.


ISI : DOKUMEN RENCANA PENGUJIAN

Bagian 1 Pengenalan
1.1 Lingkup
1.2 Maksud
1.3 Ringkasan

Bagian 2 Dokumen Keterkaitan
1.1 Referensi yang dapat diterapkan
1.2 Dokumen Pengembangan

Bagian 3 Konsep Pengujian
1.1 Filosofi Pengujian
1.2 Verifikasi Metode
1.3 Tingkatan Pengujian
1.3.1 Unit Pengujian Program
1.3.2 Pengujian Integrasi Modul
1.3.3 Verifikasi Pengujian
1.3.4 Penerimaan Pengujian

1.4 Peraturan Organisasi
1.4.1 Pengembangan Piranti Lunak
1.4.2 Penjamin Produk
1.4.3 Pengendalian Produk
1.4.4 Verifikasi dan Sertifikasi
1.4.5 Integrasi dan Pengujian
1.4.6 Human Engineering

1.5 Pengendalian Pengujian
1.5.1 Penjamin Kualitas
1.5.2 Memonitor Pengujian
1.5.3 Pengendalian Konfigurasi Pengujian

Bagian 4 Verifikasi Persyaratan dan Kriteria
4.1 Pengujian ke I
1.1.1 Deskripsi Pengujian
1.1.2 Pelaksanaan Pengujian
1.1.3 Hasil yang diharapkan
…….
4.n Pengujian n
4.n.1 Deskripsi Pengujian
4.n.2 Pengujian Masukan
4.n.3 Pelaksanaan Pengujian
4.n.4 Hasil yang diharapkan

Bagian 5 Persyaratan dan Ringkasan Tahap Pengujian

Bagian 6 Pengujian Integrasi Modul
1.1 Pengenalan
1.2 Lokasi dan Jadual
1.3 Pembatasan dan Komentar Umum
1.4 Persipan Masukan
1.5 Pengujian Dilakukan
1.6 Hasil Analisis
1.7 Pengujian Lingkungan
1.8 Persyaratan Personil

Bagian 7 Verifikasi Pengujian
1.1 Pengenalan
1.2 Lokasi dan Jadual
1.3 Pembatasan dan Komentar Umum
1.4 Persipan Masukan
1.5 Pengujian Dilakukan
1.6 Hasil Analisis
1.7 Pengujian Lingkungan
1.8 Persyaratan Personil

Bagian 8 Penerimaan Pengujian
8.1 Pengenalan
8.2 Lokasi dan Jadual
8.3 Pembatasan dan Komentar Umum
8.4 Persipan Masukan
8.5 Pengujian Dilakukan
8.6 Hasil Analisis
8.7 Pengujian Lingkungan
8.8 Persyaratan Personil

Bagian 9 Pengendalian dan Prosedur Pelaporan
9.1 Pengendalian Pengujian Program
9.2 Dokumentasi Prosedur PengujianDokumentasi Laporan Pengujian

8.2.3 Laporan Pengujian (Test Reports)
Dokumen Laporan Test hasil untuk masing-masing tahap pengujian kasus yang menggambarkan Rencana Test dan yang diuraikan secara detil di dalam Prosedur Test. Hasil percobaan untuk masing-masing kasus test diuraikan dengan suatu ringkasan permasalahan yang ditemukan, SPRs menulis lagi test, yang disposisi SPRs, dan disposisi keluaran test yang berhasil pada pelaksanaan yang terakhir. Juga dimasukkan adalah yang manapun direkomendasikan perubahan pada dokumentasi yang sebelumnya, yang mencakup halaman perubahan dan permintaan surat pelepasan tuntutan. Suatu daftar isi contoh untuk Dokumen Laporan Test disiapkan dalam bentuk gambar 8.7.


8.3 TEST TINJAUAN ULANG (TEST REVIEWS)

Tiga jenis tinjauan ulang diadakan untuk pendukung pengujian:

1. Rancangan Kritis Dan persiapan tinjauan ulang untuk meninjau ulang rancangan dan Perencanaan Test,
2. Menguji Tinjauan ulang (Prosedur Test Procedures Review (TPR)), yang sebelum ditangani pengujian formal (mungkin adalah dtangani kenaikannya), dan
3. Tinjauan ulang Penerimaan Piranti lunak (SAR)

ISI : DOKUMEN PROSEDUR PENGUJIAN

Bagian 1 Pengenalan
1.1 Maksud
1.2 Lingkup
1.3 Ringkasan

Bagian 2 Dokumen Keterkaitan
1.1 Referensi yang dapat diterapkan
1.2 Dokumen Pengembangan

Bagian 3 Pengujian Obyektiv

Bagian 4 Orang yan Bertanggung Jawab

Bagian 5 Perlengkapan dan Persyaratan program Komputer

Bagian 6 Prosedur Operasi Pengujian
6.1 Inisiatif Sistem Operasi
6.2 Pemeliharaan Sistem Operasi
6.3 Mengakhiri dan Mengulang Sistem Operasi

Bagian 7 Prosedur Rinci Pengujian : Pengujian Integrasi Modul
3. Pengujian ke I
4. Deskripsi Modul
5. Pengujian Masukan
6. Pengujian Dilakukan
7. Hasil yang diharapkan
…..
7.n Pengujian ke n
7.n.1 Deskripsi Modul
7.n.2 Pengujian Masukan
7.n.3 Pengujian Dilakukan
7.n.4 Hasil yang diharapkan

Bagian 8 Penerimaan Pengujian
8.1 Pengujian ke I
8.2 Deskripsi Modul
8.3 Pengujian Masukan
8.4 Pengujian Dilakukan
8.5 Hasil yang diharapkan
…..
8.n Pengujian ke n
8.n.1 Deskripsi Modul
8.n.2 Pengujian Masukan
8.n.3 Pengujian Dilakukan
8.n.4 Hasil yang diharapkan

Bagian 9 Pengendalian dan Prosedur Pelaporan
9.1 Pengujian ke I
9.2 Deskripsi Modul
9.3 Pengujian Masukan
9.4 Pengujian Dilakukan
9.5 Hasil yang diharapkan
…..
9.n Pengujian ke n
9.n.1 Deskripsi Modul
9.n.2 Pengujian Masukan
9.n.3 Pengujian Dilakukan
9.n.4 Hasil yang diharapkan

Bagian 10 Analisis dan Reduksi Data
10.1 Mencatat dan Persyaratan Reduksi
10.2 Reduksi Data dan Prosedur Analisis

Appendix A Akronim dan Singkatan
Appendix B Definisi dan Nomenklatur

Gambar 8.6 Contoh table isi untuk Dokumen Prosedur Pengujian


ISI : DOKUMEN PELAPORAN

Bagian 1 Pengenalan
1.1 Maksud
1.2 Lingkup
1.3 Ringkasan

Bagian 2 Dokumen Keterkaitan
2.1 Referensi yang dapat diterapkan
2.2 Dokumen Pengembangan

Bagian 3 Pengujian Obyektiv dan Hasil

Bagian 4 Laporan Pengujian : Pengujian Integrasi Modul
1.1 Pengujian ke I
……
4.n Pengujian ke n

Bagian 5 Perlengkapan dan Persyaratan program Komputer
5.1 Pengujian ke I
…..
5.n Pengujian ke n

Bagian 6 Prosedur Operasi Pengujian
6.1 Pengujian ke I
…..
6.n Pengujian ke n

Bagian 7 Prosedur Rinci Pengujian : Pengujian Integrasi Modul
7.1 Revisi Dokumen
7.2 Pengujian Tambahan
7.3 Permintaan Surat Pelepasan tuntutan

Bagian 8 Attachment untuk Laporan Pengujian

Appendix A Akronim dan Singkatan
Appendix B Definisi dan Nomenklatur
Appendix C Data Pendukung

Gambar 8.7 Contoh table isi untuk Dokumen Prosedur Pengujian

Yang ditangani Setelah Pengujian Penerimaan dengan sukses diselesaikan dan semua diperlukan dokumentasi yang telah disiapkan atau diperbaharui kepada" as-built" bentuk wujud. Organisasi penjamin kualitas menghadiri semua tinjauan ulang untuk memastikan bahwa program penjamin kualitas diterapkan. Isi, Format, dan yang diharapkan hasil dari tinjauan ulang ini dibahas pada subseksi yang berikut ini.

8.3.1 Disain Kritis Dan Persiapan Tinjauan Ulang (Preliminary and Critical Design Reviews)

Format rencana test ditinjau dalam persiapan Disain Kritis dan persiapan tinjauan ulang (Preliminary Design Review ( PDR)) dan di dalam format terakhir Tinjauan ulang Disain Kritis (Critical Design Reviews (CDR)). Tujuan Tinjauan ulang Rencana Test adalah untuk memastikan bahwa semua corak disain penting akan diuji dan bahwa semua kebutuhan spesifikasi akan dibuktikan. Filosofi Program Test memperkenalkan Rencana Test yang telah dipersiapkan ditinjau secara detil di PDR itu. Detil test yang nyata adalah di dalam Rencana Test yang akhirnya peninjauan pada CDR.

8.3.2 Menguji Tinjauan ulang Prosedur (Test Procedures Review)
Prosedur Test Perangkat lunak ditinjau pada Tinjauan ulang Prosedur Test untuk memastikan bahwa pengujian cukup akan dilakukan pada komponen masing-masing. Tinjauan ulang ini menyediakan persetujuan formal untuk prosedur untuk digunakan di dalam menguji dan memastikan bahwa mereka menyelesaikan tujuan Test yang telah direncanakan.
Dua rangkaian Tinjauan ulang Prosedur Test diselenggarakan: Prosedur Test Pengembangan Tinjauan ulang. Ini harus diselenggarakan secara terpisah. Tinjauan ulang Prosedur Test Pengembangan diselenggarakan sebelum Pengujian Pengintegrasian Modul dan tinjauan ulang prosedur itu untuk diikuti Sistem Pengintegrasian Modul. Tinjauan ulang Prosedur Test Pengesahan diselenggarakan sebelum Pengujian Verifikasi untuk meninjau ulang prosedur untuk diikuti Verifikasi Dan Pengujian Penerimaan. Test Pengembangan diselenggarakan untuk memastikan bahwa program komputer yang diselesaikan yang membuat kepuasan kebutuhan tercapai yang dinyatakan nya. Seperti itu, test pengembangan mengevaluasi program komputer itu lagi kebutuhan di dalam Spesifikasi Kebutuhan Perangkat lunak. Materi untuk diuji mengevaluasi prosedur test ini seperti daftar di bawah ini:

1. Uji Procedures/Plan Kecocokan. Prosedur harus konsisten dengan Test Rencanakan dan meliput semua area test diperlukan.
2. Menguji Masukan. Test Masukan harus digambarkan; masukan menggambarkan untuk test melakukan harus mampu untuk menguji disain pada batas nya.
3. Menguji Kelengkapan. Test yang didokumentasikan [perlu] mencukupi semua sasaran hasil test. Semua aspek/pengarah [yang] penting perangkat lunak disain harus dicoba-coba pengujian dan harus didokumentasikan.
4. Meriksa prosedur Kejelasan. Operator Instruksi harus dinyatakan dengan jelas, dengan singkat, dan secara terang.
5. Kofigurasi Piranti lunak. Bentuk wujud piranti lunak untuk diuji harus dengan teliti dan secara menyeluruh uraikan.
6. Ukuran-Ukuran Sukses. Sukses Ukuran-Ukuran harus digambarkan untuk masing-masing langkah pada setiap prosedur test; mereka harus konsisten dengan sasaran hasil ia perjanjian
7. Konfigurasi Perangkat keras. Perangkat keras Test Bentuk wujud harus cukup untuk melakukan test dan menggambarkan dalam detail yang jelas untuk mengevaluasi ketercukupan nya.
8. Menguji Konfigurasi Piranti lunak. Piranti lunak Test yang diperlukan konfigurasi harus cukup digambarkan. Pemenuhan perlu meliputi susunan test, masukan data, sekeliling, display, ukuran-ukuran sampling data, tingkat data rate, dan seterusnya.

8.3.3 Penerimaan Tinjauan Ulang Piranti lunak (Software Acceptance Review)

Tinjauan ulang Penerimaan Piranti lunak adalah suatu pertemuan formal diadakan untuk audit produk piranti lunak sebelum diterima pemakai. Penyelesaian dari audit ini menandakan bahwa perangkat lunak adalah siap untuk dioperasikan dan tahap pengembangan itu adalah lengkap. Tinjauan ulang yang secara normal terdiri dari dua audit: suatu Audit Konfigurasi Fungsional (Functional Configuration Audit (FCA)) dan suatu Audit Konfigurasi Phisik (Physical Configuration Audit (PCA)). Audit ini mungkin adalah diselenggarakan incrementally sebagai informasi yang perlu menjadi tersedia. Jika mereka diselenggarakan incrementally, kebanyakan materi tinjauan ulang akan merupakan suatu perihal merekam pada ketika pertemuan yang formal itu. SAR akan kemudian berisi sebagian besar menguji arsip untuk memastikan bahwa semua audit materi telah diselesaikan.

Audit Konfigurasi Fungsional (Functional Configuration Audit (FCA))
Sasaran FCA adalah untuk memverifikasi bahwa capaian piranti lunak mematuhi persyaratan capaian spesifikasi perangkat lunak itu. Ini adalah terpenuhi dengan tinjauan ulang data test itu yang mengumpulkan pengujian piranti lunak. Masing-Masing konfigurasi piranti lunak untuk disampaikan mungkin adalah tunduk kepada suatu FCA. Audit perlu menentukan yang berikut:

1. Kelengkapan Verifikasi. FCA perlu meliputi suatu audit test merencanakan, memeriksa prosedur, dan menghasilkan untuk mengkonfirmasikan bahwa data test dan hasilnya mematuhi rencana test itu dan memeriksa prosedur. Jika defisiensi dicatat, mengulangi test atau pengujian tambahan harus direkomendasikan. Di mana jika ada penyelesaian kebutuhan verifikasi parsial, status harus dibentuk mapan dan rencana untuk penyelesaian harus diperkenalkan
2. Kebenaran Simulasi. FCA perlu mengkonfirmasikan simulasi antarmuka perangkat keras dan piranti lunak itu menggunakan melakukan test telah disahihkan.
3. Kebenaran Penelitian. Di mana jika analisa telah digunakan sebagai suatu pengganti untuk menguji, metoda analisa dan hasilnya harus disahihkan.
4. Kebenaran Konfigurasi. fungsional Dan Memerinci Dokumen Disain dan Uraian dokumen Versi akan ditinjau untuk memastikan bahwa konfigurasi piranti lunak yang mengaudit adalah sama ketika itu dibuktikan.
5. Status Disain Perubahan. Semua perubahan, seperti ketika didokumentasikan oleh Laporan Masalah Piranti lunak, harus ditinjau untuk memastikan bahwa mereka telah disatukan dan dibuktikan.

Audit Konfigurasi Phisik (Physical Configuration Audit (PCA))
PCA diselenggarakan sebelum penyerahan item. Itu terdiri dari dari suatu pengujian dokumentasi disain yang terperinci melawan terhadap "as-built" konfigurasi perangkat lunak. Itu diselenggarakan untuk memastikan ketercukupan, kelengkapan, dan ketelitian dokumentasi disain yang teknis. Tinjauan ulang juga meliputi suatu audit status perubahan yang sekarang, perubahan arsip, dan arsip uraian versi untuk memastikan bahwa "as-built" konfigurasi adalah kompatibel dengan dokumen yang dilepaskan. Tim PCA perlu meninjau ulang itemnya seperti yang diuraikan di bawah. Dan Dokumen yang perlu Arsip harus disajikan oleh organisasi pengembangan piranti lunak.

1. Dokumentasi Rancangan. Suatu audit disain dokumentasi harus dilakukan untuk memastikan bahwa mereka persisnya itu menghadirkan untuk dikirimkan konfigurasi. Dokumentasi Disain terdiri dari Disain Yang fungsional, Menghubungkan pengendalian, dan Dokumen Disain Rinci. Pengujian dokumen perlu memastikan yang berikut: korelasi modul mengalir ke tingkat yang tertinggi, masukan sesuai ke aliran, dan korelasi data alat penghubung ke ICDs. Pengujian perlu juga memastikan definisi data base yang cukup karakteritiknya, ketentuan alokasi penyimpanan, pemilihan waktu dan karakteristik peruntukan, dan yang perlu cross-checking mengalir ke listing program computer.
2. Dokumentasi Test. Dokumentasi Test untuk ditinjau terdiri dari Perencanaan Test, Prosedur Test. Dan Laporan perubahan Test. untuk Menguji Prosedur yang membuat pengujian harus ditinjau untuk menentukan kebenaran test yang dilakukan menggunakan prosedur yang berkembang itu. Test Data harus diuji untuk meyakinkan bahwa semua data yang di test diperlukan hadir dan yang bersertifikat oleh organisasi penjamin kualitas. Perencanaan Test ditinjau untuk memastikan bahwa semua perubahan disetujui untuk Test Perencana telah dicerminkan Prosedur Test.
3. Uraian Dokumen Versi. Uraian Dokumen Versi harus teraudit untuk memastikan kelengkapan uraian versi yang dikirimkan itu. Suatu daftar lengkap dokumen, angka-angka versi, dan subroutine identifiers memerlukan untuk membangun versi program komputer itu harus dimasukkan
4. Dokumen Instruksi Operasi. Dokumen Instruksi operasi harus bersertifikat untuk penggunaan operasional.
5. Pendukung Dokumentasi. Semua pendukung bisa menyampaikan/kirim dokumentasi harus ditinjau untuk memastikan kelengkapan mereka.
6. Perubahan Status. Daftar semua perubahan disain yang menyatukan dengan program komputer itu karena sejak start menguji harus ditinjau untuk memastikan kelengkapannya.
7. Konfigurasi Materi. Konfigurasi Paket Item harus ditinjau untuk menjamin bahwa semua tape, kartu, dokumen, daftar, dan seterusnya hadir dan memberi label dengan identifikasi dan tanda-tanda yang diperlukan.

8.4 PENGUJIAN PROSES DAFTAR (TESTING PROCESS CHECKLIST)
Daftar nama yang berikut menyediakan suatu ringkasan mengenai pokok-pokok informasi yang harus tersedia dokumentasi test. Informasi ini memastikan bahwa perangkat lunak yang terakhir ditemukan kebutuhan itu yang menyatakan Spesifikasi Persyaratan Piranti lunak dan disain yang diuraikan Dokumen Persyaratan Disain Rinci.

1. Uji filosofi dan metodologi pekerja dan mengubah test methode yang dipertimbangkan untuk mencapai penerimaan terhadap perangkat lunak itu.
2. Memerlukan Personil untuk mendukung program test itu, yang mencakup banyaknya orang-orang dan kecakapan mereka dalam kaitannya dengan pelatihan, keanggotaan organisatoris, dan pengalaman.
3. Fasilitas Komputer yang diperlukan, mencakup suatu blok diagram sebagai tempat test yang di atasnya perangkat lunak akan jadi diuji.
4. Uji perangkat lunak yang diperlukan untuk mendukung program test itu.
5. Uji jadual, mencakup penempatan, menguji konfigurasi, dan diagram arus test.
6. Korelasi dari semua perangkat lunak dan kebutuhan disain ke test individu.
7. Capaian, Alat penghubung, dan kebutuhan test atas mana rencana test didasarkan.
8. Uji rencana untuk gerbang keluar dari tiap modul perangkat lunak menulis, seperti halnya suatu test merencanakan untuk memverifikasi bahwa sistem menemukan kebutuhan sistem itu.
9. Uraian dari semua pengujian untuk dilakukan mencakup masukan, melakukan test, dan mengharapkan hasil. Hasil yang diharapkan diperlukan meliputi ukuran-ukuran penerimaan dan toleransi pengukuran itu.
10. Hasil percobaan diperoleh pada setiap perjanjian

Dokumentasi Pengujian ditinjau pada sebagian pada PDR, CDR, TPR dan SAR. Ketika meninjau ulang dokumentasi ini, tim tinjauan ulang perlu memastikan bahwa:

1. Perencana Test meliputi suatu test terintegrasi beredar dari sistem meratakan kepada test yang paling rendah mengukur.
2. Masing-Masing test memverifikasi sedikitnya satu kebutuhan dan masing-masing kebutuhan dibuktikan dalam suatu perjanjian
3. Semua test dapat terpenuhi dengan perangkat lunak test dan peralatan mengenali.
4. Test yang dilakukan adalah suatu urutan yang logis, sedemikian rupa sehingga penggunaan yang maksimum hasil awal percobaan dapat direalisir test kemudiannya.
5. Test memverifikasi kecocokan alat penghubung.
6. Tidak ada area di atas pengujian atau di bawah pengujian.
7. Semua sumber daya pendukung dikenali.
8. Tanggung-Jawab peserta test dikenali.
9. Uraian dari tiap test adalah cukup untuk test yang benar-benar dilakukan.
10. Ukuran-Ukuran untuk sukses atau kegagalan dari tiap test secara jelas dikenali.
11. Masukan Test Dan Keluaran dikenali dan terdaftar.
12. Pertimbangan cukup diberikan kepada penyimpanan data dan pengurangan data.
13. Jadual Test adalah kompatibel dengan disain yangberedar.
14. Hasil yang nyata dari tiap test didaftarkan dan dibandingkan dengan hasil yang diramalkan itu. Hasil percobaan menemukan ukuran-ukuran penerimaan itu.

Referensi

Bob Hughes and Mike Cotterell, 2002, Software Project Management, McGraw Hill, London.
Philip Bruce, Sam M. Pederson, 1982 The Software Development Project, John Wiley and Sons, New York.
Steve McConnell, 1996, Rapid Development Taming Wild Software Schedule, Microsoft Press, Washington.
Tumar, 2002, Information System Strategic, Universitas Bina Nusantara, Jakarta.

TAHAP IMPLEMENTASI DAN OPERASI

TAHAP IMPLEMENTASI DAN OPERASI

oleh: Tumar

Tahap Implementasi dan Operasi pada proses pengembangan piranti lunak termasuk di dalamnya antara lain :

1. Penterjemahan Dokumen, Tinjauan rancangan rinci kedalam eksekusi kode,
2. Validasi transformasi diantara berbagai level testing,
3. Verifikasi formal syarat-syarat dokumen itu hasilnya memuaskan dalam Persyaratan Piranti Lunak Khusus.

Kunci kegiatan dalam tahap ini adalah penyelesaian pada implementasi dan testing piranti lunak dan secara formal piranti lunak diterima oleh pelanggan. Testing dan proses penerimaan dukungan aktivitas ini digambarkan secara rinci dalam Bab 8. Berikutnya kesimpulannya sukses pada upaya ini, yang mana mencapai puncaknya dengan intalasi piranti lunak dalam konfigurasi operasionalnya adalah telah siap hingga fungsi kinerjanya untuk implementasi ini.

Biasanya operasi piranti lunak setelah pasca penyerahan dan pemeliharaan nya adalah berdasarkan perjanjian/kontrak dan jelas organisasinya dari pengembangnya dan terpisah berkenaan dengan personil khusus termasuk di dalamnya. Bagaimanapun ringkasan laporan singkat tipe aktivitas wajib diberikan dalam bab ini, sejak mengetahui pengoperasian dan pemeliharaan sayarat-syaratnya mungkin mempengaruhi keputusan rancangan dan perhatian menetapkan pelbagai macam penugasan tahap pengembangan. Untuk latihan sebuah simulasi peralatan yang digunakan untuk mendukung rancangan dan tes pada sistem yang besar, yang mana akan dioperasikan oleh pengembang, mungkin tingkat keperluannya tidak sama rinciannya dalam dokumentasi dan testing daripada sistem piranti lunak komersial, yang mana akan dioperasikan oleh personil tata usaha dengan pergantian karyawan yang berkecepatan tinggi.

Dalam penambahan untuk dokumentasi tes dan penyerahan kode, beberapa produk dokumen selama ini tahap akhir pengembangan piranti lunak adalah digunakan untuk mendukung operasi piranti lunak dan pemeliharaannya. Ini termasuk memperbaharui dokumen rancangan untuk mewakili piranti lunak “as built”, sebuah deskripsi operasi piranti lunak yang disimpan, dan dokumentasi identifikasinya jelas setiap versi program komputer.


7.1 PROSES IMPLEMENTASI DAN OPERASI

Tahap Implementasi dan Operasi pada proses pengembangan piranti lunak konsisten terhadap tiga dasar aktivitas yaitu :

1. Menterjemahkan rancangan kedalam kode,
2. Testing / uji coba, dan
3. Operasi.

Aktivitas ini waktunya relatif seperti yang diilustrasikan dalam Gambar 8.1.

Dasar yang obyektif pada tahap ini adalah sampai :

1. Implementasi rancangan kedalam kode,
2. Tes/uji coba hasilnya piranti lunak, dan
3. Menyerahkan dengan resmi,
4. Penggunaan, dan
5. Pemeliharaan piranti lunak dalam lngkungan operasi

Disana transaksinya terkenal overlap dalam fungsinya dan iterasi berbagai macam langkah selesai pada aktivitas kinerjanya selama Proses Implementasi dan Operasi. Untuk Latihan :

1. Aktivitas Coding dan testing / uji coba (dan beberapa waktu rancangan kejadian) terus menerus pengulangan sebagai kesalahan adalah penutup dalam testing.
2. Pertimbangan fakta-fakta dan mengerti pada lingkungan operasi dan operatornya ahli dan sistem harus digunakan selama siklus pengembangan piranti lunak lengkap. Ini akan menjamin komplikasi sedikit berkurang dan rancangannya mahal dan implementasinya itu tepat dengan lingkungannya dalam program komputer adalah sampai pada operasi.
3. Sistem Operasi dan disiplin dalam pemeliharaan piranti lunak adalah peranan latihan selama coding dan testing. Prosedur untuk pemeliharaan adalah yang terus menerus selama tahap verifikasi testing yang belakangan. Prosedur untuk pemeliharaan piranti lunak dalam lingkungan operasi adalah menentukan dan utilitas setelah kontrol konfigurasi terintegrasi selama pengembangan.
4. Tes proses definisi harus dipertimbangkan aktivitas pemeliharaan piranti lunak sampai terjamin subsetnya itu akan tepat untuk tes ulang dalam lingkungan operasinya. Ini akan menyisihkan kebutuhan terakhir pekerjaan ulang tes generasi.
5. Melapiskan keatas dalam segala Implementasi dan Proses Operasi adalah konfigurasi aktivitas manajemen yang digambarkan dalam Bab 9.

7.1.1 Menterjemahkan Rancangan kedalam Kode
Langkah pertama dalam proses implementasi konsisten pada tugas termasuk di dalamnya adalah :

1. Kode Generasi,
2. Inspeksi Visual,
3. Pengecekan Kode.

Aktivitas ini adalah petunjuk pada persiapan kode untuk di tes.

Kode Generasi
Proses coding adalah konversi logic flow dari Dokumen Rancangan Rinci ke assembler atau Higher Order Language (HOL) statemen untuk masukan ke assembler atau HOL compiler. Salah satu Coding adalah sesuai dengan kinerjanya proyek programming standard termasuk dalam Rencana Proyek, atau sesuai dengan standard dokumen produk terpisah pada permulaan proyek. Ini adalah luar biasa pentingnya itu cukup tertulis komentarnya selama coding dengan mudah keluar

Inspeksi Visual
Compiler atau assembler hanya diberikan untuk mendiagnose kesalahan dalam syntax atau mengggunakan bahasa programming . ini tidak dapat diverifikasi kode itu dikoreksi terjemahannya pada logic flow. Sebuah peringatan langkah dalam proses pengembangan yang mana seringkali melampaui perbandingannya kode assemler (Compiler) dengan logic flow. Inspeksi Visual ini sederhana dapat disimpan dalam jam program komputer waktu dalam proses verifikasi oleh banyak lokasi yang sederhana kesalahan menterjemahkan logic.

Pengecekan Kode
Sebuah peringatan konsep untuk diimplementasikan dalam proses coding adalah kode yang kerjanya teliti (beberapa waktu menghubungi tinjauan kode tak sebanding). Dalam proses ini programmer menguji setiap kode yang berlainan dalam caranya terstruktur testing dimulai lebih dahulu. Dalam penjumlahan untuk membantu menemukan kesalahan dalam coding, antar muka, dan syarat-syarat implementasi , prosesnya kepercayaan manajemen juga dikurang pada dukungan programmer individu.

7.1.2 Testing
Proses testing yang diharapkan adalah sampai dijaminnya kode program itu memuaskan kinerjanya dan syarat-syarat rancangannya khusus dalam Persyaratan Spesifikasi Piranti Lunak. Proses testing didifinisikan rinci dalam Bab 8. Pada tahap ini proses testing mencapai puncaknya dalam verifikasi formal dan diserahkannya piranti lunak ke pelanggan.

7.1.3 Operasi
Sistem operasi konsisten pada utilitas piranti lunak dalam lingkungan operasinya dengan produk yang dihasilkan atau proses kontrol itu adalah definisi semula dalam spesifikasi sistem. Tahap operasi khas dimulai dengan tiga aktivitas utama.

Dukungan Transit
Seteleh penerimaan piranti lunak atau, dalam beberapa kasus, lebih dulu dengan penerimaan, periode operasinya paralel dan penala mungkin terjadi. Jika piranti lunak ditempatkan lagi pada piranti keras lama, piranti lunak atau sistem manual, ini mungkin periode operasi paralel bilamana jika keluarannya sistem baru adalah setara dengan yang lama. Sistem baru waktu itu dapat digunakan operasionalnya, dengan kemungkinan kembali pada sistem lama pada setiap saat, atau kenaikannya ini dapat diimplementasikan, tahapannya berangsur-angsur di luar sistem lama.
Selama transit atau periode aktivitas sistem, parameter database-nya mungkin sikapnya untuk membrikan dukungan operasi yang optimal. Ini menyesuaikan diri atau perbakan pada parameternya sering kali dapat dikerjakan hanya setelah sistemnya diamati dalam operasinya untuk beberapa waktu. Ini adalah peringatan seluruh piranti lunak itu berubah selama periode ini dengan resmi dikontrol, dan dengan tergesa-gesa perubahan implementasi dapat dibuktikan mendatangkan malapetaka.

Pelatihan Operator
Pelatihan personil pada pengguna piranti lunak baru mungkin juga di bawah lindungan kontrak pengembangan atau berikutnya dalam kontrak operasi dan pemeliharaan (O&M). Pada salah satu kasus, tingkat dan tipe pelatihan, jumlah / kuantitas material spesialis (bantuan visual, workshop material), sampai pada persiapan, jumlah orang untuk di latih, jumlah jam yang diberikan ( ruang kelas, laboratorium, dan mesin) dan latar belakang pelatihan seluruhnya akan masuk dalam kemajuan khusus.
Jika struktur sebagaimana mestinya, Fungsional Rancangan Rinci, dan Dokumen Instruksi Operasi elemen utamnya wajib diberikan untuk kursus pelatihan.

Operational Use
Bilamana piranti lunak yang akhirnya dimasukan kedalam operasional ini biasanya siapa personil yang latihannya tidak berperan pada upaya pengembangan (e.g., operator komputer dan perorangan yang familier dengan disiplin fungsional itu sebagai dukungan piranti lunak). Untuk alasan ini, salah pengertian syarat-syaratnya dan pemakaian sistem seringkali terjadi pada permulaan tahap operasi. Kemungkinan sewaktu-waktu, personil pengembangan piranti lunak akan diberikan bantuan di tempat ini selama waktu untuk menjawab pertanyaan, mengatasi kondisi yang luar biasa, dan menjelaskan pemakaian sistem untuk operasional personil. Dukungan tertutup ini akan tidak beralasan mencegah problem laporan dan menahan komplain jaminan transisi kedalam lingkungan operasi.

Pemeliharaan
Aktivitas Kunci yang akhir sepanjang tahap operasi adalah pemeliharaan piranti lunak. Suatu komponen pemeliharaan piranti lunak yang utama adalah proses manajemen konfigurasi. Proses ini dibahas pada bab 9. Pemeliharaan Piranti lunak melibatkan perbaikan kesalahan yang muncul dalam penggunaan operasional piranti lunak.

Pekerjaan ini terbaik dilaksanakan di bawah suatu kontrak terpisah. yang paling umum "bekerja keras jam" kontrak, di bawah yang suatu tingkatan usaha yang disajikan untuk menentukan apapun juga yang pelanggan perlukan, dan pelanggan membayar biaya itu terjadi. Kontrak jenis ini menghindari pertanyaan jaminan keabsahan dan argumentasi seperti pada perbaikan adalah suatu koreksi atau suatu upgrade. Upgrade yang secara khas memerlukan suatu perubahan kontrak jika usaha dilakukan di bawah kontrak pengembangan.

Suatu jaminan keabsahan perangkat keras berarti bahwa perangkat keras akan jadi ditetapkan diperbaiki jika itu gagal untuk menemukan spesifikasi pada beberapa petunjuk operasi. Yang sama adalah untuk benar produk piranti lunak. Itu adalah, piranti lunak dijamin untuk menemukan kebutuhan itu seperti yang dirumuskan dalam penerimaan piranti lunak menguji ukuran-ukuran. Test ini adalah cukup, karena sejak pelanggan telah menyetujui bahwa temuan test penerimaan itu adalah setara dengan temuan persyaratan.

Oleh karena itu, di dalam suatu yang tersusun dan pengembangan software yang diatur memproses, manapun kesalahan menemukan setelah penerimaan menguji. Pada kenyataannya, bagaimanapun, kesalahan yang harusnya telah ditemukan lebih awal terjadi, karena pada umumnya terlalu mahal untuk melaksanakan test penerimaan secara total menyeluruh. Oleh karena itu, awal persetujuan dengan pelanggan pada suatu kontrak perawatan piranti lunak dibiayai, bersama-sama dengan suatu pendekatan yang kaku kepada proses test seperti yang dirumuskan dalam bab 8, adalah pendekatan yang paling efisien dan murah ke keandalan piranti lunak dan pemeliharaan.

Perubahan Piranti lunak setelah penyerahan akan sering dibuat oleh para orang yang berbeda dari mereka mengembangkan piranti lunak. Oleh karena itu, dokumentasi sangat penting. Itu adalah basis dimana personil pemeliharaan memperoleh pemahaman operasi dan disain yang perlu untuk membuat perubahan tanpa memperkenalkan kesalahan baru. Jelas bersih, tegas eksplisit proses uraian di dalam Dokumen Disain rinci akan mengurangi kekejaman dan jumlah permasalahan yang operasional disebabkan oleh perubahan pemeliharaan yang salah. Pengendalian konfigurasi yang ketat yaitu kode dan dokumentasi diperbaharui, mencerminkan semua perubahan, adalah berisi yang diperlukan untuk mendukung aktivitas pemeliharaan piranti lunak. Prosedur Pengendalian ini digambarkan secara detil di dalam bab 9. Sebagai tambahan terhadap kesalahan perbaikan yang ditemukan pada pemakaian piranti lunak, pemeliharaan piranti lunak aktivitasnya meliputi peningkatan piranti lunak. Upgrade kecil terhadap piranti lunak yang dikirimkan sistem mungkin adalah terpenuhi dengan lindungan kontrak perawatan piranti lunak. bab 9 menyediakan petunjuk untuk mengendalikan yang menghasilkan perubahan konfigurasi. Bagaimanapun juga perubahan yang lebih besar, , harus diperlakukan secara terpisah. Mereka harus dihargai, dijadualkan, didokumentasikan, dan dikendalikan dengan cara yang sama sebagai pengembangan yang asli. Produk yang dihasilkan mungkin adalah suatu pelepasan/release yang baru dari beberapa unsur-unsur sistem piranti lunak atau suatu penyerahan kembali yang lengkap untuk keseluruhan sistem piranti lunak, bukan tidak sama dengan penyerahan sistem yang asli.
Seperti ketika dengan pemeliharaan piranti lunak, suatu unsur kunci di dalam mengurangi resiko peningkatan adalah mutu dokumentasi disain


7.2 DOKUMEN TAHAP IMPLEMENTASI DAN OPERASI (IMPLEMENTATION AND OPERATION PHASE DOCOMENTATION)

Seperti yang ditunjukkan pada gambar 7.1, baseline dokumen untuk Implementasi Dan Tahap Operasi adalah Dokumen Instruksi Operasi, Bundel Unit Pengembangan, fungsional yang terakhir dan Dokumen Disain Rinci, dan Dokumen Uraian Versi. Dokumen ini mungkin adalah diperbaharui seperti terjadi perubahan operasi dan pemeliharaan piranti lunak. Muatan indeksnya yang terperinci dari tiap dokumen mungkin adalah ditemukan dalam Catatan tambahan B.


7.2.1 Dokumen Instruksi Operasi (Operating Instructions Document)

Tujuan Dokumen Instruksi Operasi adalah untuk menguraikan prosedur operasi untuk mengisi, start, beroperasi, start kembali, dan stop program komputer. Melengkapi instruksi operasi meliputi kebutuhan mesin, masukan, keluaran, mengendalikan gambaran kartu atau format masukan papan tombol, pilihan, pembatasan, perberhentian dan prosedur recovery, daftar on-line, dan parameter khusus.

Ada dua kategori prosedur operasi untuk piranti lunak. Kategori yang pertama, Operasi Program komputer, menunjukkan langkah-langkah yang diperlukan untuk membawa program komputer itu dari status yang diam di dalam penyimpanan program bagi suatu status yang dinamis mampu melakukan fungsi yang diharapkan. Kategori yang kedua , operasi fungsi utama, menguraikan bagaimana kemampuan piranti lunak dicoba-coba. Kategori yang pertama adalah sering didokumentasikan sebagai suatu "Pemandu Operator", sedangkan kategori yang kedua adalah tercakup di sebuah " Manual Pemakai".
Karena masing-masing fungsi utama, suatu diskusi yang teknis ringkas tentang operasi program di dalam memberikan gaya. Ini adalah terpenuhi yang mana dengan mengacu pada dokumen rinci, seperti Persyaratan Spesifikasi Piranti lunak atau dokumen disain program komputer, atau termasuk dengan beberapa atau semuanya detil yang secara normal terdapat di dokumen ini. Isi yang umum, Tinjauan ulang, Persetujuan, dan persyaratan pengendalian untuk dokumen ini diperkenalkan pada gambar 7.2. Suatu daftar isi contoh disiapkan dalam bentuk gambar 7.3. Seluruh persiapan Dokumen Instruksi Operasi, ketrampilan dan keahlian dari semua para pemakai mungkin harus dipertimbangkan dengan seksama.
Maka, di dalam ada persyaratan untuk uraian yang terang, jelas dan bersih dengan mudah memahami susunan kata. Ilustrasi, Grafik, Tabel, dan tabel harus digunakan dengan bebas untuk memudahkan pengertian dan untuk menyediakan material acuan yang cepat. Dokumen Instruksi Operasi adalah manual yang harus akurat atas siklus hidup piranti lunak, dan itu adalah tunduk kepada perubahan yang berkesinambungan. Oleh karena itu, dokumen harus terorganisir dan terikat dengan cara yang akan membuatnya murah dan menyenangkan untuk memelihara.

7.2.1 Bundel Unit Pengembangan (Unit Development Folder UDF)

Bundel Unit Pengembangan (Unit Development Folder UDF), sering dihubungikan dengan Buku catatan Programmer, adalah suatu catatan [tentang aktivitas pengembangan piranti lunak/software spesifik yang berhubungan dengan suatu unit program. Itu dibangun seperti yang terbentuk di start program dan menjadi suatu alat manajemen penting untuk monitoring kemajuan selama pengembangan piranti lunak/software dan aktivitas pengujian . Bundel Unit Pengembangan juga bertindak sebagai sarana di mana disain piranti lunak barangkali kenaikannya yang ditinjau oleh pelanggan sepanjang proses pengembangan piranti lunak/software.
Programmer yang bertanggung jawab untuk suatu unit program memelihara UDF yang terkait di dalam suatu buku catatan. Format yang paling menyenangkan adalah suatu loose-leaf binder dengan menyebut bagian. UDF adalah pusat tempat untuk memelihara semua informasi yang diperlukan tentang unit tertentu dan akan menjadi berat dengan didasarkan ketika membangkitkan "ketika dibangun" dokumentasi sistem yang tercakup di dokumen disain akhir. Jadi UDF juga akan menggunakan untuk memenuhi yang berikut:

1. Memastikan dokumentasi unit program yang konsisten proses pengujianya.
2. Menjajaki apapun modifikasi untuk perancangan unit program yang asli.
3. Disain Dokumen Dan Keputusan Coding yang mungkin mempengaruhi capaian atau kemampuan akhir sistem.
4. Mengurangi waktu yang diperlukan untuk unit program yang familiarisasi selama pemeliharaan sistem.
5. Menyediakan suatu sarana untuk monitoring kemajuan proyeku pada suatu unit program dasar.

7.2.2 Dokumen Rancangan (As built) (Design Documents (As-Built))
Versi yang fungsional akhir dan Dokumen Disain Rinci persisnya mempunyai isi yang sama sebagai versi persiapan yang digambarkan lebih awal. Versi yang lebih awal tidaklah dipertimbangkan persiapannya disebabkan informasi adalah yang hilang, tetapi hanya oleh karena pengenalan perubahan yang akan terjadi sepanjang proses implementasi disain. Produksi dokumen yang terakhir adalah suatu pekerjaan yang secara langsung jika Bundel Unit Pengembangan telah dengan baik terawat. Dokumen Disain Rinci yang terakhir perlu juga berisi program yang didaftarkan terakhir. Daftar ditambahkan sebagai suatu catatan tambahan dokumen (mereka mungkin adalah secara terpisah terikat).

7.2.3 Dokumen Diskripsi Versi (Version Description Document)
Tujuan Dokumen Uraian Versi adalah mencatat dan menguraikan kemampuan dan isi dari tiap versi yang disampaikan sistem piranti lunak. Itu mengidentifikasi materi yang disampaikan dan arsip yang tambahan data yang bersangkutan berkenaan dengan status dan pemakaian perubahan program komputer bagi suatu program yang disampaikan. Itu mengidentifikasi disain yang bisa diterapkan dan dokumen test, daftar dari tiap versi secara terpisah mampu menyusun unsur piranti lunak, mengidentifikasi adaptasi data itu yang berhubungan dengan versi, dan memberi instruksi untuk membangitkan obyek kode yang baru dari sumber program dan data.
Isi, Tinjauan ulang, Persetujuan, dan persyaratan pengendalian untuk Uraian Versi yang diringkas pada gambar 7.6 Suatu daftar isi contoh disiapkan dalam bentuk gambar 7.7.

7.2.4 Dokumen Tes (Test Documentation)
Seperti diuraikan bab 8, dokumentasi test yang sisanya dikembangkan tahap ini. Ini meliputi awal dan akhir Dokumen Prosedur Test akhir dan Laporan Test.


7.3 TAHAP TINJAUAN ULANG IMPLEMENTASI DAN OPERASI (IMPLEMENTATION AND OPERATION PHASE REVIEWS)

Tiga jenis tinjauan ulang yang diadakan untuk pendukunga aktivitas Implementasi Dan Tahap Operasi:

1. Kode Dan Tinjauan ulang Disain Internal berjalan untuk meninjau ulang disain piranti lunak dan menyelesaikan kode,
2. Bundel Pengembangan Unit untuk memverifikasi kelengkapan UDF dan pemenuhan untuk menetapkan standard, dan
3. Menguji Tinjauan ulang untuk menguji proses dan untuk memverifikasi operasi piranti lunak yang benar.

Organisasi Penjamian Kualitas harus diwakili dengan orang yang sama waktu meninjau ulang untuk meyakinkan bahwa program yang diterapkan kualitasnya dijamin. Isi, Format, dan mengharapkan hasil dari tinjauan ulang ini dibahas subseksi yang berikut.

7.3.1 Tinjauan Ulang Rancangan Internal (Internal Design Reviews)
Tinjauan ulang rancangan internal (IDRs), yang diperkenalkan sepanjang Tahap Disain Yang terperinci, harus dilanjutkan sepanjang proses implementasi. Tujuan, Isi, dan format IDRs sepanjang Tahap Disain Rinci yang diuraikan Sesi 6.3.1. Tinjauan ulang mempunyai tujuan yang sama dan perlu mengikuti format yang sama sepanjang proses implementasi, tetapi perlu memusatkan pada disain yang lebih terperinci isu dan informasi implementasi, termasuk menyelesaikan kode. Perjalanan Kode keliling harus diselenggarakan setelah suatu unit program adalah coded, tetapi sebelum belanjaan manapun usaha luas di dalam Unit Program yang menguji ( lihat sesi 8.1.3).

7.3.2 Bundel Audit Unit Pengembangan (Unit Development Folder Audits)

Bundel Unit Pengembangan (Unit Development Folder (UDF)) karena suatu unit program harus ditinjau oleh organisasi penjamin kualitas dan programmer yang bertanggung jawab untuk unit program sebelum submittal unit program ke pengendalian konfigurasi. UDF harus ditinjau untuk memverifikasi kelengkapan dan kesetiaan untuk menetapkan standard. Perhatian khusus harus dibayarkan kepada Unit yang menguji Perencanaan/ Prosedur / Hasil (Plan/Procedures/Results) untuk meyakinkan pengujian cukup pada tingkatan ini (lihat sesi 8.1.3). Dokumentasi yang diperbaharui mungkin adalah kritis untuk implementasi yang benar dari unit program yang lain. Oleh karena itu, UDF harus disampaikan ke pengendalian konfigurasi dan yang tersedia untuk semua orang atas proyek pada waktu yang bersamaan bahwa unit program disampaikan ke pengendalian konfigurasi.

7.2 DAFTAR TAHAP IMPLEMENTASI DAN OPERASI (IMPLEMENTATION AND OPERATION PHASE CHECKLIST)

Daftar nama yang berikut menyediakan suatu ringkasan mengenai pokok-pokok informasi yang harus tersedia dan menyetujui di Implementasi Dan Tinjauan ulang Tahap Operasi.
Rancangan Internal Tinjauan ulang disain modul tinjauan ulang itu yang diperlukan untuk menyediakan informasi daftar nama di dalam sesi 6.4. Tinjauan ulang itu di mana kode nyata perlu ditinjau juga memverifikasi yang berikut:

1. Bahwa masing-masing unit program didahului dengan informasi yang berisi paling sedikit sebagai berikut:
   a. Nama.
   b. Programmer.
   c. Tujuan Dan Uraian pengolahan yang dilakukan oleh unit program.
   d. Uraian data untuk diproses.
   e. Menghubungi struktur dan parameter yang lulus.
   f. Antarmuka eksternal.
   g. Sejarah Revisi.
2. Bahwa ada komentar cukup di dalam badan kode untuk menguraikan pengolahan itu dilakukan, keputusan termasuk komentar tiap-tiap area kode yang melibatkan suatu arah perubahan yang sedang dikerjakan.
3. Struktur Pengendalian yang bisa diterima itu digunakan, mempunyai batasan-batasan tergambar jelas, dan tidak digelapkan oleh yang berkomentar.
4. Itu adalah unit program mempunyai masukan tunggal dan keluaran tunggal.
5. Istilah Dan Notasi yang seragam itu digunakan untuk menyediakan konsistensi dan mengambil alih kemampuan melacak kebutuhan ke unsur-unsur piranti lunak.
6. Bahwa integritas tentang data dirawat bersama.
7. Bahwa kode adalah suatu terjemahan akurat yang dibutuhkan dan mendokumentasikan disain UDF.

Jika suatu Tinjauan ulang Disain Internal yang mencakup suatu kode perjalanan keliling telah diadakan untuk suatu unit program, Bundel Audit Unit Pengembangan terdiri dari materi tinjauan ulang yang mengecek di IDR dan suatu pass akhir sampai UDF untuk memverifikasi kelengkapan. Cara lainnya, tinjauan ulang suatu kode, yang memanfaatkan daftar nama di atas, harus dilakukan sepanjang audit UDF. Materi yang berikut harus dicek untuk memverifikasi kelengkapan UDF:

1. Semua bagian hadir dan dengan jelas mengenali.
2. Bahwa UDF berisi semua dokumentasi yang terkait dari Spesifikasi Persyaratan Piranti lunak (didapat dari acuan), fungsional dan Dokumen Disain Rinci, Menghubungkan Dokumen Pengendalian (didapat dari acuan), dan Dokumen Instruksi Operasi.
3. Bahwa semua dokumentasi telah menjadi red-line seperti yang diperlukan untuk mencerminkan perancangan kode yang diuji.
4. Bahwa unit pengujian dokumentasi membuat puas yang menyerahkan daftar nama sesi 8.4.
5. Bahwa semua Laporan Masalah Piranti lunak yang berhubungan dengan unit program ini tertutup.

Daftar nama untuk Prosedur Test Tinjauan ulang disampaikan dalam sesi 8.4, bersamaan dengan menguji daftar nama adalah bagian terbesar Tinjauan ulang Penerimaan Piranti lunak. Daftar nama untuk tinjauan lain item di SAR, seperti dokumentasi, yang ditemukan pada bab berhubungan dengan dokumen itu.

Referensi

Bob Hughes and Mike Cotterell, 2002, Software Project Management, McGraw Hill, London.
Philip Bruce, Sam M. Pederson, 1982 The Software Development Project, John Wiley and Sons, New York.
Steve McConnell, 1996, Rapid Development Taming Wild Software Schedule, Microsoft Press, Washington.Tumar, 2002, Information System Strategic, Universitas Bina Nusantara, Jakarta.