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.