TAHAP RANCANGAN RINCI

TAHAP RANCANGAN RINCI

oleh: Tumar

Tahap utama proses pengembangan piranti lunak adalah Tahap Rancangan Rinci (Detailed Design Phase). Tujuan (goal) utamanya pada tahap ini adalah sampai pada dikembangkan dan didokumentasikan suatu rancangan rinci program untuk lengkapnya sub sistem piranti lunak sampai membentuk garis dasar untuk implementasi piranti lunak. Titik kuncinya di sini, dan barangkali titik kunci seluruhnya pada buku, itu adalah terdapat rancangan program pertama. Rancangan program akan disertai oleh lengkapnya dokumentasinya.
Tingkat dokumentasi rancangan diharuskan pada langkah ini yaitu proses pengembangan piranti lunak yang cukup untuk dokumentasi program pada produk akhir. Jika dunia itu adalah benar-benar, piranti lunak diimplementasikan adalah melahirkan suatu kesimpulan akan tepat cocok dengan deskripsinya Tahap Dokumentasi Rancangan Rinci dan, selanjutnya, dokumentasi ini akan mencukupi pada tingkat rinci sampai pada dukungan operasi dan pemeliharaan setelah program diserahkan. Ini manyatakan perancang program itu adalah bekerjanya benar-benar pada aliran program / individu subroutine tingkat logik dan dokumentasi ini pekerjaan yang cermat flowchart, program rancangan bahasa, atau beberapa metode dokumentasi logik yang lain, daripada ketelitian kode yang sebenarnya.
Sebagian besar perhatian bagian manajemen pada tahap ini sampai dengan dijalankannya syarat-syarat dokumentasi rinci tanpa pembelaan dan tanpa diskriminasi. Rancangan adalah Dokumentasi. Jika dokumentasinya lengkap atau tidak baik, kemudian rancangan tidak eksis, sungguhpun mungkin orang yang mempunyai ide banyak dan mungkin menghabiskan (banyak menghilangkan) jam bicara ini.
Bagian ini menggambarkan pada proses rancangan rinci, sekumpulan dokumentasi, dan tinjauan formal.


6.1 PROSES RANCANGAN RINCI (THE DETAILED DESIGN PROCESS)

Tahap Rancangan Rinci pada proses pengembangan piranti lunak konsisten dengan tiga dasar aktivitas yaitu :

1. Analisis
2. Rancangan Rinci Program dan,
3. Pre-CDR coding.

Waktunya relativ pada aktivitas ini yang diilustrasikan dalam Gambar 7.1. Untuk scientific, program komputer analisis tinggi, yang overlap tugas analisis dengan rancangan rinci program mungkin dipertimbangkan lagi dari ilustrasi dalam gambar. Untuk program logik-oriented dengan tidak kritisnya sumber problem, tahap analis mungkin kosong. Rancangan rinci pada struktur kontrol program, masukan/keluaran rutin dan beberapa pemrosesan rutin dapat diproses saat analisisnya lengkap.

Obyektiv tekniknya untuk Tahap Rancangan Rinci adalah untuk kelengkapan dan tinjauan rancangan pada programprogram komputer, dan program komputer antar muka. Penambahannya obyektiv untuk kelengkapan dan tinjauan rancangan dan memulai coding sebagai dukungan piranti lunak, dan sedikit pemodelan piranti lunak harus untuk mendukung aktivitas rancangan rinci.

6.1.1 Analisis
Aktivitas analisis termasuk di dalamnya adalah :

• persamaan atau alogaritma ,
• analisis isi basis data,
• menyelesaikan analisis,
• data storage dan analisis acces, dan
• rancangan analisis piranti lunak,

Persamaan atau alogaritma asal tugasnya pada aktivitas analisis konsis terhadap yang tercantum di bawah ini yaitu :

• scientifik
• matematik, atau
• analisis numerik,

Tugasnya harus sampai menentukan persamaan yang tepat atau alogaritma untuk diimplementasikan dalam tugas rancangan rinci program. Ini adalah satu pada segolongan kecil tugas dalam proses pengembangan piranti lunak yang mempunyai pendekatan tradisional pada masa lalu dengan digunakannya konsep yang ditampilkan dalam buku ini. Itu adalah sebagai berikut :

