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.

TAHAP RANCANGAN PENDAHULUAN

TAHAP RANCANGAN PENDAHULUAN

oleh : Tumar

Tahap utama proses pengembangan piranti lunak adalah Tahap Rancangan Awal (Preliminary Design Phase). Pentahapannya mempunyai dua tujuan (goal) pertama yaitu :

1. Definisi job kinerjanya piranti lunak apa
2. Generasi pertama akan membuat bagaimana strukturnya piranti lunak sampai dengan kinerja jobnya.

Definis tugas piranti lunak itu adalah kinerjanya harus khas yang menamakan persyaratan definisi. Persyaratan definisi mempunyai dua dasar yang obyektiv yaitu:

1. Definisi persyaratan yang digunakan itu harus dipenuhi oleh piranti lunak sebagai sub sistem dan,
2. Persyaratan yang diperoleh menyatakan tidak langsung untuk piranti lunak yang mana adalah suatu kebutuhan sampai dengan digunakan persyaratannya memenuhi.

Untuk latihan “Suatu sistem akan memberikan ringkasan kronologis yang lengkap pada seluruh operator yang aktivitasnya berlebihan sebagian besar baru saja satu jam jangka waktunya dalam permohonan operator “ adalah digunakan persyaratan. Persyaratan piranti lunak yang sama adalah berasal : “Piranti lunak seluruh masukan/ input harus tersimpan dengan command key board dalam disk pada sebuah command file, yang menyebabkan penyimpanan adalah sekumpulan waktu pada setiap perintah, membersihkan perintah lama satu jam lamanya, dan memberikan perintah waktu print-out pada dasar command file pada operator masukan (input).
Tujuan (goal) kedua Tahap Rancangan Awal adalah sampai menghasilkan sebuah inisial struktur progran komputer sampai dengan kinerja yang ditugaskan. Ini adalah hubungannya awal rancangan program. Pekerjaan ini adalah kinerjanya perancang utama piranti lunak sampai dengan analisis rinci itu akan dipersyaratkan sampai rancangan dan implementasi sistem piranti lunak secara lengkap. Sejak perancang itu bekerja dari persyaratannya sendiri, rancangan awal membolehkan kesalahan, tapi pada sistem tingkat atas dipertimbangakan ( tersedianya memori, penyimpanan data, pewaktuan, masukan data dan kecepatan keluaran (output) serta sampai dengan komponen antar muka dan eksternal) akan bersatu padu. Belakangan ini akan diijinkan analisis rinci dan rancangan dikerjakan sampai dalam batas struktur dan pembatas, dengan demikian yang terkenal adalah subsistem piranti lunak yang realistis sanggup diimplementasikan. Oleh karena itu total sumber dapat dievaluasi secepatnya dalam tahap program, lebih dulu besar transaksinya waktu dan keperluan yang dipakai pada percobaan sampai penyelesaian problem dengan tidak cukup sumbernya atau tak dapat dipakai.
Proses rancangan awal, sekumpulan dokumen, dan tinjauan formal program adalah digambarkan berturut-turut dalam bagianbagian.

5.1 PROSES RANCANGAN AWAL (THE PRELIMINARY DESIGN PROCESS)
Tahap Rancangan Awal pada prose pengembangan piranti lunak konsisten terhadap dasar aktivitas-aktivitasnya antara lain :

1. Definisi persyaratan sistem
2. Definisi persyaratan piranti lunak dan
3. Rancangan awal sistem piranti lunak.

Gambar 5.1 Mengilustrasikan waktu yang relativ pada ke tiga aktivitasnya, dan tinjauan persyaratan sampai verifikasi hansilnya pada Tahap Rancangan Awal.
Rekayasa yang obyektiv pada tahap ini adalah sama sekali khusus persyaratan piranti lunak dan menetapkan rancangan konsep untuk piranti lunak yang sesuai dengan persyaratan ini.

5.1.1 Definisi Sistem Peryaratan (System Requirements Definition)
Definisi persyaratan sistem aktivitasnya konsisten pada analisis persyaratan dan sampai pada menentukan pelajaran kejuruan yaitu :

1. Fungsi sistem sampai kinerjanya,
2. Bagaimana fungsi yang baik sampai pada kinerjanya,
3. Bagaimana kemauan struktur sistem atau segmennya, dan
4. Alokasi persyaratan sampai pada segmen individu.

