TUGAS 9 Nama : Daniel Saputra Nim : 41813010198 Study : Rekayasa Perangkat Lunak
MODEL DESAIN DOKUMENTASI DESAIN A. MODEL DESAIN Prinsip dan konsep desain disini dimaksudkan membangun sebuah fondasi untuk pembuatan model desain yang mencakup representasi data, arsitektur, interface, dan prosedural. Seperti model analisis sebelumnya. Pada model desain, masing-masing representasi desain diikatkan dengan yang lainnya, dan semua dapat ditelusuri balik ke persyaratan perangkat lunak. Banyak pemrogram terus menerus mendesain secara implisit, dengan melakukan desain prosedural pada saat dikodekan. Hal itu sama dengan mengambil desain piramid dan mendirikannya pada titiknya, hasil desain yang sangat tidak stabil. Perubahan yang paling kecil dapat menyebabkan piaramid tersebut (dan program) tumbang. Desain adalah langkah pertama dalam fase pengembangan bagi setiap produk atau sistem yang direkayasa. Desain dapat didefinisikan berbagai “proses aplikasi berbagai teknik dan prinsip bagi tujuan pendefinisian suatu perangkat, suatu proses atau sistem dalam detail yang memadai untuk memungkinkan realisasi fisiknya”[TAY59]. Tujuan desainer adalah untuk menghasilkan suatu model atau representasi dari entitas yang kemudian akan dibangun. Desain perangkat lunak berada pada inti teknik dari proses rekayasa perangkat lunak dan diaplikasikan tanpa memperhatikan model proses perangkat lunak yang digunakan. Begitu persyaratan perangkat lunak telah mulai dianalisis dan ditentukan, maka desain perangkat lunak menjadi yang pertama dari tiga aktivitas teknik – desain, pembuatan kode dan pengujian yang diperlukan untuk membangun dan menguji perangkat lunak. Persyaratan perangkat lunak, yang dimanifestasi oleh data, fungsional, dan model-model perilaku, mengisi langkah desain.
1
Dengan menggunakan satu dari sejumlah metode desain, langkah desain menghasilkan : Desain data Desain arsitektur Desain interface Desain prosedural Selama desain, kita dapat membuat keputusan yang akan mempengaruhi kesuksesan konstruksi perangkat lunak dan kemudahan maintenance-nya. Desain sangat Penting karena dapat menentukan kualitas dari suatu perangkat lunak. Data design mengubah informasi menjadi struktur data untuk mengimplementasikan software. Data design dibuat berdasarkan data dictionary dan ERD. Architectural design mendefinisikan relasi antara elemen - elemen structural utama, pola desain yang digunakan untuk mencapai kebutuhan yang ditentukan untuk sistem dan batasan - batasan yang mempengaruhi bagaimana desain arsitektural ini diterapkan. Desain ini berdasarkan spesifikasi sistem, model analisis (bagian DFD) dan interaksi antara subsistem. Interface design menjelaskan bagaimana software berkomunikasi dalam dirinya, dengan sistem yang bertukar informasi dengannya, dan dengan manusia yang menggunakannya. DFD diperlukan untuk desain ini. Component - level design menghasilkan deskripsi prosedur software. Desain Arsitektur Software Proses merancang untuk menentukan sub-sub sistem dan membangun kerangka kerja untuk kendali dan komunikasi antar sub sistem disebut design arsitektural. Proses merancang ini menghasilkan arsitektur software atau arsitektur sistem. Desain arsitektur adalah aktifitas desain yang pertama dalam pembangunan software. Desain arsitektur memberikan 3 keuntungan yaitu: 1. Arsitektur software menjadi media komunikasi dan diskusi karena mudah dipahami 2. Memberi kemudahan dalam melakukan analisis terhadap software yang akan dibangun 3. Arsitektur-nya bisa digunakan lagi untuk sistem selanjutnya (reusable)
2
Tiap perancang sistem memiliki kemampuan dan pengetahuan yang berbeda dalam merancang arsitektural. Aktifitas-aktifitas berikut adalah aktifitas dalam merancang dan aktifitas ini tidak dikerjakan satu persatu berurutan, tapi bisa dilakukan bersamaan, yang meliputi : 1.
Menyusun sistem (system structuring) : sistem disusun menjadi beberapa subsistem utama, dimana subsistem adalah unit bagian software yang berdiri sendiri.
2.
Membuat model kendali (Control modelling) : berkaitan dengan hubungan antara bagian dalam sistem.
3.
Membuat pembagian sistem menjadi modul-modul (modular decomposition): membagi sub-sub sistem menjadi modul-modul.
Untuk menghindari kesalahan dalam pemahaman terhadap istilah modul dan sub sistem, perlu diketahui bahwa sub sistem adalah bagian dari sistem yang bias berdiri sendiri dan tidak bergantung pada layanan sub sistem lain. Sub system terdiri dari beberapa modul dan dilengkapi interface untuk berkomunikasi / bertukar data dengan sub sistem lain. Struktur Program dan Data Terminologi struktur dapat didefinisikan sebgai berikut: 1. Program structure menampilkan / menyajikan organisasi (seringkali organisasi hirarki) komponen-komponen program (modul-modul) dan mengandung arti hirarki dari kontrol Program 2. Notasi yang digunakan adalah diagram tree. Biasanya dinamakan structure chart Sedangkan struktur data menggambarkan relasi logikal antara sejumlah elemen Software Prosedur Difokuskan pada detail pemrosesan dari setiap modul secara individu. Prosedur harus mengandung spesifikasi yang benar / tepat dari pemrosesan, termasuk : sequence of events, decision points, repetitive operations, dan struktur data. Software dibagi kedalam nama-nama yang terpisah dan elemen-elemen yang dapat dipanggil, yang disebut dengan modul, yang termasuk kedalam memenuhi syarat-syarat permasalahan. Modular design digunakan untuk mereduksi komplesitas masalah, menyediakan fasilitas untuk melakukan perubahan (dalam hal pemeliharaan), dan memudahkan implementasi dengan pengembangan paralel dari bagian-bagian yang berbeda dalam suatu sistem. Adapun type Module meliputi :
3
Abstraksi dan penyembunyian informasi dipakai untuk mendefinisikan modul-modul di dalam lingkungan software architecture. Di dalam structure software, suatu modul mungkin dikategorikan sebagai berikut : 1. Sequential module :dieksekusi tanpa interupsi yang dilakukan software aplikasi 2. Incremental module:dapat diinterupsi oleh program aplikasi dan kemudian kembali ke titik semula setelah interupsi selesai 3. Parallel module:dieksekusi secara simultan dengan modul lain dalam lingkungan Concurrent multiprocessor.
B. DOKUMENTASI DESAIN Dokumentasi digunakan secara berkala untuk menggambarkan seluruh instruksi, programprogram, dan naratif atau segala sesuatu yang bersifat abstrak/virtual mengenai sistem informasi. Dokumentasi mempunyai beberapa kegunaan, diantaranya :
Selama dilaksanakan desain sistem merupakan penyusunan produk yang dibangun oleh team desain dan user.
Setelah instalasi, merupakan dasar untuk membuat perubahan terhadap sistem.
Kualitas dari dokumentasi menentukan seberapa besar flesibilitas departemen layanan informasi
memberikan respon terhadap permintaan user.
Dokumentasi yang baik disajikan untuk mengurangi konflik antar user dengan departemen layanan
informasi, ketika sistem didokumentasikan dengan baik menjadi lebih mudah dimengerti oleh user.
Melalui dokumentasi berarti referensi yang memadai tersedian ketika masalah terjadi, dan informasi informasi ini membantu user untuk mempelajari bagaimana menyelesaikan masalah mereka dengan sistem. Terdapat beberapa jenis dokumentasi, yaitu :
Dokumentasi desain
Dokumentasi user untuk training
Dokumentasi operasi
Dokumentasi referensi user 4
Design Documentation Purpose :
Dokumentasi ini membantu komunikasi didalam tim desain, merepresentasikan konseptualisasi terakhir dari sistem yang baru atau pemahaman terhadap sistem yang telah ada.
Selama proses desain kegunaan lain dari dokumentasi ini merupakan kontrol, menyediakan record dari apa yang telah dibangun dan diubah.
Menjadi sangat penting untuk memastikan bahwa seluruh bagian dari sistem dipengaruhi oleh perubahan
yang dipertimbangkan dan bahwa tanggung jawab untuk komponen-komponen dari sistem yang dipengaruhi oleh perubahan telah diberitahukan.
Misalkan jika format file atau isi dari file diubah, maka modul program apa dan siapa saja pemrogram yang akan terpengaruh ?
Kontrol ini juga berfungsi untuk memanggil ujicoba pelaksanaan yang lampau atau versi lama dari suatu program atau file.
Jenis dokumentasi ini akan membentuk database yang baik untuk menentukan estimasi diwaktu mendatang mengenai berapa lama waktu yang dibutuhkan untuk membangun sistem yang serupa.
Sistem perpustakaan program dapat menyimpan setiap track dari seluruh versi program dan memastikan bahwa pemrogram bekerja dengan versi terbaru.
Content :
Komponen dari dokumentasi desain
Elemen mendasar dari dokumentasi desain seperti tersebut diatas, dokumentasi yang terpenting adalah tabel isian (table of content) yang disediakan sebagai derektori untuk file manual yang berisikan seluruh informasi lainnya mengenai sistem.
Pustaka harus berisi survey dan studi kemungkinan dan dokumen yang berhubungan dengan analisis dari sistem yang ada. Juga sebagai tempat untuk menyimpan spesifikasi untuk sistem yang baru.
Ketika diagram alur data diubah, maka diagram yang asli disimpan dalam penyimpanan arsip sebagai backup. Menyimpan dokumen terbaru dalam pustaka kerja dengan setiap modul tertanggal dan pointer untuk lokasi versi lampau dalam arsip.
5
Penting untuk menyimpan salinan dari input, output dan format record file dan daftar modul. Baebagai macam modul dan file harus direferensi silang berdasarkan modul lain yang terkait dengannya.
Harus terdapat daftar referensi silang dari pemanggilan modul dan modul yang menggunakan elemen data yang berbeda, dan jika diperlukan perubahan uratan pemanggilan atau format record, maka beberapa pemrogram yang terpengaruh dapat di beritahukan dengan menggunakan daftar referensi silang.
Seseorang dalam tim desain harus ditunjuk sebagai pustakawan atau databese administrator, yang harus mendistribusikan daftar identifier kepada pemrogram.
User Documentation for training Purpose :
Dokumentasi training mempersiapkan user untuk implementasi dan penggunaan sistem selanjutnya
Dokumentasi user training digunakan untuk menjembatani jarak antara prosedurprosedur lama, saat ini dan yang dibutuhkan/diminta untuk sistem baru
Dokumen ini harus dibangun oleh anggota user dari tim desain dalam hubungannya dengan user lainnya dalam organisasi
Content :
Minimal komponen dokumentasi training use
Sangat baik untuk memulai pelatihan dengan terlebih dahulu memberikan penjelasan menyeluruh mengenai sistem dan apa masud/tujuan diselesaikannya pelatihan tersebut
Untuk aplikasi interaktif, pengguna dapat mempelajari sistem lebih sering dengan melihat pohon menu
Pelatihan user juga termasuk mempertimbangkan pengaruh dari transisi, khususnya ujicoba dan konversi
Operation Documentation Purpose :
Bagian operasi dari departemen layanan informasi harus mengoperasikan sistem setelah diimplementasikan
6
Kelompok ini memerlukan informasi mengenai prosedur operasi normal dan bagaimana merespon kesalahan
Informasi ini baiknya disiapkan oleh analis sistem dan programer, dan banyak diantaranya dihasilkan/diambil dari dokumentasi desain
Content :
Minimal komponen dokumentasi operasi
Diagram alur yang lengkap yang menunjukan input yang dibutuhkan untuk setiap program, file-file apa saja yang diperlukan dan output apa saja yang harus dicetak/dihasilkan
Jika terdapat input yang khusus, maka harus diberikan catatan dan dokumentasi harus menunjukkan file-file yang terkait dalam pemrosesan
Penting bagi operator untuk mengetahui kondisi kesalahan yang mungkin terjadi dan bagaimana merespon keadaan tersebut
Jika terdapat beberapa pengguna sistem, maka akan menjadi hal yang baik jika disediakan daftar terminal dan pengguna yang mengakses sistem
User Reference Documentation Purpose :
Informasi ini akan dituju oleh user yang mempunyai pertanyan atau masalah sebelum mereka menghubungi departemen layanan informasi
Jika dokumentasi ini memiliki kualitas yang cukup, maka pertanyaan-pertanyaan tersebut akan terjawab tanpa harus menghubungi departemen layanan informasi
Akan terjadi tingkat frustasi yang cukup tinggi ketika terjadi suatu kesalahan dengan sistem informasi dan user tidak mengerti mengapa terjadi masalah tersebut atau bagaimana cara mengatasinya
7
Referensi Raymond McLeod, Jr., “Management Information System A Study of Computer Based Information Systems”, Prentice Hall, Inc, 1995. Roger S. Pressman, "Software Engineering, a Practitioner's Approach" Fourth Edition, McGraw Hill, 1997. Roger S. Pressman, "Software Engineering, A Beginner's Guide", McGraw Hill, 1998. Barbee Teasley Mynatt, "Software Engineering with Student Project Guidance", Prentice Hall, Inc, 1990. Coad, Peter and Edward Yourdan. 1991. Object Oriented Analysis. New Jersey : PrenticeHall. Coad, Peter and Edward Yourdan. 1991. Object Oriented Design. New Jersey : Prentice Hall.Goodland, Mike. 1995. SSADM A Practical Approach Version 4. London : Mc Graw Hill Handoko, Mary. 1999. Bahan Kuliah Manajemen Proyek Perangkat Lunak. Bandung :Magister Informatika ITB Jacobson, I. 1995. Object Oriented Software Engineering. Edinburg Gate Harlow : Addison Wesley. Laksmiwati, Hira. 1998. Bahan-bahan Kuliah Rekayasa dan Analisis Perangkat Lunak.Bandung : Magister Informatika ITB Mahyuzir, Tavri D. 1989. Analisisa dan Perancangan Sistem Pengolahan Data. Jakarta :Elex Media Komputindo Mahyuzir, Tavri D. 1991. Pengantar Analisis dan Perancangan Perangkat Lunak. Jakarta :Elex Media Komputindo Mardiyanto, M. Sukrisno 1998. Bahan-bahan Kuliah Pembangunan Sistem Perangkat Lunak. Bandung : Magister Informatika ITB
8
Santoso. Oerip S. 1999. Bahan-bahan Kuliah Uji Kualitas Perangkat Lunak. Bandung :Magister Informatika ITB Sucahyo, Yudho Giri. 1997. Bahan Kuliah Rekayasa Perangkat Lunak. Jakarta : Ilmu Komputer UI
Roger S. Pressman, Ph.D, “Rekayasa Perangkat Lunak”, Pendekatan Praktisi (Buku Satu ), ANDI Yogyakarta Roger S. Pressman, "Software Engineering, a Practitioner's Approach" Fourth Edition, McGraw Hill, 1997. Barbee Teasley Mynatt, "Software Engineering with Student Project Guidance", Prentice Hall Int. 1990. Roger S. Pressman, "Software Engineering, A Beginner's Guide", McGraw Hill, 1998. http://kuliah.dinus.ac.id/ika/prc3.html http://parno.staff.gunadarma.ac.id/Downloads/files/11337/SI_10_Kamus_Data.pdf
9