1. Definisi problem,
2. Pekerjaan yang dikerjakan sampai penyelesaian definisi (teknik memperoleh nya atau persamaan),
3. Penyelesaian dokumentasi dan tinjauan oleh para ahli dalam field,
4. Analisis ujicoba diselesaikan atau dengan simulasi, dan
5. Penyelesaian akhir direalisasikan untuk implementasi piranti lunak.

Biasanya, teknik khusus atau alogaritma tugasnya adalah memanaj yang baik dan tinjauan. Setelah, grup khusus berdedikasi untuk menganalisis, dan bilamana mereka mempunyai kesulitan kelengkapannya beberapa waktu dan pekerjaannya kompleks, hasil kode-nya mungkin sama kecilnya dengan segolongan kecil instruksi. Jika kesalahan terjadi dalam analisis, ini adalah seringkali dikoreksi dengan merubah sebuah intruksi tunggal, atau sekumpulan instruksi kecil, yang mana minimal kekacauan pada proses pengembangan program komputer. Bagaimapun, jika dasar pemikirannya yang mana dalam menganalisisnya dasarnya tidak tepat, seluruh konsep rancangan piranti lunak memungkinkan untuk dirobah. Untuk sebab ini, Tinjauan Rancangan Awal (The Preliminary Design Review / PDR) termasuk didalamnya tinjauan lengkap dasar analitis untuk konsep rancangan sebelumnya lebih dulu sampai kinerjanya analisis rinci dan rancangan program rinci. Untuk teknik pemrosesan data yang kritis atau alogaritma, protipe kode mungkin dikembangkan untuk evaluasi ujicoba alogaritma sampai verifikasi rancangan alogaritma sebelumnya untuk kelengkapan rancangan rinci pada langkah dalam proses verifikasi rancangan.
Selain tugas analisis lainnya lagi langsung berhubungan sampai piranti lunak diimplementasikan dan diperlukan untuk verifikasi tinjauan konsep rancangan pada PDR dapat diimplementasikan sebagai usulan.

• Termasuk didalamnya penelitian pengaturan waktu analisis basis data,
• Acces constraints,
• Format problem,
• Penanganan kesalahan-kesalahan, dan
• Didapatkannya kembali keistimewaan rancangan untuk mendukung pengimplementasian konsep PDR pada proses rancangan rinci.

Aktivitas analisis juga termasuk analisis rinci sistem yang teliti, dan sedikit tambahan tugas analisis rancangan piranti lunak itu mungkin harus untuk mendukung aktivitas program rancangan rinci.

6.1.2 Rancangan Rinci Program (Detailed Program Design)
Rancangan rinci program adalah proses rancangan pengembangan lengkap dan deskripsi operasional setiap program komputer, sampai tingkat subroutin, dasar pada konsep rancangan diperlihatkan dalam Fungsional Dokumen Rancangan. Rancangan dan deskripsi operasi, diperlihatkan dalam bentuk Dokumen Rancangan Rinci (Detailed Design Document), adalah Tinjauan Rancangan Kritis (Critical Design Review / CDR). Pemilihan komputer dan bahasa program, sebagai struktur dasar pengembangan piranti lunak dan konsep operasi, dan rancangan piranti lunak antarmuka semuanya adalah PDR lebih dulu. Sisanya rancangan diupayakan terfokus pada rancangan eksekusi elemen pada modul program dan penggunaan operasionalnya rinci.
Proses rancangan rinci mungkin menggunakan teknik pemodelan untuk penyelesaian analisis rancangan kritis, antar muka data flow diagram untuk memastikan diantara kesesuaian program komputer eksekusi elemen, Kontrol Dokument Antarmuka (Inteface Control Dokument) untuk pengontrolan antarmuka eksternal, komputer sumber teknik manajemen untuk pengontrolan komputer sumber penyimpanan (resources of storage) dan kapasitas komputasinya, dan rancangan teknik integrasinya untuk menjamin kontinyuitas rancangan. Setelah teknik rancangan sistem, yang akan didiskusikan pada paragrap berikutnya, pekerjaannya dan hasil evaluasinya, setiap rancangan eksekusi elemen sampai model laporan untuk sebuah titik yang menjamin rancangan modul itu refleks seluruhnya harus diberikan fungsinya untuk ini. Rancangan digambarkan teliti logik flow diagram rinci, rancangan bahasa program, atau dokumentasi logik yang lainnya.