Hasil tugas ini didokumentasikan dalam Persyaratan Spesifikasi Sistem dan Segmen.
Pelanggan atau pemakai biasanya bertanggung jawab untuk persiapan spesifikasi salah satu dari dua ini langsung tepat atau sebagai kemajuan produk sistem pendidikan. Jika mendapakan sistem yang kompetitiv, spesifikasi ini adalah lazimnya persoalan biasa dengan Proposal Untuk Permohonan (Request for Proposal / RFP) yang mana prospektus penawaran kontraktor melanggar. Jika sistem dikembannya adalah internal, organisasi pengguna bertanggung jawab terhadap produksi Persyaratan Spesifikasi Sistem dan Segmen setelah grup pengembangan piranti lunak menjawab sampai evaluasi dan biaya keperluan implementasi piranti lunak. Seringkali sekolah membantu dari personil persyaratan sistem piranti lunak dan gambaran dalam definisi sistem kerjanya, produk gagasannya mantap tegasnya bukan sebuah produk piranti lunak, tapi adalah spesifikasi tingkat besar dari persyaratan piranti lunak akan dialokasikan. Piranti keras bervariasi dan piranti lunak meningkatkan kinerja pelajar kejuruan, definisi rangkaian operasionalnya dan ujian, dan persyaratan intesvigasi antarmuka, dan definisi konsep operasi. Interaksinya interactiv diantara pengguna dan perancang sistem yang terakhir pada taraf ini sewaktu-waktu acapkali hasilnya makin baik jike beberapa tingkat persyaratan fleksibel. Kuncinya sampai dengan interaksi ini, pada kursus, tidak sampai dibiarkan isu rancangan yang potensial dikemudikan persyaratan tingkat sistem, tapi agaknya sampai dengan kompromi itu diminta, pertama-tama, menerima pengguna yang membutuhkan dan, yang kedua, membiarkan kesempatan untuk solusi yang layak dalam proses rancangan awal.Persyaratan sistem analis aktivitasnya akan menganalisis proses the end to end untuk setiap individu sampai seluruh sistem segala. Fungsi eksekusinya sistematis aktivitas analisis sewakut-waktu terpenuhi dalam spesifikasinya kosong dan membuka beberapa persyaratan yang tidak konsisten. Fungsi analis akan memberikan diagram rinci dan deskripsi kata untuk setiap fungsi utama sampai kinerjanya. Analisisnya adalah tak terbatas hanya sampai dengan piranti lunak. Termasuk di dalamnya seluruh sistem dan persyaratan definisi harus untuk seluruh sub sistem. Sebagaimana mestinya pimpinan latihan sewaktu-waktu memberikan analisis end to end pada seluruh fungsi dan hubungannya dilihat dari dalam terintegrasinya piranti keras/ piranti lunak lingkungan operasinya.

Untuk latihan, mengambil proyek yang konsis yaitu pada kontrol pesawat terbang dari stasiun di darat sebagaimana membimbing pesawat yang akan mengikuti jejak dari bimbingan sub sistem dalam papan pada pesawat melalui seluruh sistem. Analisis fungsional akan dimulai dengan parameter bimbingan sampai dengan langkah-langkah yang teratur diberikan instrumennya dalam pesawat untuk mengukurnya. Kemauannya itu menghasilkan jejak data yang teliti dalam papan elektronik, sub sistem komunikasinya cermat, link transmisinya berakhir di darat, penerima di darat meneliti, di darat perlengkapan termasuk di dalamnya komputer diteliti. Disana ukuran data akan diproses dan output-nya akan dipersiapkan untuk program kumputer yang lain. Perintahnya itu lebih lanjut akan menghasilkan yang diproses komputer. Perintah di transmisikan akan berakhir pada sebuah perintah link sampai pesawat, menerima dan diproses oleh sub sistem dalam papan komunikasi, dan akhirnya oleh bimbingan sub sistem sampai memberikan koreksi yang tepat hingga kontrol pesawat.

Setiap organisasi engineer berpura-pura dalam memberikan contoh tersebut di atas yang digambarkanya data atau persyaratan fungsi sampai memuaskan ini adalah fakta-fakta pertanggung jawaban diantara relasi untuk organisasi yang lain itu. Fungsi frekuensi peristiwa , persetujuan operasi, dan setiap waktu kritis hubungannya dengan fungsi harus didefinisikan. Jadi, persyaratan tambahan tidak jelas kelihatan dalam spesifikasi untuk sub sistem yang pura-pura, sebaiknya persyaratan piranti lunak, boleh berasal dari fungsi sistem analis. Panambahan persyaratan waktu itu dicatat dalam Persyaratan Spesifikasi Sistem dan Segmen yang tepat.

5.1.2 Definisi Persyaratan Piranti Lunak
Bilamana tingkat besar spesifikasinya telah lengkap, maka dimulaiilah aktivitas definisi persyaratan piranti lunak. Aktivias ini yaitu intisari persyaratan piranti lunak dari spesifikasi dan penambahan persyaratan diperoleh secara rinci. Asal mulanya persyaratan piranti lunak adalah aktivitasnya kompleks yang memutuhkan partisipasi aktif dan kerjasamanya sistem dan personil piranti lunak, terus dengan yang lain rancangan yang dibikin-bikin dan dukungan staff personil. Yang pertama sumber persyaratan adalah spesifikasi tingkat besar digambarkan dalam Sesi 5.1.1. Dalam penambahan, rangkaian operasional analis, dan piranti keras komputer meempertim bangkan memberi masukan-masukan untuk aktivitas definisi persyaratan.

1. Persyaratan Analisis dan Alokasi
Seluruh piranti lunak besar fungsi persyaratannya harus mudah dikerjakan untuk spesifikasi tingkat besar selanjutnya. Ini persyaratan sistem umum yang diperluas pada aktivitas definisi persyaratan piranti lunak dengan memberikan definisi yang bersih fungsi dan kinerja parameternya untuk sub sistem piranti lunak.

2. Rangkaian Operasional Analis
Rangkaian Operasional Analis akibat fungsional persyaratan tingkat besar digambarkan Sesi 5.1.1 dan perluasannya dengan tingkat rendah yang rinci untuk digambarkan rinci fungsinya pada sistem dan piranti lunak. Perhatiannya untuk memperoleh persyaratan rinci selama relasi mereka untuk elemen sistem yang lain. Dalam kinerjanya rangkaian operasional analisis, perlakuannya akan dimulai dengan catatan hanya persyaratan, dan bukan rancangan.mungkin solusinya rancangan dapat dievaluasi pada sekenario operasionalnya belakangan, selama aktivitas rancangan.

