Konsep modularitas dalam perangkat lunak komputer telah didukung selama hampir empat dekade. Arsitektur perangkat lunak memasukkan modularitas, dimana perangkat lunak dibagi ke dalam komponen-komponen bernama dan dapat dipanggil terpisah. Lima kriteria yang memungkinkan kita mengevaluasi suatu metode desain dengan merujuk pada kemampuannya untuk menentukan sistem modular yang efektif. Dekomposibilitas modular. Bila metode desain memberikan suatu mekanisme sistematis untuk melakukan dekomposisi terhadap masalah menjadi submasalah-submasalah, maka metode desain akan mengurangi kompleksitas keseluruhan masalah, sehingga dapat mencapai solusi modular efektif. Komposabilitas modular, bila suatu metode desain memungkinkan komponen-komponen desain (reusable) yang ada untuk dipasang ke dalam sebuah sistem baru, maka metode desain akan menghasilkan suatu solusi modular yang tidak berulang. Kemampuan pemahaman modular, jika sebuah modul dapat dipahami sebagai unit yang berdiri sendiri (tanpa referensi dari modul lain), maka modul akan lebih mudah dibangun dan diubah. Kontinuitas modular, Bila perubahan kecil pada persyaratan sistem menyebabkan perubahan kecil pada modul individual dan bukan perubahan sistem secara luas, maka pengaruh dari efek samping yang disebabkan oleh kesalahan oleh perubahan dapat diminimalkan. Proteksi modular, Bila terjadi kondisi yang menyimpang pada modul tersebut, pengaruh dari efek samping yang disebabkan oleh kesalahan akan diminimalkan. Akhirnya penting untuk dicatat bahwa suatu sistem dapat di desain secara modular, bahkan juga bila implementasinya harus “monolistik”. Ada situasi (misalnya perangkat lunak real time, perangkat lunak embedded) di mana kecepatan dan subrutin, prosedur) tidak dapat diterima. Dalam situasi seperti itu, perangkat lunak dapat dan harus dirancang dengan modularitas sebagai sebuah filosofi yang diprogram tidak kelihatan modular pada saat pertamanya, filosofi harus dijaga, dan program tersebut akan memberikan manfaat sistem modular.
Disini Terdapat beberapa Rangkaian Lengkap Dari Konsep dan Prinsip Design.
- Desain software dan software engineering
- Process desain
- Prinsip desain
- Konsep desain
- Abstraksi, perbaikan, modularity
- Arsitektur software
- Hirarki control
- Partisi struktural
- Struktur data
- Procedur software
- Information yang tersembunyi
- Desain modular yang efektif
- Ketergantungan fungsional, kohesi, penggabungan Desain heuristic untuk modularity efektif Model desain Dokumentasi desain.
Desain Software dan Software Engineering
Desain ->Langkah pertama dalam fase pengembangan untuk prodengineer manapun. Bertindak sebagai pondasi untuk semua software engineering dan pemeliharaan software dengan langkah-langkah yang mengikutinya.
Tujuan seorang perancang adalah menghasilkan suatu model(atau penyajian) dari sebuah entitas yang akan dibangun
Input desain software : Model analisa kebutuhan dan dokumentasi spesifikasi
Output desain software : Model desain dan dokumentasi spesifikasi desain
Desain - menerjemahkan kebutuhan ke model desain lengkap untuk sebuah produk software.
- menyediakan representasi software yang dapat diduga untuk kualitas.
Desain Software
Sejumlah metode desain dapat digunakan untuk menghasilkan desain software:
- Desain data: mentransformasi model domain informasi ke struktur data
- Desain arsitektur: menggambarkan relasi antar elemen struktural utama program
- Desain interface : mendeskripsikan bagaimana software berkomunikasi with user
- Desain prosedur: mentransformasikan elemen structural arsitektur program ke sebuah deskripsi prosedur dari komponen software.
Evolusi desain software:
- Konstruksi program modular[DEN73] dan metode perbaikan top-down[WIR71].
- Pemrograman terstruktur [DAH71, MIL72].
- Perpindahan data flow/data structure ke sebuah defenisi desain[JAC75][WAR74].
- Pendekatan berorientasi object[JAC92][GAM95].
Fitur umum metode desain software:
- Sebuah mekanisme untuk perpindahan sebuah model analisa ke representasi desain
Sebuah notasi untuk merepresentasi komponen fungsional dan interface-nya.
Heuristic untuk perbaikan dan partisi
Panduan untuk assessment kualitas
- Evaluasi “iterasi pertama” dari struktur program untuk mengurangi perangkaian dan meningkatkan kohesi.
- Usahakan meminimalkan struktur dengan fan-out yang tinggi; usahakan untuk melakukan fan-in pada saat kedalaman (depth) bertambah.
- Jagalah supaya lingkup efek dari suatu model ada dalam lingkup control.
- Evaluasi interface modul untuk mengurangi kompleksitas dan redundansi.
- Tetapkan modul-modul yang fungsinya dapat diprediksi, tetapi hindari modul yang terlalu restriktif.
- Usahakan modul-modul “entri kontrol” dengan menghindari “hubungan patalogis”
- Kemaslah software berdasarkan batasan desain dan persyaratan probabilitas.
Proses Desain
Desain software --> sebuah proses iteratif dimana kebutuhan diterjemahkan ke sebauh “blueprint” untuk mengkonstruksi software.
Desain direpresentasikan pada level atas abstraction. Saat iterasi desain terjadi, perbaikan subsequent membawa ke representasi desain pada level abstraksi yang lebih bawah.
Kualitas desain sangat penting. Dua metode digunakan untuk mengecek kualitas:
a) Tinjauan ulang teknis formal, dan b) desain walkthrough
Tiga fitur umum sebuah desain yang baik dari McGlaughlin’s [McG91]:
- Desain harus mengimplementasikan semua kebutuhan(eksplisit/implisit)
- Desain harus dapat dibaca dan dimengerti
- Desain harus menyediakan suatu gambar lengkap software pada aspek aspek data, fungsi dan perilaku.
Kualitas Desain
Untuk mengevaluasi sebuah desain software, sebauh criteris kualitas desain dapat digunakan.
Berikut panduan untuk sebuah desain yang baik:
- Sebuah desain harus A design should exhibit a hierarchical organization about software
- Sebuah desain harus modular berdasarkan pada partisi logical.
Sebuah desain terdiri dari data dan abstraksi prosedural.
Sebuah desain harus membawa ke modul dengan fitur fungsional yang independen.
Sebuah desain harus membawa interface yang sederhana antar modul.
Sebuah desain harus diturunkan menggunakan metode yang dapat berulang.
Proses desain software memacu desain yang baik dalam aplikasi dengan prinsip desain fundamental, metodologi yang sistematik, dan melalui review(pengulangan).
Prinsip Desain
David [DAV95] memaparkan sekumpulan prinsip untuk desain software:
- Proses desain seharusnya tidak bertahan dari “tunnel vision”.
- Desain harus dapat di trace ke model analisa.
- Desain seharusnya tidak menemukan/invent wheel.
- Desain harus “memperkecil jarak intellectual” antara software dan masalah-masalah pada dunia nyata.
- Desain harus mengeluarkan uniformity dan integrasi.
- Desain harus terstruktur untuk mengakomodasi perubahan.
- Desain harus terstruktur untuk mendegradasi secara halus(degrade gently).
- Desain bukan coding.
- Desain harus di-assessed untuk kualitas.
Desain harus diulang untuk meminimalis kesalahan konsep.
Faktor kualitas eksternal: diobservasi oleh user.
Faktor kualitas internal: penting untuk engineer.
Konsep Desain
Abstraksi:
Tiap langkah pada proses software engineering adalah sebuah perbaikan pada tingkatan abstraksi dari solusi software.
- Abstraksi data: Sekumpulan data
- Abstraksi prosedural:
Satu urutan instruksi pada sebuah fungsi spesifik
- Abstraksi kontrol:
Sebuah program mengkontrol mekanisme tanpa menspesifikasikan detail internal.
Refinement(perbaikan): Perbaikan sebenarnya adalah sebuah proses dari elaborasi.
Stepwise dari perbaikan adalah sebuah strategi desain top-down yang dikeluarkan oleh Niklaus [WIR71].
Arsitektur sebuah program dikembangkan dengan sukses memperbaiki
level detail procedural.
Proses perbaikan program analog terhadap proses perbaikan dan partisi yang digunakan selama analisa kebutuhan. Perbedaan utama berada pada level detail implementasi, disamping pendekatannya.
Abstraksi dan perbaikan secara komplemen dikonsep.
Abstraksi memungkinkan seorang desainer untuk menspesifikasi prosedur dan data w/o detail.
Perbaikan membantu desainer untuk me-reveal detail low-level.
Konsep Desain - Modularity
Konsep modularity telah dipakai selama hampir empat dekade.
Software dibagi komponen dengan nama dan alamat yang berbeda, disebut modul.
Meyer [MEY88] mendefenisikan lima kriteria yang memungkinkan kita mengevaluasi sebuah metode desain dengan bergantung kepada kemampuannya mendefenisikanfive sebuah sistem modular efektif:
Modular decomposability: sebuah metode desain menyediakan sebuah mekanisme sistematik untuk men- decompose atau membagi masalah ke sub-masalahà mengurangi kompleksitas dan mendapatkan modularity
Modular composability: sebuah metode desain memungkinkan komponen desain yang telah ada dirakit ke sebuah sistem baru.
Modular understandability: sebuah modul dapat dimengerti sebagai sebuah unit yang berdiri sendiri dan akan lebih mudah membangun dan mengubahnya.
Modular continuity: perubahan kecil terhadap kebutuhan sistem menghasilkan perubahan pada tiap modul, dibanding perubahan system-wide.
Modular protection: sebuah kondisi aberrant terjadi dalam sebuah modul dan efeknya di-constrain
dalam modul.
Arsitektur Software
Arsitektur software adalah struktue hirarki dari komponen program components dan interaksinya.
Shaw dan Garlan [SHA95a] menggambarkan sekumpulan properti desain arsitektur:
Properti structural : Desain arsitektur mendefenisikan komponen sistem dan interaksinya.
Properti extra-functional : Desain arsitektur harus meng-address bagaimana arsitektur desain menerima kebutuhan untuk performance, kapasitas, ketersediaan(reliability), adaptability, keamanan.
Kumpulan sistem yang berhubungan:
desain arsitektur harus menggambar pola yang dapat diulang pada desain dengan sistem yang sama.
Metode desain arsitektural yang berbeda:
Model structural: merepresentasikan arsitektur sebagai sebuah koleksi terorganisir dari komponen
Model framework: meningkatkan level desain abstraksi dengan mengidentifikasi secara berulang
framework desain arsitektur(pola-pola)
Model dinamis: meng-address aspek-aspek perilaku arsitektur program
Model prosess: fokus pada desain bisnis atau proses teknis
Model functional: dapat digunakan untuk merepresentasikan hierarki fungsional sebuah sistem
Partisi Structural
Struktur program harus dipartisi secara horizontal dan vertikal. (Gambar 13.4)
(1)Partisi horizontal menggambarkan cabang-cabang yang terbagi dari hierarki modular untuk tiap fungsi program utama.
Cara termudah adalah mempartisi sebuah sistem menjadi:
input, transformasi data(pemrosesan), dan output
Keuntungan dari partisi horizontal:
- mudah untuk diuji, di-maintain, dan extend
- efek yang lebih kecil pada perubahan propagasi atau error propagasi
Kerugian: lebih banyak data dilewatkan melalui interface modul
--> menyulitkan kontrol keseluruhan dari aliran program
(2) Partisi vertical memaparkan kontrol dan work harus terdistribusi top-down dalam struktur program.
Keuntungan: baik pada kesesuain untuk perubahan:
- mudah untuk me-maintain perubahan
- mengurangi pengaruh perubahan dan propagasi.
Desain Modular Efektif
Informasi yang disimpan: Modul-modul seharusnya dispesifikasi dan didesain sehingga detail internal dari modul darus dapat terlihat atau dapat diakses terhadap modul lainnya.
Keuntungan utama: mengurangi pengaruh perubahan pada testing(pengujian) dan maintenance(perawatan).
Independen fungsional: Mendesain modul-modul berdasarkan fitur fungsional independen.
Keuntungan utama: modularity efektif
Cohesion: sebuah ekstensi alami dari konsep informasi yang disimpan sebuah modul dapat menampilkan sejumlah tusk
Sebuah modul cohesive menampilkan sebuha task tunggal dalam sebuah prosedur dengan interaksi kecil dengan lainnya.
Goal: untuk mencapai cohesion yang tinggi untuk modul-modul pada sebuah sistem.
Tipe-tipe yang berbeda dari cohesion:
- coincidentally cohesive: sekumpulan task yang berhubungan satu sama lain secara bebas.
- logically cohesive: koneksi logical antara elemen-elemen pemrosesan
- communication cohesion: data di-share antar elemen-elemen pemrosesan
- procedural cohesion: pemesanan antara elemen-elemen pemrosesan
Desain Modular Efektif
Coupling: (Gambar 13.8)
Suatu ukuran interkoneksi antar modul-modul dalam sebuah struktur program.
Coupling tergantung pada kompleksitas interface antar modul.
Goal: mencoba untuk coupling terendah yang mungkin antar modul.
Coupling yang baik à mengurangi atau mencegah pengaruh perubahan dan efek ripple.
à mengurangi biaya pada perubahan program, testing,
maintenance
Tipe-tipe coupling:
- data coupling: parameter passing atau interaksi data
- control coupling: share logical kontrol yang berhubungan (untuk sebuah data kontrol)
- common coupling: sharing data umum
- content coupling: modul, penggunaan data atau pengontrolan
informasi di-maintain modul lain.
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 :
1. Dokumentasi desain
2. Dokumentasi user untuk training
3. Dokumentasi operasi
4. Dokumentasi referensi user
1. 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.
2.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
3. Operation Documentation
Purpose :
- Bagian operasi dari departemen layanan informasi harus mengoperasikan sistem
setelah
- diimplementasikan 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
4. 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
JENIS DOKUMENTASI DAN STRUKTUR DOKUMENTASI
Ian Sommerville mengklasifikasi dokumentasi ke dalam dua kelas, yaitu dokumentasi
proses dan dokumentasi produk.
Dokumentasi proses merupakan dokumen yang menyimpan semua proses dari
pembangunan dan pemeliharaan perangkat lunak, termasuk perencanaan,
penjadwalan, lembar kerja, serta memo maupun email.
Dokumen produk yaitu dokumen yang merupakan penjelasan dari perangkat lunak
yang dibangun. Dokumentasi pengguna dan dokumentasi sistem termasuk dalam
dokumen produk. Dokumentasi pengguna yaitu dokumen yang menjelaskan tentang
bagaimana penggunaan dari produk perangkat lunak tersebut, sedangkan dokumen
sistem yaitu semua dokumen yang menjelaskan tentang sistem yang dibagun, mulai
dari spesifikasi kebutuhan sampai dengan pengujian perangkat lunak.
Pada sumber lain ada yang mengklasifikasikan dokumentasi ke dalam empat bagian
yaitu dokumen kebutuhan, arsitektur dan desain, dokumen teknis, dokumen end user, dan
dokumen pemasaran. Dokumen kebutuhan merupakan dokumen yang menjelaskan tentang
atribut, kemampuan, karakterisitik, atau kualitas dari suatu sistem yang merupakan dasar dari
pembuatan suatu perangkat lunak. Dokumen arsitektur dan disain yaitu dokumen yang
menjelaskan tentang arsitektur sistem dan prinsip – prinsip konstruksi yang akan digunakan
dalam desain komponen perangkat lunak. Dokumen teknis merupakan dokumentasi dari
kode, algoritma dan interface. Dokumen end user merupakan dokumen manual tentang
bagaimana perangkat lunak tersebut digunakan. Dokumen pemasaran berisi bagaimana cara
pemasaran dari produk dan analisis permintaan pasar.
KUALITAS DOKUMENTASI
Berdasarkan hasil survei yang dilakukan oleh Andrew Forward, software engineers
mengungkapkan dokumen seperti apa yang dianggap berkualitas bagus, jelek dan sangat
buruk.
1) Dokumen berkualitas bagus
Arsitektur dan informasi dokumentasi lainnya selalu valid atau setidaknya menyediakan
panduan sejarah yang dapat berguna untuk pemeliharaan perangkat lunak.
Inline comments pada kode program cukup baik dalam memberikan informasi yang berguna
untuk pemeliharaan perangkat lunak.
2) Dokumen berkualitas jelek
- Dokumentasi untuk semua jenis sering sekali tidak diperbaharui (out of date)
- Sistem mempunyai terlalu banyak dokumentasi
- Penulisan dokumentasi yang buruk
- Pengguna kesulitan menemukan isi yang berguna dalam dokumentasi
- Pembuatan dokumentasi yang memakan waktu yang tidak sebanding dengan keuntungan dari dokumentasi tersebut
3) Dokumen berkualitas sangat buruk
Sebuah dokumentasi yang informasinya tidak dapat Secara umum dokumentasi yang bagus yaitu dokumen yang ditulis dengan baik,
mudah dibaca dan dimengerti serta memberikan informasi yang lengkap dan akurat.
Walaupun pembuatan dokumen yang seperti ini mungkin akan menyita waktu yang lebih
banyak, tetapi dengan dokumen yang baik akan sangat membantu baik itu pengembang
maupun pengguna program tersebut.
Berdasarkan survei Andrew Forward menunjukkan bahwa isi dokumen merupakan
atribut dokumen yang paling penting dari sebuah dokumentasi perangkat lunak. Tiga atribut
lainnya yang dianggap penting yaitu up-to-date, availability, use of examples. Atribut-atribut
tersebut yang sangat menentukan kualitas suatu dokumen, walaupun atribut lainnya juga
tidak kalah pentingnya.
Dokumentasi Desain
Dokumentasi desain berisi penjelasan rinci tentang inti teknis dari rekayasa perangkat
lunak yang meliputi struktur data, arsitektur program, interface dan detail prosedural. Gambar
1 menunjukan contoh outline dari dokumen desain yang diambil dari buku Pressman. Berikut
penjelasan perbagian dari Pressman mengenai outline tersebut:
Bagian I berisi ruang lingkup dari kerja desain.
Bagian II berisi desain data, struktur file eksternal dan referensi silang yang
menghubungkan objek data dengan file tertentu.
Bagian III berisi desain arsitektur.
Bagian IV dan V, pada bagian ini berkembang pada saat desain interface dan
procedural dimulai.
Bagian VI berisi referensi silang yang bertujuan utnuk menetapkan bahwa semua
persyaratan dipenuhi oleh desainperangkat lunak dan menunjukkan modul mana yang
krites terhadap implementasi persyaratan spesifik.
Bagian VII berisi tahap pertama dari pembuatan dokumentasi pengujian.
Bagian VIII dan IX berisi data tambahan meliputi deskripsi algoritma, prosedur
alternative, data dalam bentuk tabel, kutipan dari dokumen lain, dan informasi relevan
lainnya.
Dokumentasi Pengujian
Pengujian perangkat lunak merupakan sederetan langkah yang digunakan untuk
melakukan pengujian atau pengecekan terhadap unit program ataupun sistem lengkap dari
perangkat lunak untuk menjamin bahwa persyaratan sistem telah dipenuhi. Pengujian
memastikan bahwa program tersebut telah berfungsi sebagaimana mestinya. Rencana, hasil
serta prosedur pengujian harus didokumentasikan dalam suatu dokumen pengujian.
Tidak ada komentar:
Posting Komentar