Rancangan Antar Muka
Rancangan Awal Dokumen Kontrol Antarmuka (Preliminary Interface Control Document / ICDs) pada PDR berisi deskripsi rancangan rinci piranti lunak antarmuka eksternal. Dokumen ini mungkin termasuk didalamnya alogaritma dan persamaan, sebagaimana berisi data pesan khusus, rate dan format. Alogaritma dan persamaan dalam ICD adalah syarat-syarat untuk piranti lunak dan harus diimplementasikan dalam rancangan rinci modul pertama.
Selama rancangan rinci piranti lunak, biasanya adalah beberapa iterasi khusus pada rancangan antar muka. Untuk alasan ini, ICD diterbitkan lagi dalam tahap ini dalam format final. Dengan jelas selama proses rancangan perubahan proposal untuk rancangan awal antar muka yang akan dikoordinasikan dengan bertanggung jawab untuk sistem rancangan elemen dalam setiap sisi pada nodifikasi antarmuka.

Pemodelan Piranti Lunak
Sistem piranti lunak mempunyai banyak syarat-syarat, sebagaimana waktunya harus tepat, itu adalah kesulitan untuk diimplementasikan dan untuk kesulitan ini yang mana rancangan itu diverifikasi hingga memadai. Dalam kejadian itu solusi rancangannya tidak dapat dievaluasi secara lengkap dengan cara analitik, ini mungkin perlu dibuktikan kecukupan dan kelayakan rancangan proposal menurut model. Hasil pemodelan dan analisis ini adalah bagian proses rancangan rinci.
Pemodelan konsisten pada percobaan berfungsinya coding sampai evaluasi dan contoh yang representatif pada elemen antar muka tidak wajib untuk membuktikan pertanyaan penyelesaian rancangan. Bilamana komputer me-load adalah satu jenis dalam pertanyaan, contoh kode elemen yang tampilannya diharapkan memori dan prosessor men-load produk akhir. Parameter kontrol adalah termasuk di dalamnya itu juga yang bervariasi berpengaruh kuat dalam memuat estimasi yang dapat dievaluasi. Hasil pemodelan adalah digunakan sampai penyelesaian proposal rancangan dibuktikan dan memberikan manfaat yang melekat dan perkiraan waktu.

Rancangan Pengoperasian Piranti Lunak
Penggunaan dan pengoperasian piranti lunak harus diakhiri selama tahap ini. Informasi ini, termasuk didalamnya seluruh operator / pemakai antarmuka, waktu itu perusahaan di dalam rancangan pada elemen piranti lunak cocok. Rancangan aktivitas ini dukungan alamat pada kedua permulaan dan pengoperasian program komputer.
Permulaan termasuk di dalamnya aktivitas piranti lunak, pelaksanaan kontrol, dan pengoperasian yang mem-backup konfigurasi. Rancangan operasi termasuk di dalamnya definisi rinci pada seluruh interaksi dengan orangorang yang menggunakan pirantai lunak, termasuk didalamnya anatara lain :

• Format display
• Command input,
• Pembatasan Operasi, dan
• Error conditions.

Operasi ini dipertimbangkan oleh perusahaan termasuk di dalamnya rancangan piranti lunak. Prosedur rinci untuk operasi dan penggunaan piranti lunak adalah suatu dokumen pada awal Dokumen Instruksi Operasi, yang mana diberikan pada tahap selanjutnya.

Rancangan Rinci Piranti Lunak
Pada hasil dasar aktivitas analisis, memperoleh syarat-syarat dari ICDs, dan hasilnya piranti lunak aktivitas pemodelan, rancangan rinci pada setiap modul adalah dikembangkan. Pada tingkat ini rancangan termasuk logik flow didokumentasikan untuk seluruh tingkatan piranti lunak, termasuk seluruh sub routinnya. Logik flow memberi definisi antara lain pada :

• All bracnch points,
• Processing iteration,
• Entry points,
• Recovery logic, dan
• External storage access and usage.

Untuk seluruh subroutine, argumentasi rangkaian pemanggilannya, beranggapan, berinteraksi dengan subroutine yang lain, data dan kontrol antar muka, pembatasan, dan batas-batasnya adalah telah digambarkan. Rancangan informasi ini adalah didokumentasikan dalam Dokumen Rancangan Rinci. Peralatan ini bermanfaat dalam persiapan rancangan rinci adalah data flow diagram dan komputer sumber manajemen.