3. Definisi Antarmuka
Identifikasi piranti lunak antar muka dan persyaratan antarmuka analisis syarat pendukung pada organisasi antar muka, sistem engineering, dan personil piranti lunak. Dimana insan operator adalah suatu pertimbangan dalam pengontrolan beroperasinya piranti keras dan piranti lunak, manusia mesin analisis antarmuka dan manusia faktor analisis dan rancangan tugas kinerjanya harus diperoleh dengan sekumpulan persyaratan piranti lunak. Fungsi kontrol, rangkaian operasional, dan persyaratan diperlihatkan untuk kinerja operator-operator jobnya harus didefinisikan.
Analisis antarmuka ini tugasnya adalah biasanya dpertanggungjawabkan personil rekayasa sistem dan seringkali kinerjanya tidak sampai dengan tahap rancangan adalah baik dalam perjalanan. Sejak persyaratan piranti lunak dihasilkan signifikan barangkali berpengaruh yang kuat pada rancangan piranti lunak, organisasi piranti lunak harus mendukung dan menganjurkan selekasnya dikerjakan dalam areal ini selama aktivitas definisi persayaratan piranti lunak.

4. Penyeleksian Penyelidikan / Studi Komputer
Pemilihan piranti keras komputer mestinya menjadi hak dalam aktivitas awal rancangan program, seperti didiskusikan dalam Sesi 5.1.3. Bagaimanapun piranti keras komputer adalah seringkali dipilih pertama untuk aktivitas persyaratan definisi piranti lunak untuk satu alasan atau yang lain ( e.g.., sudah tersedia piranti kerasnya, atau terlalu banyak kegiatannya). Kasus ini , tersedianya piranti keras yang kapabel dan sumbernya harus dianalisis dalam memperoleh persyaratan piranti lunak.

5. Verifikasi Persyaratan
Persyaratan itu diperoleh yang mana terhadap sub sistem piranti lunak benar akan diserahkan definisinya dalam persyaratan piranti lunak.
Produk yang utama definisi tugas persyaratan piranti lunak adalah Persyaratann Spesifikasi Piranti Lunak untuk setiap definisi, menyerahkan program komputer (seringkali menghubungi Konfigurasi Jenis Program Komputer atau KJPK) susunan sub sistem piranti lunak. Definisi spesifikasi pada persyaratan fungsi, kuantitatif persyaratan kinerjanya, persyaratan antar muka (seringkali referensi Spesifikasi Kontrol Antarmuka terpisah), dan verifikasi persyaratannya.

5.1.3 Program Rancangan Awal
Pada taraf Akhir Tahap Rancangan Awal adalah rancangan awal program, yang mana telah diperlihatkan dalam Gambar 5.1, waktunya overlap dengan aktivitas akhir persyaratan piranti lunak yang digambargak dalam Sesi 5.1.2. Selekasnya pada aktivitas rancangan awal ini adalah seringkali kesulitan selama issu rancangan terisolasi yang diperoleh dari issu persyaratan. Ketelitian harus diberikan selama dijamin rancangan informasi itu adalah tidak termasuk dalam persyaratan piranti lunak.
Rancangan awal program adalah proses pendefinisian struktur rancangan secara keseluruhan pada sub sistem piranti lunak dan tingkat program komputer. Proses ini termasuk di dalamnya pilihan sistem komputer, fungsi alokasi sampai modul program, definisi program komputer modul antarmuka, pengembangan konsep database, serta pengembangan rencana verifikasi. Aktivitas ini adalah diperlihatkan dalam Gambar 5.1 dan terus gambarannya.



1. Penyeleksian Sistem Komputer
Dalam banyak proyek, salah satu dari dua komputer, bahasa programming, atau keduanya adalah spesifikasi oleh pelanggan atau oleh pengembang piranti lunak dalam proposalnya. Komputer dan bahasanya seringkali signifikan yang berpengaruh yang kuat pada keseluruhan pengembangan piranti lunak biaya dan kemampuan ampai penyerahan piranti lunak masih dalam koridor schedule. Penyeleksian komputer dan bahasanya adalah dibuat selama pada bagian praproposal studi, proposal aktivitas rancangan, atau selama tugas rancangan awal secepatnya.
Beberapa pertimbangan utama dalam memilih sistem komputer adalah :

1. Persyaratan storage komputer
2. Komputasinya kapabel
3. Masukan / keluaran
4. Pertumbuhannya kapabel
5. Dukungan Bahasa Perintahnya tinggi
6. Tak berhenti dengan rancangan yang unik
7. Biaya
8. Waktu dan Ukuran Scehedule
9. Keistimewaan Sistem operasi piranti lunak
10. Dukungan pengembangan piranti lunak
11. Dukungan vendor

Prakiraan dalam syarat-syarat yang diperlukan komputer anatara lain : Storage, peed, masukan/keluaran kapabel, dan juga dalam langkah pertama dalam penyeleksian proses. Prakiraan harus berdasarkan pada keperluan analisis dan sebagai dasar konsep rancangan awal. Ini adalah perhatian yang perlu dicatat bahwa prakiraan yang pertama itu optimis sampai pemeliharaan. Pertumbuhan mungkin akan diperlukan dalam prakiraan dan menghindari kapabel dipesan selama dijamin itu menyangka pertumbuhan yang dinginkan melebihi 65% dari kemampuan yang ada kapabel. Penyelidikannya memperlihatkan kode program itu optimis melebihi limit 65 % untuk kapasitas piranti keras yang meningkatnya sangat ruwet dan kedua biaya piranti lunak. Gambar ini mempergunakan komputer untuk pemuatannya atas pelepasannya. Sejak prakiraan pertama cenderung untuk optimis, prakiraan akan mengantarkan berakhirnya sampai pada kapasitas 40 % dan selesailah Tahap Rancangan Awal.

