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.