Data Flow Diagram
Data Flow Diagram adalah bermanfaat sebagai alat dalam pengembangan pada rancangan rinci, terutama sekali bilamana beberapa perancang piranti lunak adalah termasuk di dalam proses rancangan rinci. Data flow diagram akan dikembangkan untuk setiap tingkatan dalam hirarkhi piranti lunak sampai memungkinkan data elemen antar muka apa saja (input/output) sampai menemukan untuk berkolaborasi atau penggunaan subroutine. Data elemen antarmuka ini berbeda-beda dengan aplikasinya, tapi biasanya mereka adalah :

• Data routes,
• Quenes,
• Buffers, tables,
• Data sets,
• Data files, dan juga dalam pemakaiannya sampai pengumpulan,
• Transfer dan
• Store data.

Keperluan, data flow diagram biasanya adalah dipersiapkan dalam lembaran kertas yang luas, itu juga seluruh garis edar data flow dan subroutine dapat diperlihatkan. Diagram akan mengetahui pada kegagalan dalam wilayah proyek dan akan familier penggunaannya pada umumnya untuk setiap perancang piranti lunak. Data flow diagram adalah digunakan sebagai gambaran dalam Dokumen Kontrol Antarmuka (Interface Control Document) dan dokumen rancangan dikembangkan selama tahap ini. Gambar 7.2 diperlihatkan sebuah contoh data flow diagram.

Komputer Sumber Manajemen
Proses rancangan rinci memerlukan pengawasan perkiraan memori dan storage eksternal, channel data dan kapabelitas komputasinya, dan syarat-syarat terakhir perkiraan untuk setiap sumber ini. Waktu dan ukuran perkiraan untuk program dan ukuran dan access rates untuk data harus tetap dijaga dan diperbarui setiap saat. Ini harus sangat konsisten dibandingkan terhadap :

• memori yang ada,
• on-line storage,
• execution speed, and
• data channel capabilities,

Jika batasan pendekatan, tindakannya korektiv harus diberikan. Syarat-syarat cadangan harus dipertimbangkan dalam menentukannya jika tindakan korektiv diperlukan. Tindakan ini mungkin termasuk restrukturisasi pada elemen eksekusi, database, atau konsep operasi, atau pertambahan pada sumber yang tersedia. Komputer merupakan sumber manajemen adalah bagian yang harus diperhatikan pada proses rancangan rinci. Sumber ini akan berpengaruh kuat pada faktor utama yang berbagai macam akan dipertimbangkan alternatif rancangan rinci.

Dukungan Rancangan Piranti Lunak
Dalam perhatian elemen pada rencana pengembangan piranti lunak adalah sebagai definisi yang diwajibkan fasilitas pengembangan piranti lunak. Ini tidak termasuk hanya khusus fasilitas perangkat keras komputer antara lain :

• tape drives,
• extra disk, or
• printres, or
• extra terminal tidak termasuk dalam konfigurasi operasi komputer.

Ini mungkin termasuk :

• assembler,
• compilers,
• precompiler,
• database generasi piranti lunak,
• simulator lingkungan,
• interprestasi simulator komputer,
• test data generasi program,
• test data program pengurangan, dan
• tambahan perbaikan, sebagaimana melimpahkan dan menemukan kapabelitasnya.

Selama tahap ini, rancangan rinci pada dukungan elemen harus komplit dan, dalam sebagain terbesar kasus, tinjauan dan persetujuan untuk coding utama samapa CDR. Ini adalah kebutuhan dalam perintah untuk mempunyai dukungan verifikasi piranti lunak dalam waktu untuk mendukung code dan test pada piranti lunak yang dihasilkan.

Rencana Test/ UjicobaPerencanaan akhir untuk apa piranti lunak akan dites / uji coba adalah dikembangkan untuk diprsentasikan pada CDR. Perencanaan secara rinci akan dibahas dalam bab selanjutnya.

6.1.1 Pre-CDR Coding

Pertemuan dalam rangka jadual pengembangan, itu secara normal diperlukan untuk memulai codingyang memilih unsur-unsur perangkat lunak utama ke CDR. Elemen di mana ini adalah dilaksanakan harus secara hati-hati memilihnya dan harus tidak mengecualikan CDR itu jenis keamanan disain. Mungkin saja yang diinginkan pada unsure dokumen ini di dalam suatu pemisahan Dokumen Disain Rinci untuk meninjau ulang pada suatu awal mini-CDR diadakan untuk tinjauan ulang perancangan unsur-unsur ini, yakni pengembangan yang mendukung dan menguji perangkat lunak. Tambahan rutin, seperti kegunaan, boleh juga dipertimbangkan untuk awal coding.