Kriteria penyelekasian yang serupa harus dipertimbangkan yaitu pemilihan bahasa program. Pertimbangan untuk penyeleksian bahasa program diantaranya berorientasi bahasa mesin (Machine Oriented Language / MOL), sebagaimana assembly atau bahasa mesin, dan bahasa perintah tingkat tinggi (Hihger Order Language / HOL ) termasuk di dalamnya antara lain :

1. HOL, adalah mudah untuk dipelajari dan digunakan,
2. HOL, daftarnya adalah mudah untuk dibaca dan dimengerti
3. HOL, programnya adalah mudah untuk di-debug dan dipelihara,
4. HOL, progranya adalah mudah untuk dipindahkan ke komputer lain,
5. Permasalahan Engineering bisa dipecahkan, lagi cepat dengan HOL,
6. HOL kodenya obyektif biasanya adalah kurang effisien,
7. HOL yang ada tidak boleh untuk komputer biasa atau compilernya mungkin sangat tidak effisien untuk komputer itu.
8. HOL adalah juga tidak cocok untuk beberapa fungsi sistem operasi, perlakuan I/O dan bit termanipulasi.

Jika diputuskan untuk menggunakan HOL, ini adalah nomor yang lebih lanjut untuk dipertimbangkan :

1. Keserasian untuk lingkup permasalahan dan pemakai :

• Fasilitas untuk menyelesaian persamaan scientific.
• Kemampuan ber Aritmatik, termasuk didalamnya titik perpindahan operasi,
• Derajat sumbangannya wajib untuk aplikasi
• Variabelnya cukup dan data reputasi kemampuannya,
• Ahli di dalam bahasa program,
• Berkemampuan khusus, sebagaimana karakter kelakuannya, laporan yang dihasilkan dan makro,
• Kemampuan mendiagnose cukup untuk membantu pemerikasaan.

2. Adanya keinginan kompiler dan ini adalah syarat-syarat konfigurasi komputer.

3. Effisiensi dan bahasa yang digunakan (implementasi bahasanya bagus menurut kompiler sedikit susah digunakan. Beberapa kompiler tidak dapat diimplementasi kan yang effisien sekali dalam beberpa komputer).

4. Reaksi untuk pemakai sebelumnya pada bahasa dan kompiler,

5. Pelatihannya mudah dan didokumentasikan,

6. Kemampuan dan pertumbuhannya (kemampuan instalasinya dengan yang lain, mudah dikonversi untuk komputer yang berlainan, potensi pertumbuhan jangka panjang).

7. Karakter Teknisi.

• Metode gambaran data sampai dengan pemrosesannya,
• Menggunakan operator,
• Perintahnya,
• Instruksi kompiler,
• Delimiter
• Struktur Program,
• Dukungan untuk struktur program

2. Rancangan Awal Piranti Lunak
Fungsi khusus dalam Spefikasi Persyaratan Piranti Lunak untuk program komputer adalah di dalam berfungsinya organisasi yang grupnya saling berhubungan memerlukan modul-modul, yang mana pada tingkat pertama organisasi berikutnya program komputer. Sebuah modul mungkin atau tidak mungkin dalam mengeksekusi elemen sampai pada program komputer. Rancangan awal piranti lunak konsisten dengan kesempatan program komputer di bawahnya termasuk di dalamnya berfungsinya hubungan modul ini, definisi konsep operasional (termasuk di dalamnya cara, kontrol, dan skenario pengoperasian), dan mengidentifikasi antarmuka diantara modul-modul. Pada pendahuluan memasukan aktivitas ini adalah untuk menetapkan apa berfungsinya program komputer kinerjanya akan bagaiman dan ini adalah untuk struktur terhadap fungsi kinerjanya. Bagian yang pertama pada modul timgkat rancangan adalah kebutuhan untuk menyelesaikan tugas. Idealnya struktur program komputer dan konsep operasi akan memerlukan minimal hanya perubahan setelah Tinjauan Rancangan Awal (Preliminary Design Review / PDR ), mengingat rancangan modul dapat berubah yang sangat signifikan sebagai sebuah hasil pada analisis rancangan rici yang mana berikutnya PDR.
Menentukan konsep operasional termasuk di dalamnya ditegaskan bagaimana program komputer akan dikontrol sampai fungsinya diselesaikan. Konsep kontrol, rangkaian elemen eksekusinya, pemeliharaan terganggu, dan pemeliharaan masukan/ keluaran adalah dikembangkan pada point ini. Cara operasionalnya adalah didefinisikan dan operasional dengan waktu yang tepat mengahsilkan yang mana digambarkan menyangka rangkaian dan waktu untuk elemen-elemen ekekusi sampai normal dan kondisi abnormal.

3. Waktu dan Ukuran Penyelidikan
Bilamana struktur operasionalnya ditentukan dan elemen-elemen eksekusinya teridentifikasi, waktu yang dikehendaki untuk eksekusi setiap element eksekusi dan kuantitas memori yang dikehendaki selama perkiraan eksekusi. Cara elemen kritis mungkin yang dikehendaki untuk memperbaiki waktu dan perkiraan ukuran. Perkiraan ukuran dan waktu, dikombinasikan dengan waktu yang tepat operasionalnya, yang memberikan basis kinerja penyelidikan untuk loading-komputer sebagai dukungannya terhadap seleksi tugas komputer.

4. Rancangan Awal Antar Muka
Syarat-syarat untuk antar muka diantaranya program komputer dan sumber eksternal, termasuk di dalamnya program komputer yang lain adalah identifikasi dalam bagian persyaratan definisi tugas piranti lunak. Sebagai bagian penugasan rancangan awal program adalah :,
a. tipe data,
b. dasar data,
c. kondisi khusus,
d. protokol antar muka,
e. jenis data spesifik adalah didefinisikan.

Jika mungkin, data spesifik tetap formatnya akan khusus pada waktu ini. Antarmuka ini rancangan informasinya yang kemudian memberikan basis untuk tingkat atas program komputer masukan/keluaran dan proses rancangan. Data dikembangkan di bawah penugasan ini akan diusahakan didalam bagian antarmuka untuk Spesifikasi Persyaratan Piranti Lunak dan kedalam Dokumen Kontrol Antar Muka awal.

5. Rancangan Basis Data
Tugas utama rancangan basis data adalah sampai pada definisi terdiri dari apa basis data. Basis data mungkin didefinisikan yang mempunyai lingkup yang sangat sempit, hanya data yang konsisten, itu adalah dikontrol secara resmi, atau didefinisikan sangat luas sampai termasuk di dalamnya sumber file program komputer dan menyimpan isi modul dalam disk dan seluruh elemen komunikasi data diantaranya setiap elemen eksekusi piranti lunak. Jika ini adalah yang lain dari pada satu program komputer dalam subsistem, yang lazim pemakai basis data dan maksud khusus perlengkapan pengembangan sampai definisi kontrol data akan deksplorasi. Struktur basis data adalah ,:

• Metode access,
• Updating methods,
• Kontrol dan
• Memproteksi keistimewahannya yang harus digambarkan dalam Fungsional Dokumen Rancangan.

6. Perencanaan Ujicoba
Sebuah rencana awal bagaimana untuk sistem yang akan diujicoba adalah dikembangkan untuk diresentasikan pada PDR. Rencana Ujicoba ini akan berakhir selama Tahap Rancangan Rinci. Rencana ini digambarkan secara rinci dalam bab 8.


5.2 RANCANGAN AWAL TAHAP DOKUMENTASI
Diperlihatkan dalam Gambar 5.1, produk Tahap Rancangan Awal untuk proses pengembangan piranti lunak adalah ada empat dokumen yang akan digambarkan berikut. Yang sebelumnya didiskusikan, berbagai tingkat sistem spesifikasi adalah juga secepatnya diproduksi dalam Tahap Rancangan Awal. Dokumen ini adalah masukan yang dipertimbangkan sampai, tidak diproduksinya, proses pengembangan piranti lunak. Perincian isi untuk setiap dokumen berikutnya adalah didapat pada Appendix B.

5.2.1 Persyaratan Spesifikasi Piranti Lunak
Maksud dari Persyaratan Spesifikasi Piranti Lunak adalah sampa pada dokumen fungsonal :

• Kinerja,
• Antarmuka,
• Rancangan dan
• Verifikasi persyaratan untuk setiap program komputer sampai dikembangkannya.

Persyaratan harus khusus sampai pada tingkat keperluan rinci untuk menetapkan batas rancangan. Persyaratan ini adalah alokasi dari sistem tingkat tinggi dan spesifikasi atau yang diperoleh dari analisis pada persyaratan tingkat sistem.Gambar 5.2, Ringkasan isi, persetujuan, dan sekumpulan kontrol kejadian dengan Spesifikasi Persyaratan Piranti Lunak. Contoh tabel isinya adalah diberikan dalam gambar 5.3.

5.2.1 Dokumen Disain Fungsional.
Tujuan Dokumen Disain Fungsional adalah untuk menetapkan fungsional perancangan piranti lunak di program komputer terukur. Itu adalah basis untuk yang terperinci berikut perancangan program komputer. Oleh karena itu harus menyediakan informasi disain cukup memenuhi ke tujuan Tinjauan ulang Disain Pendahuluan, seperti dirumuskan dalam sesi 5.3.2. Untuk melakukan hal ini, Dokumen Disain Fungsional harus:

1. Menyediakan suatu uraian keseluruhan subsistem piranti lunak konsep disainnya, mengungkapkan bagaimana program komputer itu berkait dengan disain itu.
2. Menyediakan definisi, diagram arus, dan uraian modul yang terusun hirarki komputernya.
3. Menyediakan diagram arus data tingkatan puncak dan narasi untuk menguraikan alur data dan peristiwa utama di dalam operasional sistem. Arus perlu menggambarkan semua alur data alat penghubung antara program komputer, perangkat keras, operator, dan program computer lain.
4. Menugaskan masing-masing kebutuhan yang unik di dalam Spesifikasi Kebutuhan Piranti lunak ke modul spesifik dan rutin, atau kelompok rutin yang terkait di dalam suatu modul, dan dengan tegas itu mengidentifikasi pemetaan dari kebutuhan disain piranti lunak.
5. Mengidentifikasi dan menyebut semua tingkatan organisasi piranti lunak (e.g., subsistem, program komputer, modul, unit program) yang diperlukan untuk piranti lunak yang dikembangkan.
6. Untuk masing-masing tingkatan organisasi piranti lunak sampai tingkatan modul:
   a. Identifikasi sesuai nama dan komponen yang berfungsi pada yang terukur.
   b. Menetapkan alat penghubung pengendalian itu yang mempengaruhi komponen pada yang terukur.
   c. Menetapkan alat penghubung data itu yang mempengaruhi komponen pada yang terukur.
   d. Identifikasi pengolahan data mengalir pada yang terukur dari titik masuk untuk menunjuk keluaran.
   e. Uraikan modifikasi / pengembangan yang diperlukan mendekati untuk masing-masing komponen untuk diadaptasikan dari piranti lunak ada.