Pre-CDR Coding harus diperlakukan kepada proyek dan pertimbangannya bahasa program sama yang memprogram standard sebagai sisa dari kode itu. Itu sangat penting bahwa komentar yang tertulis dengan kode untuk mengijinkan jejak kemampuannya mudah dari daftar lis kembali ke arus logika itu.


6.2 DOKUMENTASI TAHAP RANCANGAN RINCI (DETAILED DESIGN PHASE DOCUMENTATION)

Seperti ditunjukkan pada gambar 6.1, produk memerinci perancangan proses pengembangan piranti lunak/software adalah tiga dokumen, diuraikan di bawah. Indeks yang terperinci dari tiap dokumen yang berikut mungkin adalah ditemukan Apendix B.

6.2.1 Pengendalian Dokumen Antarmuka ( Akhir).

Pengendalian Dokumen Antarmuka memproduksi sepanjang Tahap Disain Awal diuraikan pada bab 5 diselesaikan tahap ini dan yang dikirimkan format akhir.

6.2.2 Membaharui Dokumen Rancangan Fungsional.

Dokumen Rancangan Fungsional mengembangkan Tahap Rancangan Awal yang harus diperbaharui terhadap perubahan apapun yang direfleksikan di dalam disain tingkat puncak yang terjadi sepanjang pengembangan disain rinci itu.

6.2.3 Dokumen Rancangan Rinci

Mengukur disain Piranti lunak tingkat tinggi yang memperkenalkan Dokumen Rancangan Fungsional yang diperbaharui diperluas untuk suatu disain tingkatan coding di dalam Dokumen Disain Rinci untuk Tinjauan ulang pada Tinjauan ulang Rancangan Kritis. Isi, Tinjauan ulang, Persetujuan, dan kebutuhan kendali untuk dokumen ini atau satuan dokumen diperkenalkan gambar 6.3. Dokumen Disain Terperinci estalishes suatu terperinci (" membangun untuk") mendisain dari yang mana kode akan jadi dihasilkan. Disain Yang terperinci Dokumen harus:

1. Memperbaharui dan memperluas disain itu baseline menetapkan pada PDR, mencakup detil operasi program dan pngendalian dan penggunaan dari data umum. Disain rinci harus diuraikan sampai subroutine tingkat organisasi perangkat lunak (yaitu., field atau tingkatan bit, yang sesuai). Mengacu pada Dokumen Disain Fungsional yang diperbaharui untuk ikhtisar disain informasi.
2. Bertahan pada struktur dasar pengendalian itu menyiapkan dalam bentuk standar programming yang digambarkan pada Proyek yang direncanakan.
3. Menekankan secara detil pada pemilihan waktu, penyimpanan, dan ketelitian
4. Mengalokasikan fungsi kepada masing-masing unsur perangkat lunak pada tingkatan masing-masing hirarki piranti lunak ( modul, unit program, subroutine), dengan suatu uraian bagaimana subroutine dan unit program beroperasi memenuhi fungsi yang dialokasikan ke masing-masing modul.
5. Menyediakan uraian disain rinci dari tiap unit program pada setiap modul, termasuk yang berikut ini:

• Uraian Fungsional. Apa yang dikerjakan unit program.
• Pemakaian. Pemanggil yang berurutan dan / atau prosedur operasi, maksud pesan atau hasil print komputer, kesalahan mengembalikan atau stop dan tindakan yang sesuai, dan keluaran atau masukan khusus yang menonjolkan atau kebutuhan operasi.
• Pemakaian Subroutine. Mengidentifikasi dari semua subroutines yang dipanggil oleh unit program.
• Masukan. Uraian yang terperinci dari semua data eksternal, data base, dan operator atau perangkat keras antarmuka masukan, mencakup pengendalian kata, format yang terperinci, pilihan, pemilihan waktu, dan seterusnya, baik eksplisit maupun oleh referensi bagi lain dokumen.
• Keluaran. Uraian yang terperinci dari semua keluaran, mencakup pilihan, format, batas, pemilihan waktu, dan seterusnya.
• Metoda Pemrosesan. Uraian dari semua matematika dan proses logika yang digunakan. Presentasi harus di dalam urutannya bahwa programming yang nyata akan mengambil dan perlu menggunakan konsep disain informasi itu Dokumen fungsional, Acuan, untuk metoda yang dikerjakan. Aliran Logika dipresentasikan (diagram alir, proses aliran, atau bahasa disain) yang digunakan untuk menguraikan proses aliran yang detail yang jelas untuk seorang programmer yang berpengalaman dengan kode unit program. Arus Logika meliputi atau acuan persamaan apapun yang digunakan dan mengidentifikasi semua titik cabang, memproses perkataan berulang-ulang, poin-poin masukan, recovery logika, dan menyetujui penyimpanan eksterna dan pemakaiannya. Toleransi Ketelitian yang tidak bisa dipisahkan di dalam model matematika atau pengolahan kuantitatip dan yang membangun dari implementasi teknik itu seharusnya ditetapkan.
• Pembatasan. Pembatasan Unit Program, seperti batas pada volume atau tingkat tarip perpindahan untuk memasukan atau data keluaran, komponen perangkat keras minimum yang diperlukan, ketelitian dan pembatasan logika, kesalahan tidak memeriksa buat (bila ada), kondisi-kondisi yang harus dicukupi sebelum eksekusi program itu.
• Ukuran Dan Perkiraan Pemilihan waktu. Kebutuhan Sumber daya Unit Program, kedua-duanya kode dan data, untuk digunakan sebagai basis untuk perkiraan program komputer dan subsistem piranti lunak yang diperbaharui.
• Uraian Subroutine. Definisi jenis informasi yang sama ketika ditetapkan di atas untuk unit program untuk masing-masing subroutines yang digunakan oleh sejumlah unit program untuk masing-masing subroutine yang dirancang sebagai suatu elemen unit program.

6. Menyediakan uraian disain rinci untuk kegunaan subroutines yang digunakan oleh sejumlah unit program. Uraian ini perlu menyediakan informasi yang sama seperti yang ditetapkan item 5 untuk unit program dan mereka subroutines.
Daftar dari semua program komputer yang diuraikan dalam dokumen yang ditambahkan sebagai suatu catatan tambahan ketika dokumen diperbaharui yang mencerminkan konfigurasi yang terakhir di dalam tahap yang berikutnya. Proses ini diuraikan bab 8.

Suatu indeks tabel contoh untuk suatu Dokumen Rancangan rinci ditunjukkan gambar 6.4. Dokumen Rancangan fungsional, yang digambarkan bab 5, yang menyediakan keseluruhan struktur program komputer, modul mengukur uraian, dan modul yang menghubungkan definisi. Menyediakan uraian rancangan rinci dari tiap unit program pada setiap modul. Karena program komputer besar, mungkin saja yang diinginkan pada pemisahan dokumen untuk menguraikan modul masing-masing. Ini juga kadang-kadang diinginkan pada pemisahan informasi data base di dalam suatu Dokumen Rancangan Data Base. Pendekatan Umum yang lain adalah pada pemisahan semua aliran logika yang disajikan dalam volume lain, teks yang dikunci dengan sejumlah bagian. Teknik ini mengijinkan pembaca untuk mempunyai volume kedua menyertai, itu membuat lebih mudah untuk menghubungkan prosa itu ke logika. Juga, pembaca tidak menginginkan untuk memasuki logika detil yang mempunyai lebih sedikit kerumitan dan lebih mudah untuk mengikuti volume yang akan bekerja bersama.

6.2.4 Menguji Dokumen (Test Document)

Versi terakhir Pengujian Rencana diproduksi sepanjang Tahap Rancangan rinci. Dokumen ini, Yang telah dimulai sepanjang Tahap Rancangan Pendahuluan, adalah digambarkan secara detil di dalam) bab 9.

6.3 TINJAUAN ULANG TAHAP RANCANGAN RINCI (DETAILED DESIGN PHASE REVIEWS)

Sepanjang Tahap Disain Rinci , perancangan piranti lunak meningkatkan, puncaknya adalah suatu rancangan rinci yang terakhir. Untuk mendukung proses ini, dua jenis tinjauan ulang dilaksanakan pada tahap ini: Tinjauan ulang Rancangan Internal dan Tinjauan ulang Rancangan kritis. Tinjauan ulang ini dibahas bagian yang berikut.