7. Menetapkan anggaran sumber daya pengolahan data (e.g.,pemilihan waktu, penyimpanan, ketelitian).
8. Identifikasi semua yang utama diperlukan alogritma dan penempatan mereka di dalam disain program komputer.
9. Identifikasi dan menyebut tingkatan hirarki data base ( e.g., data base, file, record, arary, hingga menuju ke tingkatan parameter yang individu. Karena masing-masing tingkatan hirarki data base, Dokumen Disain Fungsional mengidentifikasi nama itu, indeks] ( uraian dan unit), dan ukuran komponen data base.
10. Perlihtkan bahwa anggaran sumber daya kumpulan pengolahan data (e.g., pemilihan waktu, penyimpanan, dan ketelitian) adalah di dalam total sumber daya yang tersedia.
11. Meliputi seorang pemakai yang mengorientasikan uraian perancangan alat penghubung antara para pemakai manusia dan program komputer, perangkat keras komputer, dan peralatan sistem.
12. Meliputi suatu definisi dari semua standard disain dan konvensi mengadopsi untuk menggunakan disain yang diperkenalkan dokumen ini dan mereka untuk diamati sepanjang Tahap Disain Detil. Disain ini Standard boleh meliputi diagram aliran atau bahasa disain program baku, menamai konvensi, dan seterusnya.
13. Meliputi suatu definisi dari semua standard dan konvensi untuk diamati praktek coding, seperti bahasa, praktek coding yang dilarang, praktek coding yang diperlukan, dan merekomendasikan praktek coding.
    Indeks, Persetujuan, dan pengendalian peristiwa yang berhubungan dengan Ringkasan Dokumen Disain Fungsional gambar 5.4. Suatu daftar isi contoh disiapkan dalam bentuk gambar 5.5.