6.3.1 Tinjauan ulang Rancangan Internal (Internal Design Reviews-IDR))
Seperti disain program komputer secara keseluruhan dewasa ini dan fokus individu lebih secara intensif pada perancangan modul mereka sendiri, itu terjadi terus meningkat sukar untuk menyimpan suatu perspektif sistem. Sebagai tambahan, aliran informasi tentang antarmuka modul dan teknik yang bermanfaat menjadi lebih sedikit efektif pada basis khusus (untuk suatu maksud).
Dalam rangka menunjuk permasalahan di atas , proyek perlu menjaga satu rangkaian Tinjauan ulang Rancangan Internal (IDRs). Suatu IDR adalah suatu presentasi informal yang memusat pada suatu area khusus rancangan, apakah modul, antarmuka, atau keseluruhan kemampuan program komputer. IDR perlu menyediakan suatu pandangan konseptual ringkas area sedang dalam pembicaraan dan presentasi tentang segala teknik khusus atau yang melibatkan corak khusus. IDR tidak pernah melibatkan lebih dari satu atau dua jam persiapan atau mendorong kearah lebih dari setengah jam tinjauan ulang yang sebenarnaya. Semua anggota proyek harus diundang, tetapi kehadiran biasanya dipilih, kecuali itu secara langsung terkait dengan material tinjauan ulang. Tinjauan ulang bukanlah suatu test atau suatu demostration, hanyalah suatu presentasi potongan piranti lunak: itu adalah tujuan, struktur umum, dan arus yang menyatakan seperti dilihat oleh orang yang bertanggung jawab ciptaannya. Itu tidak pernah menjadi rancangan dengan sesi komite, walaupun permasalahan yang harus ditujukan di luar tinjauan ulang itu boleh dikemukakaan. dengan singkat, tujuan CDR adalah:

1. untuk memperkenalkan semua anggota staff dengan keseluruhan struktur piranti lunak.
2. untuk menunjukkan teknik yang ditemukan untuk bisa efektip di dalam proyek (terutama penggunaan peralatan perangkat keras), dan
3. untuk menjelaskan permasalahan khusus dan pertimbangan, menyatukan pengetahuan dari semua anggota proyek.

6.3.2 Tinjauan ulang Rancangan Kritis. (Critical Design Review(CDR))

Seperti ditunjukkan gambar 7.1, Tahap Rancangan Rinci proses pengembangan piranti lunak memuncak dengan Tinjauan ulang Disain Kritis (CDR). CDR adalah suatu format tinjauan ulang teknis disainnya. Itu diselenggarakan ketika rancangan rinci untuk piranti lunak diselesaikan dan Dokumen Rancangan Rinci adalah siap untuk disampaikan. Kebenaran Tinjauan ulang Rancangan Kritis mendisain ketercukupan. Untuk memenuhi verifikasi rancangan itu, material yang berikut harus tersedia untuk penulis resensi buku sebelum CDR pertemuan yang dijadualkan adalah :

1. Dokumen Rancangan Fungsional Yang Diperbaharui.
2. Dokumen Rancangan Rinci.
3. Spesifikasi Kebutuhan Piranti lunak.
4. Hubungkan Dokumen Pengendalian.
5. Perubahan yang dirundingkan ke Spesifikasi Kebutuhan Poranti lunak dan Dokumen Pengendalian Antarmuka yang dihubungkan.
6. Versi yang akhir versi Rencana Test piranti lunak.
7. Disain evaluasi atau studi perdagangan menghasilkan.
8. Perkiraan Capaian yang diperbaharui.

Dokumentasi tinjauan ulang sebelum CDR dan didiskusikan pada CDR perlu memenuhi yang berikut:

1. Tinjauan ulang Rancangan Rinci. Tinjauan ulang ini perlu menetapkan bahwa rancangan rinci yang dicerminkan Dokumen Rancangan Rinci membuat puas kebutuhan Spesifikasi Kebutuhan Piranti lunak.
2. Tinjauan ulang Kecocokan Sistem. Penulis resensi buku perlu membandingkan semua diagram blok terperinci, menurut bagan, dan diagram logika dengan Dokumen Pengendalian Antarmuka (dan Dokumen Uraian Antarmuka Sistem, jika tersedia) untuk menentukan kecocokan sistem.
3. Tinjauan ulang Perubahan Rancangan. Tinjauan ulang ini perlu mempertimbangkan semua perubahan pada Spesifikasi Kebutuhan Sistem dan Dokumen Antarmuka setelah Tinjauan Ulang Rancangan Pendahuluan yang benar bahwa rancangan cukup mencerminkan perubahan itu. Tinjauan ulang perlu mempertimbangkan rancangan fungsional, sebagai dokumentasi Dokumen Rancangan fungsional dan disetujui PDR, untuk memastikan bahwa perubahan dalam rancangan dapat diterima tingkat puncak.
4. Tinjauan ulang Verifikasi Perencanaan. Tinjauan ulang ini perlu meliputi suatu evaluasi Rencana Test piranti lunak untuk kelengkapan dan ketercukupan teknis ( lihat bab 9).