5.2.2 Dokumen Pengendalian Antarmuka Awal (The Interface Control Document (ICD)
Dokumen Kendali Alat penghubung (The Interface Control Document (ICD)) menetapkan tanggung jawab antara organisasi atau pemborong untuk yang fungsional dan capaian kebutuhan dari alat penghubung spesifik di luar subsistem perangkat lunak. ISC menetapkan kebutuhan antarmuka ini dan menetapkan komponen perancangan piranti lunak yang mendukung antarmuka itu.
Bagian Kebutuhan dokumen harus tersedia untuk tinjauan ulang dan persetujuan di Kebutuhan tinjauan ulang piranti lunak. Mungkin saja dikembangkan dan terikatan secara terpisah sebagai suatu Spesifikasi Pengendalian Antarmuka (Interface Control Specification (ICS)) jika diinginkan. Bagian Disain ICD yang dikembangkan paralel dengan disain piranti lunak. Oleh karena itu, ICD mengirimkan format persiapan pada ujung Tahap Disain Pendahuluan dan di dalam format terakhir pada ujung Tahap Disain Rinci.
Piranti lunak tunggal ICD atau suatu ICD untuk masing-masing piranti lunak yang mengutamakan antarmuka mungkin adalah tertulis. Keputusan ini harus dibuat pada tahap perencanaan proyek dan hasil Rencana Proyek program komputer didomentasikan. Ukuran proyek, kompleksitas . dari antar muka, banyaknya antar muka organisasi, status anyar muka unsur (ada di bawah pengembangan), dan kebutuhan pelanggan harus ditetapkan dipertimbangkan pendekatan proyek ke ICDs.
Karena proyek kecil, ICD mungkin adalah suatu nota yang mengkoordinir antara unsure-unsur organisasi yang mengembangkan antar muka itu. Setidak-tidaknya, titik yang penting adalah bahwa ICDs diproduksi tahap ini untuk menetapkan persetujuan antarmuka. Indeks, Persetujuan, dan peristiwa pengendalian untuk ICDs disiapkan dalam bentuk gambar 5.6. Suatu Tabel Contoh isi adalah tercakup di gambar 5.7.

5.2.3 Tes Dokumentasi

Rencana Test Awal memproduksi sepanjang Tahap Disain Awal yang menggambar-kan metoda untuk menggunakan pengujian subsistem piranti lunak. Dokumen ini diuraikan secara detil di dalam bab 8.

5.3 TAHAP DISAIN PERSIAPAN TINJAUAN ULANG

Seperti ditunjukkan pada gambar 5.1, dua tinjauan ulang utama dipegang sepanjang Tahap Disain Pendahuluan:

1. Tinjauan ulang Kebutuhan Piranti lunak (Software Requirement Review (SRR)), yang dipegang pada ujung bagian definisi kebutuhan Tahap Disain Persiapan, dan
2. Tinjauan ulang Disain Persiapan (Preliminary Design Review (PDR)), yang dipegang di kesimpulan Tahap Disain Persiapan. Tanggung-Jawab, Indeks, Format, dan mengharapkan hasil dari tinjauan ulang ini dibahas bagian yang berikut.

5.3.1 Kebutuhan Tinjauan Ulang Piranti lunak
Lebih dulu tinjauan ulang formal antara pengembang piranti lunak dan pelanggan adalah Tinjauan ulang Kebutuhan Poranti lunak. (Software Requirements Review (SRR)), yang mana adalah diselenggarakan setelah penyelesaian analisa kebutuhan dan alokasi kebutuhan ke program komputer di dalam subsistem piranti lunak. Tujuannya adalah untuk memperoleh persetujuan timbal balik antara pemakai atau pelanggan dan pengembang piranti lunak bahwa kebutuhan yang ditetapkan untuk subsistem piranti lunak atau program komputer adalah akurat dan lengkap dan bahwa mereka menghadirkan komitmen pengembangan itu untuk item piranti lunak. Tinjauan ulang didasarkan pada Spesifikasi Kebutuhan Piranti lunak, yang diuraikan sesi 5.2.1, yang harus diselesaikan sebelum tinjauan ulang . Tinjauan ulang spesifikasi yang diselesaikan adalah basis untuk persetujuan yang dapat dikuatkan, dikendalikan, dan dikomunikasikan. Spesifikasi yang disetujui adalah basis untuk disain piranti lunak komputer dan Persiapan perjanjian untuk SRR termasuk penelitian dan mengevaluasi Spesifikasi Kebutuhan Piranti lunak untuk kemampuan menerima yang sesuai kontrak dan teknisnya dan mengembangkan suatu tanggapan kepada masing-masing masalah mengenali analisa ini atau di dalam tinjauan ulang pelanggan berkomentar menerima sebelum Kebutuhan Piranti lunak ditinjau ulang. Aktivitas Persiapan Tinjauan ulang meliputi yang berikut:

1. Analisa puncak mengukur kebutuhan untuk kelengkapan, konsistensi, test kemampuan , dan kelayakan teknis.
2. Analisa dari tiap kebutuhan berkenaan dengan yang berikut:
   a. Kejelasan (Clarity). Semua kebutuhan mengalokasikan kepada program komputer harus dengan jelas dinyatakan spesifikasinya.
   b. Presentasi (Presentation). Kebutuhan yang harus dinyatakan adalah suatu bahasa yang dapat dimengerti kepada masyarakat pemakai secara umum, bukannya di dalam menghitung atau jargon piranti lunak.
   c. Lacak kemampuan (Traceability). Masing-Masing kebutuhan harus dapat dilacak bagi suatu spesifikasi tingkat yang lebih tinggi.
   d. Kecocokan (Compatibility). Masing-Masing kebutuhan harus kompatibel dengan sistem mengukur yang obyektivitas.
   e. Kelayakan Teknis (Technical Feasibility). Masing-Masing kebutuhan ia harus di dalam kemampuan teknologi terkini yang hadir atau teknologi yang diproyeksikan kepada periode waktu pengembangan.
   f. Kelengkapan (Completeness). Seperti kebutuhan adalah yang dinyatakan , apapun itu namun untuk menentukan harus dikenali dengan tegas, tidak melulu yang disiiratkan.
   g. Verifikasi (Verification). Masing-Masing kebutuhan yang dinyatakan harus dibuktikan oleh test, analisa, atau demonstrasi.
   h. Metoda Verifikasi (Verification Method). Spesifikasi Piranti lunak perlu mengidentifikasi metoda yang umum untuk digunakan di dalam pembuktian kebutuhan masing-masing.
   i. Kebenaran (Validity). Hanya kebutuhan yang benar harus dinyatakan spesifikasinya bebas dari informasi disain.
3. Analisa kebutuhan untuk menentukan kecocokan dengan jadual kontrak, pembiayaan, dan lain sumber daya proyek.
   
   Komite SRR Tinjauan ulang meninjau ulang presentasi hasil analisa kebutuhan untuk menentukan bahwa masing-masing kebutuhan telah dianalisa dan digambarkan dalam detail yang jelas untuk mulai disain piranti lunak.

5.3.2. Tinjauan Ulang Disain Pendahuluan
Tahap Disain Program pendahuluan memuncak adalah suatu Tinjauan ulang Disain Pendahuluan (Preliminary Design Review (PDR)). Tinjauan Material pada PDR meliputi Dokumen Disain Fungsional, Dokumen Pengendalian Antarmuka, dan hasil studi perdagangan yang dilakukan untuk mendukung aktivitas disain program pendahuluan. (Sebagai tambahan, Menguji Material Tinjauan Rencana pada PDR waktu, seperti yang diuraikan pada bab 8.) Ketika material ini, dokumen yang mana keseluruhan disain, telah ditinjau, disdain rinci piranti lunak dapat berproses. Tujuan Tinjauan ulang Disain Pendahuluan adalah untuk mengevaluasi pendekatan disain data base sebelum meneruskan usaha disain rinci. Tinjauan ulang ini diselenggarakan untuk menentukan apakah pendekatan disain membuat puas kebutuhan Spesifikasi Kebutuhan Piranti lunak dan apakah anatarmuka adalah kompatibel dengan lain sistem antarmuka. Tinjauan ulang dipegang ketika disain telah maju langsung di mana jika fungsi telah dialokasikan ke modul program komputer, dan arus operasional, mempertunjukkan data itu mengalir antara fungsi, telah diselesaikan. Material yang berikut harus tersedia untuk penulis resensi buku sebelum PDR bertemu:
1. Apunpun perubahan diusulkan kepada Spesifikasi Kebutuhan Piranti lunak.
2. Dokumen Disain Fungsional.
3. Menghubungkan Dokumen Pengendalian Antarmuka.
4. Capaian persiapan estimasi.
5. Rencana persiapan Test Piranti lunak ( lihat bab 8).
Dokumen meninjau ulang sebelum PDR dan diskusi pada PDR perlu memenuhi yang berikut:
1. Tinjauan ulang Pendekatan Disain (Review of Design Approach). Tinjauan ulang ini perlu mengkonfirmasikan bahwa pendekatan disain program komputer Dokumen Disain Fungsional dipresentasikan yang menyertakan dan membuat puas semua kebutuhan yang menyatakan Kebutuhan Spesifikasi Piranti lunak. Pertimbangan tertentu harus diberikan kepada alokasi kebutuhan spesifikasi ke unsur-unsur piranti lunak (modul) dan kepada definisi alokasi penyimpanan, konsep operasional, dan disain data base.
2. Tinjauan ulang Antarmuka (Review of Interface). Tinjauan ulang ini perlu membongkar dan memecahkan ketidak cocokan dan ketidak konsistenan antar spesifikasi antarmuka eksternal untuk kedua-duanya yang fungsional dan phisik antarmuka.
3. Tinjauan ulang Kebutuhan Verifikasi (Review of Verification Requirement). Tinjauan ulang ini perlu meliputi suatu evaluasi Rencana Test piranti lunak pendahuluan (sebagai yang digambarkan bab 9) untuk memastikan bahwa dengan mematuhi ketentuan pejamin kualitas Spesifikasi Kebutuhan Piranti lunak. Itu perlu juga menyediakan jaminan bahwa semua pendukung kebutuhan test telah (menjadi) tercakup di perencanaan test, yang terutama sekali yang memerlukan suatu yang merindukan lead-time untuk pengembangan atau pengadaan.
4. Tinjauan ulang Data Pendukung (Review of Supporting Data). Tinjauan ulang ini akan menentukan apakah pendekatan disain, ketika didokumentasikan Dokumen Disain Fungsional, mempunyai cukup data pendukung dan apakah jadual pengembangan realistis. Yang berikut harus tercakup data pendukung: jadual pengembangan; perdagangan disain hasil belajar, mencakup simulasi dan analisa; diagram urutan operasional; sistem arus fungsional; dan hasil pemilihan waktu dan analisa ukuran.

Pertemuan PDR yang biasanya terdiri dari presentasi yang menujukan, sebagai minimum, isu yang berikut:
1. Suatu ikhtisar disain, mengidentifikasi struktur piranti lunak, mendukung dasar pemikiran disain, operasi piranti lunak di dalam lingkungan sistem, dan pemakai antarmuka.
2. Suatu ikhtisar implementasi dan rencana test.
3. Isu sesuai kontrak dan teknis kritis, yang diikuti oleh suatu resolusi dari isu ini dan suatu persetujuan dengan pelanggan untuk meneruskan Tahap Disain Rinci.





5.4 DAFTAR NAMA TAHAP DISAIN PERSIAPAN

Daftar nama yang berikut menyediakan suatu ringkasan mengenai pokok-pokok informasi yang harus tersedia pada ujung Tahap Disain Pendahuluan untuk mendukung aktivitas disain rinci di dalam tahap berikutnya:

1. Capaian dan kebutuhan antarmuka eksternal pada suatu tingkatan yang cukup tentang detil untuk membentuk basis itu untuk mendisain piranti lunak.

2. Alokasi kebutuhan fungsional untuk mendisain

• Suatu uraian keseluruhan kebutuhan pengolahan data.
• Alokasi kebutuhan capaian (dari Spesifikasi Kebutuhan Piranti lunak) ke unsur-unsur perangkat lunak individu.
• Urutan operasi di dalam unsur-unsur piranti lunak pada suatu tingkatan yang cukup untuk menunjukkan pemenuhan kebutuhan capaian.

3. Lingkungan Piranti lunak

• Suatu uraian konfigurasi perangkat keras.
• Suatu uraian sistem operasi dan sistem lain mendukung kegunaan.
• Suatu uraian tentang segala piranti lunak yang ada untuk digunakan pengembangan.
• Detil dari ketergantungan yang kritis pada yang manapun di atas piranti lunak ( e.g., pemilihan waktu sistem operasi).
• Suatu uraian tentang segala piranti lunak untuk dikembangkan itu tidak akan dari bagian sistem yang operasional ( e.g., perlatan test atau peralatan pendukung pengembangan).

4. Struktur Program

• Suatu uraian keseluruhan struktur unsur piranti lunak yang hirarkis.
• Pertimbangan untuk mengadopsi struktur spesifik.
• Metodologi untuk digunakan di dalam menerapkan struktur itu ( e.g., puncak menurun / top down).
• Alokasi fungsional kepada tingkat modul. Dengan mendukung dasar pemikiran.
• Suatu uraian pengendalian eksekutip dan urutan program operasi.

5. Alokasi Sumber Daya

• Alokasi dari memori tersedia ke unsur piranti lunak individu.
• Alokasi penyimpanan kepada data base dan transient data
• Suatu uraian bagaimana pemilihan waktu, berurutan, dan batasan perangkat keras telah dipertimbangkan dan dicukupi menentukan alokasi penyimpanan.
• Analisa Pemilihan waktu untuk urutan piranti lunak kritis, kecepatan masukan data, dan interrupt yang ditahan.
• Analisa bersamaan yang memproses kebutuhan, tugas, dan implikasi pemilihan waktu.

6. Struktur Data

• format dari semua antarmuka data.
• Definisi display operator, tindakan, dan tanggapan.
• Definisi struktur file, mencakup nama, ukuran, penempatan, dan implikasi pemilihan waktu.

7. Konsep Operasional

• Mulai prosedur.
• Backup / prosedur recovery.
• Kesalahan yang ditahan, kesalahan pendeteksian, dan teknik recovery.

8. Pertimbangan Keamanan

• Identifikasi kebutuhan keamanan yang bisa mempengaruhi atau menghambat disain program itu.
• Uraian teknik disain untuk menerapkan dan memelihara kebutuhan keamanan.

9. Identifikasi Area Resiko

• Identifikasi unsur-unsur yang kritis dalam kaitan dengan dampak pada operasi.
• Identifikasi unsur-unsur dengan teknis yang tinggi atau berharga / menjadualkan resiko di dalam pengembangan mereka.

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.