Tinjauan ulang Rancangan Kritis yang biasanya terdiri dari suatu presentasi paling sedikitnya topik yang berikut:

1. Suatu ikhtisar rancangan terperinci, mengidentifikasi struktur piranti lunak, alat penghubung komponen dan interaksi, pendukung dasar pemikiran disain, operasi piranti lunak di dalam lingkungan sistem, dan uraian pemakai terinci dihubungkan.
2. Suatu ikhtisar implementasi dan rencana test.
3. Revolusi dari isu sesuai kontrak dan teknis yang kritis, mendorong ke arah suatu persetujuan dengan pelanggan untuk meneruskan tahap coding dan bagi suatu persetujuan program test.

Karena suatu piranti lunak yang kompleks besar dirancang, CDR kadang-kadang menyelenggarakan suatu basis progresive, dengan modul atau program komputer individu yang ditinjau dan otorisasi yang diwarisi untuk meneruskan implementasi dan menguji pada satu rangkaian pemisahan tinjauan ulang. Kepedulian harus diambil bahwa perancangan modul yang bisa tiang kapal bukanlah ketergantungan pada perancangan modul-modul untuk ditinjau pada suatu tanggal kemudiannya.

6.4 DAFTAR NAMA TAHAP RANCANGAN TERPERINCI. (DETAILED DESIGN PHASE CHECKLIST)

Daftar nama yang berikut menyediakan suatu ringkasan yang mengenai pokok-pokok informasi yang harus disetujui dan tersedia pada bagian akhir Tahap Disain Rinci untuk mendukung implementasi yang berikut dan aktivitas test.

1. Kebutuhan Capaian dan rancangan antarmuka eksternal pada suatu tingkat detil yang cukup untuk membentuk basis itu untuk implementasi.
2. Alokasi kebutuhan yang terperinci kepada modul piranti lunak yang dirancang (membaharui PDR material, jika diperlukan).
3. Lingkungan Piranti lunak.

4. Piranti lunak mendisain detil.

• Suatu uraian tertulis dan memerinci spesifikasi fungsi dan capaian dari tiap modul.
• Suatu blok diagram yang mempertunjukkan struktur dari tiap modul piranti lunak hingga ke tingkatan algoritm.
• Diagram arus Modul atau suatu logika padanan mengalir uraian pada suatu suffisient tingkat detil untuk mulai persandian.
• Suatu blok diagram yang mempertunjukkan pemindahan data antar modul program dan modul program antar perangkat keras dan piranti lunak.
• Suatu definisi terperinci (uraian) tentang antarmuka pengndali antara penghembus masing-masing modul.
• Suatu definisi terperinci dari semua masukan dan keluaran untuk masing-masing modul, mencakup format data dan cakupan data valid.

5. Alokasi sumber daya (Perluasan PDR material; lihat item No 5 Bagian 6.4).
6. Struktur Data.

• Suatu definisi struktur data base dan semua file data lain dan antarmuka data.
• Rincian struktur dan perancangan data masing-masing memfile, itu adalah termasuk nama, asal, isi, panjang, metode akses, dan seterusnya.
• Suatu definisi dari tiap item atau kelompok materi di dalam data base, file data, atau data lain yang menghubungkan, mencakup item itu atau nama kelompok, definisi prosa, format, unit, dan pemakaian.

7. Prosedur Operasi.

• Prosedur rancangan rinci dan antarmuka data untuk operasi perangkat keras komputer, penggunaan sistem operasi, dan initialisasi serta pengendalian program komputer itu.
• Backup Rancangan rinci dan recovery konfigurasi dan prosedur.
• Prosedur Rancangan Rinci dan antarmuka data untuk menggunakan program komputer 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.