Rekayasa Perangkat Lunak
March 23, 2020 | Author: Anonymous | Category: N/A
Short Description
Download Rekayasa Perangkat Lunak...
Description
Rekayasa Perangkat Lunak
DAFTAR ISI BAB 1. PENGANTAR RPL ..................................................................................................... 1 A. PENGERTIAN RPL .......................................................................................................................... 1 B. KEGUNAAN RPL .......................................................................................................................... 11 C. PERKEMBANGAN RPL ................................................................................................................. 12 D. DESKRIPSI RPL ............................................................................................................................. 12 E. KARAKTERISTIK RPL .................................................................................................................... 13 F. KOMPONEN RPL ......................................................................................................................... 13 G. APLIKASI RPL ............................................................................................................................... 13
BAB 2. MANAGING SOFTWARE PROJECTS ........................................................................ 15 A. PROJECT MANAGEMENT CONCEPT ............................................................................................ 15 B. SOFTWARE PROJECT PLANNING ................................................................................................. 17 C. RISK ANALYSIS AND MANAGEMENT .......................................................................................... 20 D. SQA ............................................................................................................................................. 24
BAB 3. METODE KONVENSIONAL UNTUK SOFTWARE ENGINEERING ................................ 26 A. SYSTEM ENGINEERING ............................................................................................................... 26 B. REQUIREMENT ENGINEERING .................................................................................................... 30
BAB 4. ANALISIS ............................................................................................................... 35 A. KONSEP DAN PRINSIP ANALISIS .................................................................................................. 35 B. MODEL ANALISIS ........................................................................................................................ 42 C. ANALISIS TERSTRUKTUR ............................................................................................................. 44 D. KAMUS DATA .............................................................................................................................. 46
BAB 5. DESAIN .................................................................................................................. 48 A. PROSES DESAIN .......................................................................................................................... 48 B. PRINSIP‐PRINSIP DESAIN ............................................................................................................ 50 C. KONSEP DESAIN .......................................................................................................................... 51 D. EFECTIVE MODULAR DESIGN ...................................................................................................... 57 E. ARCHITECTURAL DESIGN ............................................................................................................ 58 F. USER INTERFACE DESIGN............................................................................................................ 62
BAB 6. DESAIN UNTUK SYSTEM REAL‐TIME ...................................................................... 64 A. SYSTEM REAL‐TIME ..................................................................................................................... 64 B. ANALISIS DAN SIMULASI UNTUK SYSTEM REAL‐TIME ............................................................... 68
C. DESAIN REAL‐TIME .................................................................................................................... 75
BAB 7. TEKNIK PENGUJIAN PERANGKAT LUNAK ............................................................... 77 A. DASAR‐DASAR PENGUJIAN PERANGKAT LUNAK ........................................................................ 77 B. TEST CASE DESIGN .................................................................................................................... 78 C. WHITE‐BOX TESTING .................................................................................................................. 80 D. CONTROL STRUCTURE TESTING ................................................................................................. 84
BAB 8. STRATEGI PENGUJIAN PERANGKAT LUNAK............................................................ 98 A. PENDEKATAN STRATEGIS KE PENGUJIAN PERANGKAT LUNAK .................................................. 98 B. MASALAH‐MASALAH STRATEGIS ................................................................................................ 99 C. PENGUJIAN UNIT ...................................................................................................................... 100 D. PENGUJIAN INTEGRASI ............................................................................................................. 102 E. PENGUJIAN VALIDASI ............................................................................................................... 103 F. PENGUJIAN SISTEM .................................................................................................................. 103 G. PENGUJIAN DEBUGGING .......................................................................................................... 104
BAB 9. OBJECT ORIENTED SOFTWARE ENGINEERING ...................................................... 109 A. KONSEP DAN PRINSIP OBJECT ORIENTED ................................................................................ 109 B. OBJECT ORIENTED ANALIS ........................................................................................................ 118 C. OOA VS CONVENSIONAL .......................................................................................................... 125 D. UNIFIED MODELLING LANGUAGE (UML) .................................................................................. 125 E. OBJECT ORIENTED DESIGN ....................................................................................................... 135
BAB 10. CLIENT SERVER SOFTWARE ENGINEERING ......................................................... 137 A. STRUKTUR DARI SISTEM CLIENT‐ SERVER ................................................................................ 137 B. SOFTWARE ENGINEERING UNTUK SISTEM CLIENT SERVER ..................................................... 145 C. DESAIN UNTUK CLIENT‐SERVER SISTEM ................................................................................... 150
BAB 11. WEB ENGINEERING ........................................................................................... 156 A. ATRIBUT DARI APLIKASI WEB ................................................................................................... 161 B. DESAIN UNTUK WEB‐BASED APPLICATION ............................................................................. 162 C. TESTING WEB‐DESIGN APLICATION .......................................................................................... 165
BAB 1 PENGANTAR RPL Rekayasa
perangkat
lunak
merupakan
sebuah
disiplin
ilmu
yang
bertujuan
mengembangkan sistem perangkat lunak yang efektif dari segi biaya. Perangkat lunak bersifat abstrak dan tidak nyata. Rekayasa perangkat lunak masih merupakan disiplin yang relatif muda. Istilah rekayasa perangkat lunak pertama kali diajukan pada tahun 1968.
A. PENGERTIAN RPL Banyak orang menyamakan istilah perangkat lunak dengan program komputer. Sesungguhnya pandangan ini terlalu dangkal, perangkat lunak tidak hanya mencakup program, tetapi juga semua dokumentasi dan konfigurasi data yang berhubungan (Sommerville, 2003). Rekayasa perangkat lunak adalah disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal spesifikasi sistem sampai pemeliharaan. Di sisi lain terdapat istilah yang juga tidak kalah populer adalah computer science atau ilmu komputer. Pada intinya computer science berhubungan dengan teori dan metode yang mendasari sistem komputer dan perangkat lunak. Sedangkan rekayasa perangkat lunak berhubungan
dengan
masalah-masalah
praktis
dalam
memproduksi
perangkat
lunak.
Pengetahuan tetang computer science sangat penting bagi perekayasa perangkat lunak sama seperti pengetahuan tentang fisika sangat penting bagi teknik kelistrikan. Istilah lain yang juga populer adalah rekayasa sistem atau rekayasa sistem berbasis komputer.
Rekayasa
sistem
berhubungan
dengan
pengembangan
perangkat
keras,
perancangan kebijakan dan proses, dan penyebaran sistem sebagaimana pada rekayasa perangkat lunak. Rekayasa sistem merupakan disiplin yang lebih tua dari rekayasa perangkat lunak.
1. PRODUCT Saat ini perangkat lunak memiliki dua peran. Peran pertama berfungsi sebagai sebuah produk dan peran kedua sebagai kendaraan yang mengantarkan sebuah produk (Pressman, 2002). Sebagai produk
perangkat lunak mengantarkan potensi perhitungan yang dibangun
oleh perangkat lunak komputer. Tidak peduli apakah perangkat lunak ada dalam telepon seluler, dalam mainframe komputer. Perangkat lunak merupakan transformer informasi yang memproduksi,
mengatur,
memperoleh,
memodifikasi,
menampilkan
atau
menyebarkan
1
informasi dimana pekerjaan ini dapat menjadi sederhana suatu bit tunggal atau sekompleks simulasi multimedia. Sebagai kendaraan yang dipakai untuk mengantarkan produk, perangkat lunak berlaku sebagai dasar untuk kontrol komputer (sistem operasi), komunikasi informasi (jaringan komputer). Untuk memperoleh pemahaman tentang perangkat lunak serta pemahaman tentang rekayasa perangkat lunak penting juga untuk mengetahui karakteristik yang membuat perangkat lunak berbeda dengan dengan produk lain yang dihasilkan oleh manusia. Ketika perangkat lunak dibuat proses kreatif manusia (analisis, desain, konstruksi dan pengujian) diterjemahkan ke dalam bentuk fisik.
2. PROCESS Proses perangkat lunak merupakan serangkaian kegiatan dan hasil-hasil relevan yang menghasilkan perangkat lunak. Kegiatan-kegiatan ini sebagian besar dilakukan oleh perekayasa perangkat lunak. Ada empat kegiatan proses dasar perangkat lunak: 1) Spesifikasi perangkat lunak, fungsional perangkat lunak dan batasan kemampuan operasinya harus didefinisikan. 2) Pengembangan perangkat lunak, perangkat lunak yang memenuhi spesifikasi tersebut harus dipenuhi. 3) Validasi perangkat lunak, perangkat lunak harus divalidasi untuk menjamin bahwa perangkat lunak melakukan apa yang diinginkan oleh pelanggan.
4) Evolusi perangkat lunak, perangkat lunak harus dikembangkan untuk memenuhi kebutuhan pelanggan yang berubah-ubah. Proses perangkat lunak yang berbeda mengatur kegiatan ini dengan cara yang berbeda dan dijelaskan dengan tingkat kerincian yang berbeda pula. Waktu kegiatan bervariasi, sebagaimana hasilnya. Proses perangkat lunak sangat rumit dan seperti semua proses intelektual, bergantung pada penilaian manusia. Karena dibutuhkan penilaian dan kreatifitas keberhasilan usaha untuk mengotomasi proses perangkat lunak menjadi terbatas. Satu alasan mengapa otomasi proses memiliki cakupan terbatas adalah adanya keragaman proses perangkat lunak. Tidak ada proses yang ideal dan organisasi berbeda yang mengembangkan pendekatan yang benar-benar berbeda dalam pengembangan perangkat lunak.
2
1. Model Proses Perangkat Lunak Model proses perangkat lunak merupakan deksripsi yang disederhanakan dari proses perangkat lunak yang dipresentasikan dengan sudut pandang tertentu. Model sesuai sifatnya, merupakan penyederhanaan sehingga model proses bisa mencakup kegiatan yang merupakan bagian dari proses perangkat lunak, produk perangkat lunak, peran orang yang terlibat pada rekayasa perangkat lunak. a.
Model Air Terjun (Waterfall) Model ini dikenal sebagai model air terjun atau siklus hidup pengembangan perangkat lunak. Model ini dapat dilihat pada Gambar 1.1. Tahap-tahap utama dari model ini memetakan kegiatan-kegiatan pengembangan dasar, yaitu: 1) Analisis dan Definisi persyaratan. Pelayanan, batasan dan tujuan sistem ditentukan melalui konsultasi dengan user sistem. Persyaratan ini kemudian didefinisikan secara rinci dan berfungsi sebagai spesifikasi sistem. 2) Perancangan sistem dan perangkat lunak. Proses perancangan sistem membagi persyaratan dalam sistem perangkat keras atau perangkat lunak. Kegiatan ini menentukan arsitektur sistem secara keseluruhan. Perancangan perangkat lunak melibatkan identifikasi dan deskripsi abstraksi sistem perangkat lunak yang mendasar dan hubungan-hubungannya. 3) Implementasi dan pengujian unit. Pada tahap ini, perancangan perangkat lunak direalisasikan sebagai serangkaian program atau unit program. Pengujian unit melibatkan verifikasi bahwa setiap unit telah memenuhi spesifikasi. 4) Integrasi dan pengujian sistem. Unit program atau program individual diintegrasikan dan diuji sebagai sistem yang lengkap untuk menjamin bahwa persyaratan sistem telah dipenuhi. Setelah pengujian sistem, perangkat lunak dikirim kepada pelanggan. 5) Operasi dan pemeliharaan. Biasanya merupakan fase siklus hidup yang paling lama. Sistem diinstall dan dipakai. Pemeliharaan mencakup koreksi dan berbagai error yang tidak ditemukan pada tahap-tahap terdahulu, perbaikan atas implementasi unit sistem dan pengembangan pelayanan system, sementara persyaratan-persyaratan baru ditambahkan.
3
Gambar 1.1 Model Waterfall b.
Model Sekuensial Linier Gambar 1.2a menggambarkan sekuensial linier untuk rekayasa perangkat lunak, yang sering disebut juga dengan “siklus kehidupan klasik” atau “model air terjun.”
Gambar 1.2a Fase lingkaran pemecahan masalah (Raccoon, 1995)
4
Problem Definition Status Quo
Solution Integration
Teknikal Development Problem Definition Status Quo
Status Quo
Solution Integration
Teknikal Development Problem Definition Status Quo
Solution Integration
Teknikal Development
Gambar 1.2b Fase-fase di dalam fase lingkaran pemecahan masalah (Raccoon, 1995)
Pemodelan Sistem Informasi
Analisis
Desain
Kode
Gambar 1.3 Model sekuensial linier
Tes
Sekuensial linier mengusulkan sebuah pendekatan kepada perkembangan perangkat lunak yang sistematik dan sekuensial yang mulai pada tingkat dan kemajuan sistem pada seluruh analisis, desain, kode, pengujian, dan pemeliharaan. Dimodelkan setelah siklus rekayasa konvensional, model sekuensial linier melingkupi aktivitas-aktivitas sebagai berikut: 1. Rekayasa dan Pemodelan Sistem/Informasi Karena perangkat lunak selalu merupakan bagian dari sebuah sistem (bisbis) yang lebih besar, kerja dimulai dengan membangun syarat dari semua elemen sistem dan mengalokasikan beberapa subset dari kebutuhan ke perangkat lunak tersebut. Pandangan sistem ini penting ketika perangkat lunak harus berhubungan dengan
5
elemen-elemen yang lain seperti perangkat lunak, manusia, dan database. Rekayasa dan analisis sistem menyangkut pengumpulan kebutuhan pada tingkat sistem dengan sejumlah kecil analisis serta desain tingkat puncak. Rekayasa informasi mencakup juga pengumpulan kebutuhan pada tingkat bisnis strategis dan tingkat area bisnis. 2. Analisis Kebutuhan Perangkat Lunak Proses pengumpulan kebutuhan diintensifkan dan difokuskan, khususnya pada perangkat lunak. Untuk memahami sifat program yang dibangun, perekayasa perangkat lunak (analis) harus memahami domain informasi, tingkah laku, unjuk kerja, dan antarmuka (interface) yang diperlukan. Kebutuhan baik untuk sistem maupun perangkat lunak di dokumentasikan dan dilihat lagi dengan pelanggan. 3. Desain Desain perangkat lunak sebenarnya adalah proses multi langkah yang berfokus pada empat atribut sebuah program yang berbeda; struktur data, arsitektur perangkat lunak, representasi interface, dan detail (algoritma) procedural. Proses desain menerjemahkan syarat/kebutuhan ke dalam sebuah representasi perengkat lunak yang dapat diperkirakan
demi
kualitas
sebelum
dimulai
pemunculan
kode.
Sebagaimana
persyaratan, desain didokumentasikan dan menjadi bagian dari konfigurasi perangkat lunak. 4. Generasi Kode Desain harus diterjemahkan ke dalam bentuk mesin yang bisa dibaca. Langkah pembuatan kode melakukan tugas ini. Jika desain dilakukan dengan cara yang lengkap, pembuatan kode dapat diselesaikan secara mekanis. 5. Pengujian Sekali kode dibuat, pengujian program dimulai. Proses pengujian berfokus pada logika internal perangkat lunak, memastikan bahwa semua pernyataan sudah diuji, dan pada eksternal fungsional – yaitu mengarahkan pengujian untuk menemukan kesalahankesalahan dan memastikan bahwa input yang akan memberikan hasil actual yang sesuai dengan hasil yang dibutuhkan. 6. Pemeliharaan Perangkat lunak akan mengalami perubahan setelah disampaikan kepada pelanggan (perkecualian yang mungkin adalah perangkat lunak yang dilekatkan). Perubahan akan terjadi karena kesalahan-kesalahan ditentukan, karena perangkat lunak harus
6
disesuaikan
untuk
mengakomodasi
perubahan-perubahan
di
dalam
lingkungan
eksternalnya (contohnya perubahan yang dibutuhkan sebagai akibat dari perangkat
peripheral atau sistem operasi yang baru), atau karena pelanggan membutuhkan perkembangan
fungsional
atau
unjuk
kerja.
Pemeliharaan
perangkat
lunak
mengaplikasikan lagi setiap fase program sebelumnya dan tidak membuat yang baru lagi. Model sekuensial linier adalah paradigma rekayasa perangkat lunak yang paling luas dipakai dan paling tua. Tetapi kritik dari paradigma tersebut telah menyebabkan dukungan aktif untuk mempertanyakan kehandalannya (Hanna, 1995). Masalah-masalah yang kadang–kadang terjadi ketika model sekuensial linier diaplikasikan adalah: a)
Jarang sekali proyek nyata mengikuti aliran sekuensial yang dianjurkan oleh model. Meskipun model linier bias mengakomodasi iterasi, model itu melakukannya dengan cara tidak langsung. Sebagai hasilnya, perubahan-perubahan dapat menyebabkan keraguan pada saat tim proyek berjalan.
b)
Kadang-kadang sulit bagi pelanggan untuk menyatakan semua kebutuhannya secara ekplisit. Model linier sekuensial memerlukan hal ini dan mengalami kesulitan untuk mengakomodasi ketidakpastian natural yang ada pada bagian awal beberapa proyek.
c)
Pelanggan harus bersikap sabar. Sebuah versi kerja dari program-program itu tidak akan diperoleh sampai akhir waktu proyek dilalui. Sebuah kesalahan besar, jika tidak terdeteksi sampai program yang bekerja tersebut dikaji ulang, bias menjadi petaka.
d)
Pengembang sering melakukan penundaan yang tidak perlu. Di dalam analisis yang menarik tentang proyek actual, (Bradac, 1994) mendapatkan bahwa sifat alami dari siklus kehidupan klasik membawa kepada blocking state dimana banyak anggota tim proyek harus menunggu tim yang lain untuk melengkapi tugas yang saling memiliki ketergantungan. Kenyataannya, waktu yang dipakai untuk menunggu bisa mengurangi waktu untuk usaha produktif! Blocking state cenderung menjadi lebih lazim pada awal dan akhir sebuah proses sekuensial linier. Masing-masing dari masalah tersebut bersifat riil. Tetapi paradigm siklus kehidupan
klasik memiliki tempat yang terbatas namun penting di dalam kerja rekayasa perangkat lunak. Paradigma itu memberikan template dimana metode analisis, desain, pengkodean, pengujian, dan pemeliharaan bisa dilakukan. Siklus kehidupan klasik tetap menjadi model bagi rekayasa perangkat lunak yang paling luas dipakai. Sekalipun memiliki kelemahan, secara signifikan dia
7
lebih baik daripada pendekatan yang sifatnya sembrono kepada pengembangan perangkat lunak. c.
Model Prototipe Sering seorang pelanggan mendifinisikan serangkaian sasaran umum bagi perangkat lunak, tetapi tidak melakukan mengidentifikasi kebutuhan output, pemrosesan, ataupun input detail. Pada kasus yang lain, pengembang mungkin tidak memiliki kepastian terhadap efisiensi algoritme, kemampuan penyesuaian dari sebuah system operasi, atau bentukbentuk yang harus dilakukan oleh interaksi manusia dengan mesin. Dalam hal ini, serta pada banyak situasi yang lain, prototyping paradigm mungkin menawarkan pendekatan yang terbaik.
Prototyping paradigma (Gambar 1.4) dimulai dengan pengumpulan kebutuhan. Pengembang dan pelanggan bertemu dan mendefinisikan obyektif keseluruhan dari perangkat lunak, mengidentifikasi segala kebutuhan yang diketahui, dan area garis besar dimana definisi lebih jauh merupakan keharusan kemudian dilakukan “perancangan kilat”. Perancangan kilat berfokus pada penyajian dari aspek –aspek perangkat lunak tersebut yang akan Nampak bagi pelanggan/pemakai (contohnya pendekatan input dan format output). Perancangan kilat membawa kepada konstruksi sebuah prototype. Prototipe tersebut dievaluasi oleh pelanggan/pemakai dan dipakai untuk menyaring kebutuhan pengembangan perangkat lunak. Iterasi terjadi pada saat protipe disetel untuk memenuhi kebutuhan pelanggan, dan pada saat yang sama memungkinkan pengembang untuk secara lebih baik memahami apa yang harus dilakukannya.
Membangun Memperbaiki Market
Mendengarkan Pelanggan
Uji PelangganMengendalikan Market
Gambar 1.4 Prototipe Paradigma Secara ideal prototype berfungsi sebagai sebuah mekanisme untuk mengidentifikasi kebutuhan perangkat lunak. Bila prototype yang sedang bekerja dibangun, pengembang harus mempergunakan fragmen-fragmen program yang ada atau mengaplikasikan alat-alat
8
bantu (contohnya report generator, window manager, dll) yang memungkinkan program yang bekerja untuk dimunculkan secara cepat. Tetapi apa yang kita lakukan dengan prototype tersebut pada saat dia sudah melayani usulan yang digambarkan di atas? (Brooks, 1975) memberikan jawabannya: Pada sebagian besar proyek, system pertama yang dibangun baru saja bisa dipergunakan. Sistem mungkin terlalu pelan, terlalu besar, janggal di dalam pemakaian, atau bahkan ketiganya. Tidak ada alternatif lain selain mulai lagi, tidak dengan halus tetapi dengan lebih halus lagi, dan membangun sebuah versi yang dirancang kembali di mana masalah-masalah tersebut bisa diselesaikan … Ketika sebuah konsep system baru atau teknologi baru dipergunakan, seseorang harus membangun sebuah system sebagai pembuangan, bahkan untuk perencanaan terbaik sekalipun, tidak akan mudah untuk membuatnya benar pada pertama kalinya. Dengan demikian, pertanyaan manajemen tidaklah untuk membangun sebuah system contoh dan untuk membuangnya. Anda akan melakukannya. Satu-satunya pertanyaan adalah apakah akan merencanakan lebih dulu untuk membangun sebuah pembuangan, atau menjanjikan untuk menyampaikan pembuangan tersebut kepada pelanggan ………….. Prototipe bisa berfungsi sebagai “system yang pertama”. Brooks setuju bila kita membuangnya. Tetapi mungkin ini merupakan pandangan yang ideal. Memang benar bahwa baik pelanggan maupun pengembang menyukai paradigma prototype. Para pemakai
merasa
enak
dengan
system
aktual,
sedangkan
pengembang
membangunnya dengan segera. Tetapi prototyping bisa juga menjadi masalah
bisa
karena
alasan-alasan sebagai berikut: a) Pelanggan melihat apa yang tampak sebagai versi perangkat lunak yang bekerja tanpa melihat bahwa prototype itu dijalin bersama-sama “dengan permen karet dan baling
wire”, tanpa melihat bahwa di dalam permintaan untuk membuatnya bekerja, kita belum mencantumkan kualitas perangkat lunak secara keseluruhan atau kemampuan pemeliharaan untuk jangka waktu yang panjang. Ketika diberi informasi bahwa produk harus dibangun lagi agar tingkat kualitas yang tinggi bisa dijaga, pelanggan akan meneriakkan kecurangan dan permintaan agar dipakai “beberapa campuran” untuk membuat protipe menjadi sebuah produk yang bekerja yang lebih sering terjadi, sehingga manajemen pengembangan perangkat lunak menjadi penuh dengan belas kasihan. b) Pengembang sering membuat kompromi-kompromi implementasi untuk membuat prototype bekerja dengan cepat. Sistem operasi atau bahasa pemrograman yang tidak
9
sesuai bisa dipakai secara sederhana karena mungkin diperoleh dan dikenal; algoritma yang tidak efisien secara sederhana bisa diimplementasikan untuk mendemontrasikan kemampuan. Setelah selang waktu tertentu, pengembang mungkin mengenali pilihanpilihan tersebut dan melupakan semua alasan mengapa mereka tidak cocok. Pilihan yang kurang ideal telah menjadi bagian integral dari sebuah system. Meskipun berbagai masalah bisa terjadi, prototype bisa menjadi paradigm yang efektif bagi rekayasa perangkat lunak. Kuncinya adalah mmendefinisikan aturan-aturan main pada saat awal; yaitu pelanggan dan pengembang keduanya harus setuju bahwa prototype dibangun untuk berfungsi sebagai mekanisme pendefinisian kebutuhan. Prototipe kemudian disingkirkan (paling tidak sebagian), dan perangkat lunak actual direkayasa dengan tertuju kepada kualitas dan kemampuan pemeliharaan. d.
Pengembangan Evolusioner Pengembangan evolusioner berdasarkan ide untuk mengembangkan implementasi awal, memperlihatkannya kepada user untuk dikomentari, dan memperbaikinya versi demi versi sampai sistem yang memenuhi persyaratan diperoleh. Model pengembangan evolusioner dapat dilihat pada Gambar 1.5.
Penjelasan garis besar
Spesifikasi
Versi awal
Pengembangan
Versi menengah Versi akhir Versi akhir
Validasi
Versi akhir
Gambar 1.5 Model Evolusioner e.
Pengembangan Sistem Formal Pengembangan sistem formal merupakan pendekatan terhadap pengembangan perangkat lunak yang memiliki kesamaan dengan model air terjun (waterfall). Tetapi proses pengembangannya didasarkan pada transformasi matematis dari spesifikasi sistem menjadi program yang dapat dijalankan. Model pengembangan sistem formal dapat dilihat pada Gambar 1.6.
10
Gambar 1.6 Model Sistem Formal f.
Pengembangan Berorientasi Pemakaian Ulang Pada pengembangan perangkat lunak yang besar, terjadi pemakaian ulang. Hal ini biasanya terjadi secara informal ketika orang yang bekerja di proyek tersebut mengetahui adanya rancangan atau kode yang mirip dengan yang dibutuhkan. Mereka mencari rancangan
atau
kode
ini,
memodifikasinya
sebagaimana
dibutuhkan,
dan
menggabungkannya dalam sistem. Model pengembangan berorientasi pemakaian ulang dapat dilihat pada Gambar 1.7. Spesifikasi Persyaratan
Analisis Komponen
Memodifikasi Persyaratan
Perancangan Sistem dengan pemakaian ulang
Pengembangan dan integrasi
Validasi Sistem
Gambar 1.7 Model Pengembangan Berorientasi Pemakaian Ulang
B. KEGUNAAN RPL Perangkat lunak kini sudah menjadi kekuatan yang menentukan. Perangkat lunak menjadi mesin yang mengendalikan pengambilan keputusan di dalam dunia bisnis. Berfungsi sebagai dasar dari semua bentuk pelayanan serta penelitian keilmuan modern. Perangkat lunak dilekatkan pada semua sistem, seperti transportasi, medis, telekomunikasi, militer, proses industri, hiburan, produk kantor dan sebagainya. Program-program perangkat lunak sudah tersebar secara luas, dan masyarakat memandangnya sebagai kenyataan teknologi dalam kehidupan.
11
C. PERKEMBANGAN RPL Selama masa awal era komputer, perangkat lunak dilihat hanya sebagai suatu permenungan. Pemrograman komputer menjadi seni di mana di situ terdapat banyak metode yang sistematis. Perkembangan perangkat lunak sebenarnya tidak dapat diatur sampai terjadi jadwal yang bergeser, atau biaya yang mulai melonjak. Para pemrogram kemudian mulai berusaha untuk membuat semuanya benar kembali. Era kedua evolusi sistem komputer melingkupi decade pertengahan tahun 1960 dan 1970-an. Sistem multiprogram dan multiprosesor memperkenalkan konsep baru interkasi manusia dan komputer. Konsep ini membuka sebuah dunia aplikasi yang baru serta tingkat kecanggihan perangkat lunak dan perangkat keras yang baru pula. Sistem real-time dapat mengumpulkan, menganalisis, serta mengubah data dari banyak sumber sehingga proses pengontrolan dan penghasilan output tidak lagi berada dalam skala menit, melainkan detik. Kemajuan dalam penyimpanan online membawa ke generasi pertama sistem manajemen database.
Tabel 1.1 perkembangan RPL Tahun-Tahun Awal - Orientasi Batch - Distribusi terbatas - Perangkat lunak customisasi
-
Era Kedua Multiuser Real-time Database Perangkat lunak produk
Era Ketiga - Sistem terdistribusi - Embedded intelligence - Perangkat keras rendah biaya
Era Keempat - System desktop bertenaga kuat - Teknologi berorientasi objek - Sistem pakar - Jarigan syaraf tiruan - Komputasi parallel - Komputer jaringan
D. DESKRIPSI RPL Secara umum rekayasa perangkat lunak memakai pendekatan yang sistematis dan terorganisir terhadap pekerjaan karena cara ini seringkali paling efektif untuk menghasilkan perangkat lunak. Rekayasa perangkat lunak adalah disiplin ilmu yang membahas semua aspek produksi perangkat lunak. Mulai dari tahap awal spesifikasi sistem sampai pemeliharaan sistem setelah digunakan. Pada definisi ini ada dua istilah kunci: 1) Disiplin Rekayasa Perekayasa membuat suatu alat bekerja. Mereka menerapkan teori, metode, dan alat bantu yang sesuai. Selain itu mereka juga menggunakannya dengan selektif dan selalu mencoba mencari solusi terhadap permasalahan, walaupun tidak ada teori atau metode yang
12
mendukung. Perekayasa juga menyadari bahwa mereka harus bekerja dalam batasan organisasi dan keuangan, sehingga mereka berusaha mencari solusi dalam batasan-batasan ini. 2) Semua Aspek Produksi Perangkat Lunak Rekayasa perangkat lunak tidak hanya berhubungan dengan proses teknis dari pengembanga perangkat lunak, tetapi juga dengan kegiatan seperti manajemen proyek perangkat lunak dan pengembangan alat bantu, metode, dan teori untuk mendukung produksi perangkat lunak.
E. KARAKTERISTIK RPL Perangkat lunak lebih kepada logika dan bukan semata elemen fisik. Perbedaan perangkat lunak dengan perangkat keras yang mendasar adalah: 1) 2)
Perangkat lunak dibangun dan dikembangkan, tidak dibuat dalam bentuknya yang klasik. Perangkat lunak tidak pernah usang.
Sebagian besar perangkat lunak dibuat secara custom (pemesanan) serta tidak dapat dirakit dari komponen yang sudah ada.
F. KOMPONEN RPL Bersamaan
dengan
perkembangan
disiplin
keteknikan
diciptakan
sekumpulan
komponen perancangan standar. Komponen-komponen yang dapat digunakan lagi sudah diciptakan sehingga ahli teknik dapat benar-benar berkonsentrasi pada elemen-elemen inovatif suatu perancangan. Dalam dunia perangkat keras hal ini merupakan hal yang harus dicapai dalam skala yang luas. Reusability meruapakan suatu cirri penting dari komponen perangkat lunak kualitas tinggi. Sebuah komponen perangkat lunak harus didesain dan diimplementasi sehingga dapat dipakai lagi pada berbagai program yang berbeda. Komponen perangkat lunak dibangun dengan bahasa pemrograman yang memiliki kosakata terbatas, sebuah tata bahasa yang dibatasi secara eksplisit. Bahasa tingkat mesin merupakan perwakilan simbolik dari serangkaian instruksi CPU. Bahasa tingkat menengah memungkinkan pengembang perangkat lunak serta program tidak bergantung pada mesin.
G. APLIKASI RPL Perangkat lunak dapat diaplikasikan ke berbagai situasi dimana serangkaian procedural (seperti algoritma) telah didefinisikan (pengecualian-pengecualian yang dapat dicatatat pada aturan ini adalah sistem pakar dan jaringan syaraf tiruan dalam aplikasi kecerdasan buatan).
13
Kandundan informasi dan determinasi merupakan faktor penting dalam menentukan sifat aplikasi perangkat lunak.
EVALUASI 1)
Apakah yang dimaksud dengan perangkat lunak?
2)
Apakah rekayasa perangkat lunak itu?
3)
Apa perbedaan antara rekayasa perangkat lunak dan computer science?
4)
Apa perbedaan rekayasa perangkat lunak dan rekayasa sistem?
5)
Apakah yang dimaksud dengan proses perangkat lunak?
6)
Apakah model proses perangkat lunak itu?
14
BAB 2 MANAGING SOFTWARE PROJECTS
A. PROJECT MANAGEMENT CONCEPT Manajemen perangkat lunak yang efektif berfokus pada tiga P (people/manusia), P (Problem/masalah) dan P (Process/proses). Manajer proyek yang lupa bahwa kerja rekayasa perangkat lunak merupakan usaha manusia yang intens tidak akan pernah meraih sukses dalam manajemen proyek.
1. People Faktor
manusia sangat
penting
sehingga software engineering
institute
telah
mengembangkan sebuah model untuk mempertinggi kesiapan ornganisasi perangkat lunak untuk mengerjakan aplikasi yang semakin kompleks. Model kematangan manajemen manusia mencakup rekruitmen, seleksi, menajamen untuk kerja, pelatihan, kompensasi, perkembangan karir, desain kerja dan organisasi serta perkembangan kultur. Proses perangkat lunak diisi oleh para pemain yang dapat dikategorikan ke dalam salah satu dari lima kelompok sebagai berikut: 1) Manajer Senior, yang menentukan isu-isu bisnis yang sering memiliki pengaruh penting di dalam proyek. 2) Manajer (teknik) proyek, yang harus merencanakan, memotivasi, mengorganisir dan mengontrol sebuah produk atau aplikasi. 3) Pelaksana,
yang menyampaikan
ketrampilan
teknik
yang diperlukan untuk
merekayasa sebuah produk atau aplikasi. 4) Pelanggan, yang menentukan jenis kebutuhan bagi perangkat lunak yang akan direkayasa. 5) Pemakai akhir, yang berinteraksi dengan perangkat lunak bila perangkat lunak telah dikeluarkan untuk digunakan. Setiap proyek perangkat lunak dihuni oleh para pemain seperti yang tersebut di atas.
15
2. Problem Seorang manajer proyek perangkat lunak dihadapkan pada sebuah dilemma pada awal proyek rekayasa perangkat lunak. Analisis yang mendetail tentang kebutuhan perangkat lunak akan memberikan informasi yang memadai untuk suatu perhitungan, tetapi analis sering memerlukan waktu berminggu-minggu atau bahkan berbulan-bulan. Lebih buruk lagi, kebutuhan terkadang berubah-ubah. Aktivitas manajemen proyek perangkat lunak yang pertama adalah menentukan ruang lingkup perangkat lunak. Ruang lingkup dibatasi dengan menjawab pertanyaan berikut: Konteks. Bagaimana perangkat lunak yang akan dibangun dapat memenuhi sebuah sistem, produk, atau konteks bisnis yang lebih besar, serta batasan apa yang ditentukan sebagai hasil dari konteks tersebut. Tujuan informasi. Objek data pelanggan apa yang dihasilkan sebagai output dari perangkat lunak? Objek data apa yang diperlukan sebagai input? Fungsi dan unjuk kerja. Fungsi apa yang dilakukan oleh perangkat lunak untuk mentransformasikan input data menjadi output? Adakah ciri khusus yang akan ditekankan? Ruang lingkup proyek tidak boleh ambigu dan dapat dipahami pada tingkat teknis maupun manajemen. Selama aktivitas penentuan ruang lingkup berlangsung, tidak ada usaha untuk secara penuh melakukan dekomposisi masalah. Dekomposisi diterapkan pada dua area utama (1) fungsionalitas yang harus disampaikan dan (2) proses yang akan dipakai untuk menyampaikannya.
3. Process Perencanan proyek dimulai dengan menggabungkan masalah dan proses. Setiap fungsi yang akan direkayasa oleh tim perangkat lunak harus melampaui sejumlah aktivitas kerangka kerja yang sudah ditentukan bagi sebuah organisasi perangkat lunak. Tim perangkat lunak harus memiliki tingkat fleksibilitas yang signifikan dalam memilih paradigm rekayasa perangkat lunak yang paling baik bagi proyek dan tugas rekayasa perangkat lunak.
16
4. Project Para professional industry yang payah sering mengacu aturan 90-90 pada saat mendiskusikan proyek-proyek perangkat lunak yang sukar : 90 persen dari sistem yang pertama menyerap 90 persen dari usaha dan waktu yang diberikan. Yang 10 persen terakhir mengambil 90 persen lain dari usaha dan waktu yang diberikan. Proses manajemen proyek perangkat lunak dimulai dengan serangkaian aktivitas yang secara kolektif disebut project planning. Yang pertama dari aktivitas ini adalah estimation (perkiraan). Meskipun estimasi juga merupakan sebuah seni seperti juga pada sains, aktivitas yang penting itu tidak perlu dilakukan dengan cara serampangan. Benar-benar ada teknik yang berguna untuk mengestimasi waktu dan usaha. Karena estimasi menjadi dasar bagi semua aktivitas perencanaan proyek yang lain, dan perencanaan proyek memberikan sebuah peta jalan bagi suksesnya rekayasa perangkat lunak, maka tanpa estimasi kita tidak dapat berjalan dengan baik.
B. SOFTWARE PROJECT PLANNING 1. Observation On Estimation Estimasi sumber daya, biaya dan jadwal untuk usaha pengembangan perangkat lunak membutuhkan pengalaman, mengakses informasi historis yang baik, dan keberanian untuk melakukan pengukuran kuantitatif bila hanya data kualitatif saja yang ada. Estimasi membawa resiko yang inheren dan resiko inilah yang membawa kepada ketidak pastian. Kompleksitas proyek berpengaruh kuat terhadap ketidak pastian yang inheren dalam perencanaan. Tetapi kompleksitas merupakan pengukuran relative yang dipengaruhi oleh kebiasaan dengan usaha yang sudah dilakukan pada masa sebelumnya. Ukuran proyek merupakan factor penting lain yang dapat mempengaruhi akurasi estimasi. Bila ukuran bertambah maka ketergantungan diantara berbagai elemen perangkat lunak akan meningkat dengan cepat. Dekomposisi masalah sebagai suatu pendekatan yang sangat penting dalam proses estimasi menjadi lebih sulit lagi karena elemen-elemen yang akan didekomposisi masih sangat berat. Tingkat ketidak pastian structural juga berpengaruh dalam resiko estimasi. Resiko diukur melalui tingkat ketidakpastian pada estimasi kuantitatif yang dibuat untuk sumber daya, biaya dan jadwal. Bila ruang lingkup proyek tidak dipahami dengan baik atau syarat proyek
17
merupakan subjek terjadinya perubahan, maka resiko dan ketidakpastian menjadi sangat tinggi. Perencana perangkat lunak harus melengkapi fungsi, kinerja, dan definisi interface. Manejer proyek tidak perlu obsesif terhadap estimasi. Pendekatan-pendekatan rekayasa perangkat lunak modern memakai pandangan pengembangan yang interaktif. Pada pendekatan semacam ini dimungkinkan untuk melihat lagi estimasi dan merevisinya bila pelanggan mengubah kebutuhannya.
2. Software Scope Tujuan perencanaan proyek perangkat lunak adalah untuk menyediakan sebuah kerangka
kerja
yang
memungkinkan
manajer
membuat
estimasi
yang
dapat
dipertanggungjawabkan mengenai sumber daya, biaya dan jadwal. Estimasi dibuat dengan sebuah kerangka waktu yang terbatas pada awal sebuah proyek perangkat lunak dan seharusnya diperbaharui secara teratur selagi proyek sedang berjalan. Tujuan perencanaan dicapai melalui suatu proses penemuan informasi yang menunjuk estimasi yang dapat dipertanggungjawabkan. Aktivitas pertama dalam perencanaan proyek perangkat lunak adalah penentuan ruang lingkup perangkat lunak. Ruang lingkup perangkat lunak menggambarkan fungsi, kinerja, batasan, interface dan reliabilitas. Fungsi-fungsi yang digambarkan dalam ruang lingkup dievaluasi dan dalam banyak kasus juga disaring untuk memberikan awalan yang lebih detail pada saat estimasi dimulai. Teknik yang banyak dipakai secara umum untuk menjembatani jurang komunikasi antara pelanggan dan pengembang serta untuk memulai proses komunikasi adalah dengan melakukan pertemuan atau wawancara pendahuluan. Perangkat lunak berinteraksi dengan elemen
sistem
berbasis
computer
lainnya.
Perencana
mempertimbangkan
sifat
dan
kompleksitas masing-masing interface untuk menentukan pengaruhnya terhadap sumber daya, biaya dan jadwal pengembangan.
3. Resource Tugas selanjutnya dalam perencanaan proyek perangkat lunak adalah estimasi sumber daya yang dibutuhkan untuk menyelesaikan usaha pengembangan perangkat lunak tersebut. Gambar 2.1 memperlihatkan sumber daya pengembangan sebagai sebuah pyramid.
18
Gambar 2.1 Sumber Daya Proyek
Gambar 2.1 memperlihatkan bahwa lingkungan pengembangan perangkat keras dan perangkat lunak berada pada fondasi pyramid sumber daya dan menyediakan infrastruktur untuk mendukung usaha pengembangan.
Dalam tingkat yang lebih tinggi kita menemukan komponen perangkat lunak reuseable. Blok bangungan perangkat lunak yang dapat mengurangi biaya pengembangan secara dramatis dan mempercepat penyampaian. Di puncak piramida terdapat sumber daya utama yaitu manusia (people). Masing-masing sumber daya ditentukan dengan empat karakteristik.
Jumlah orang/manusia yang diperlukan untuk sebuah proyek perangkat lunak dapat ditentukan hanya setelah sebuah estimasi usaha pengembangan dibuat. Teknik untuk usaha estimasi didiskusikan pada bagian selanjutnya dari bab ini.
4. Software Project Estimation Pada masa awal perhitungan biaya perangkat lunak terdiri dari presentase kecil biaya sistem berbasis computer secara kesuluruhan. Urutan kesalahan besaran pada estimasi biaya perangkat lunak memiliki pengaruh yang relative kecil. Sekarang perangkat lunak menjadi elemen paling mahal di dalam sebagian besar sistem berbasis komputer.
Esimasi biaya dan usaha perangkat lunak tidak akan pernah menjadi ilmu pasti. Variable yang terlalu banyak seperti manusia, teknik, lingkungan, politik dapat mempengaruhi biaya dan usaha akhir yang diaplikasikan untuk mengembangkannya. Namun demikian estimasi proyek perangkat lunak dapat ditransformasi dari suatu seni yang misterius ke dalam langkahlangkah yang sistematis yang memberikan estimasi dengan resiko yang dapat diterima.
19
C. RISK ANALYSIS AND MANAGEMENT Setelah hasil dari feasibility plan dipresentasikan, proyek dapat dilanjutkan sampai dengan tahap penyelesaiannya. Yang dibutuhkan setelah presentasi feasibility plan adalah menambah input (masukan) terhadap proyek. Hasil dari riset yang telah dilakukan mungkin saja harus ditambahkan dengan masukan-masukan baru, sehingga hasil akhir yang diharapkan dapat dicapai. Tambahan masukan untuk proyek ini dapat dilakukan antara lain dengan cara: 1) Dari hasil presentasi dengan tim manajemen (feed-back input); 2) Lewat informasi proyek-proyek sejenis sebelumnya, melalui perpustakaan, Internet, database IT vendors, laporan ilmiah, jurnal ilmiah, dsb; 3) Lewat wawancara dengan pemakai akhir dan/atau personal yang pernah menggunakan produk sejenis, sponsor, dsb. Contoh penambahan informasi untuk kelangsungan proyek ini dapat berupa antara lain: 1) Pertanyaan dari pihak management mengapa tidak menggunakan teknologi lain yang lebih murah; 2) Harapan dari pihak pengguna bahwa program software yang akan dibuat mudah untuk dimengerti juga oleh mereka yang tidak memiliki basis IT yang kuat; 3) Adanya data dari database perusahaan bahwa di proyek sebelumnya teknologi terpilih ternyata memiliki kelemahan mendasar, seperti ketidakstabilan suatu program yang ditulis dalam Java di dalam lingkungan windows. Perlu diingat informasi tambahan ini hanya sebagai masukan dan harus dicari solusi pemecahan bila memang menghambat jalannya proyek. Tidak diharapkan bahwa informasi tambahan justru akan membuat proyek menjadi tersendat. Yang tetap menjadi acuan harus tetap feasibility plan yang semula. Karena dari feasibility plan, diharapkan: 1) Memenuhi keinginan pemberi order; 2) Dapat menggunakan teknologi yang sepadan dengan kriteria; 3) Dapat menyusun biaya dan rencana kerja lebih detail (dan mungkin lebih rendah dari perkiraan semula); Sebagai bahan untuk presentasi pada pihak manajemen dan pengguna (report dan
speech work) serta dapat dijadikan suatu kekuatan untuk negotiating position.
20
Adapun dalam manajemen risiko tujuan yang hendak dicapai adalah: 1)
Identifikasi terhadap risiko;
2)
Evaluasi (analisa) risiko dan (estimasi) pengaruhnya terhadap proyek;
3)
Mengembangkan responsi terhadap risiko;
4)
Mengontrol responsi risiko.
Identifikasi Proyek Input: Deskripsi produk
Rencana proyek (WBS, biaya, staff, perekrutan) Informasi histori
Output: Sumbersumber risiko
Teknik: Checklist
Flowchart
Wawancara
Potensi risiko
Tanda-tanda risiko (trigger)
Input ke proses lainnya
Identifikasi risiko terdiri atas pengawasan dan penentuan risiko apa saja yang dapat mempengaruhi proyek serta mendokumentasikan setiap dari risiko tersebut. Identifikasi tidak hanya dilakukan sekali, namun harus dilakukan sepanjang perjalanan proyek dari awal sampai akhir.
Faktor internal di dalam serta eksternal di luar proyek harus diidentifikasi. Faktor internal antara lain penugasan anggota tim kerja, perhitungan biaya dan waktu, serta support dan pengaruh dari tim manajemen. Faktor eksternal antara lain melibatkan kebijaksanaan pemerintah, bencana alam, dan hal-hal lain di luar kontrol atau pengaruh tim proyek. Identifikasi terhadap risiko harus melibatkan pengaruh baik maupun pengaruh buruk dari pengaruh faktor-faktor penentu risiko.
Dari gambar di atas dapat dilihat input bagi identifikasi risiko adalah: 1)
Diskripsi produk Produk yang berbasis pada teknologi yang telah dibuktikan kebenarannya memiliki risiko yang lebih kecil dibandingkan dengan produk yang menuntut inovasi dan penemuan.
21
2)
Rencana proyek a. Work breakdown structure: pendekatan pada deliverables setiap unit kerja secara detail. Dengan cara ini identifikasi terhadap risiko bisa sampai ke level yang sangat detail; b. Estimasi biaya dan waktu: estimasi yang terlalu kasar dan terburu-buru dapat meningkatkan risiko proyek. c. Penempatan SDM: setiap pekerjaan yang spesifik dan hanya dapat dilakukan oleh orang tertentu meningkatkan risiko proyek, apabila orang tersebut berhalangan untuk hadir; d. Perekrutan dan sub-kontraktor: pengaruh ekonomi dan kebijakan politik di sekitar proyek dapat menyebabkan fluktuasi nilai kontrak proyek.
3)
Informasi historis. hal-hal yang pernah terjadi di masa lalu, dan berkaitan dengan proyek dapat dilihat dari: a. File-file proyek sejenis dari perusahaan; b. Database komersial, contohnya: Internet knowledge-bases; c. Ilmu dan pengalaman dari tim kerja, dikenal juga dengan sebutan: tacit knowledge.
Untuk teknik yang digunakan dalam proses identifikasi risiko adalah: 1)
Checklist: dari informasi (riset, dll) yang diperoleh dapat dibuat checklist yang mendata sumber-sumber risiko;
2)
Flowcharting: dapat digunakan untuk menggambarkan penyebab dan efek dari risiko yang ada;
3)
Wawancara: data-data yang tersimpan dari hasil wawancara proyek-proyek terdahulu dapat digunakan sebagai referensi, dan juga masukan dari stakeholders merupakan sumber informasi yang berpengaruh untuk mengidentifikasi risiko.
Adapun hasil output dari pengidentifikasian risiko adalah:
1)
Daftar sumber-sumber risiko a. Yang seringkali menjadi sumber risiko proyek antara lain: perubahan requirements, kesalahan design, pendefinisian peran kerja yang lemah, kesalahan estimasi, dan tim kerja yang kurang mapan. b. Pada umumnya penjelasan mengenai sumber-sumber risiko ini disertai pula dengan: perhitungan kemungkinan terjadinya risiko tersebut, kemungkinan akibat dari risiko tersebut, kemungkinan kapan terjadinya, pengantisipasian tindakan terhadap risiko tersebut.
22
2)
Kejadian yang berpotensi menjadi risiko: biasanya merupakan kejadian-kejadian luar biasa yang jarang terjadi. a. Contohnya bencana alam, perkembangan teknologi baru yang tiba-tiba. b. Tanda-tanda datangnya risiko (risk symptoms), sering juga disebut triggers, sebabsebab yang mengakibatkan munculnya bencana pada saat ini. c. Contohnya biaya yang mengembang pada awal proyek disebabkan oleh estimasi yang terburu-buru dan tidak akurat.
Input pada proses-proses lainnya: identifikasi risiko mungkin saja menyebabkan diperlukannya pelaksanaan suatu aktivitas di area lain. Contohnya: bila identifikasi risiko memperkirakan bahwa harga barang kebutuhan utama proyek akan naik, maka ada baiknya pada penjadwalan, pembelian barang utama tersebut dilakukan di awal proyek.
Kuantifikasi risiko meliputi pengevaluasian serta interaksi antara risiko dan akibatnya. Input: 1)
Toleransi dari stakeholders dan sponsor: setiap organisasi memiliki toleransi yang berbeda-beda terhadap risiko. Ada yang hanya 10% dari modal, tapi ada juga yang berani hingga 40% dari modal proyek, asalkan proyek selesai tepat waktu.
2)
Sumber risiko (dibahas di atas);
3)
Kejadian yang berpotensi menjadi risiko(dibahas di atas);
4)
Estimasi waktu dan biaya (akan dibahas pada Manajemen waktu dan biaya);
Teknik: 1)
Perkiraan nilai moneter: bagaimana efek sebuah risiko yang telah dievaluasi nilainya? Mungkin ada yang risiko yang kemungkinannya kecil, tapi nilai risikonya dapat membuat proyek berhenti. Ada pula risiko yang kemungkinannya besar, tetapi efeknya kecil terhadap jalannya proyek.
2)
Perhitungan statistik: menghitung jangkauan (range) perhitungan minimum dan maksimum untuk biaya dan penjadwalan kerja proyek.
3)
Simulasi model: dengan bantuan model yang disimulasikan dapat diketahui estimasi yang lebih tepat, contoh: penggunaan model statistik Monte Carlo untuk menghitung estimasi durasi proyek.
4)
Decision trees: diagram yang memberikan alur kemungkinan dan interaksi antara keputusan serta akibatnya.
5)
Penilaian ahli: penilaian ahli dapat digunakan sebagai masukan tambahan setelah penggunaan teknik-teknik di atas.
23
Output: Setelah dianalisis, manajer proyek harus mampu memutuskan berbuat apa terhadap risiko yang mungkin ada. Menerimanya, membuat rencana lanjutan atau mencari alternatif lain yang tidak terpengaruh risiko.
D. SQA Banyak pengembang perangkat lunak terus percaya bahwa kualitas perangkat lunak merupakan sesuatu yang mulai dikhawatirkan setelah kode-kode dihasilkan.
1. Quality American Heritage Dictionary mendefinisikan kata kualitas sebagai sebuah karakteristik atau atribut dari sesuatu. Sebagai atribut dari sesuatu, kualitas mengacu pada karakteristik yang dapat diukur, sesuatu yang dapat kita bandingkan dengan standar yang sudah diketahui, seperti panjang, warna, sifat kelistrikan, kelunakannya dan sebagainya. Tetapi perangkat lunak, yang sebagaian besar merupakan entitas intelektual lebih menantang untuk dikarakterisasi daripada objek fisik.
Ada dua jenis kualitas yaitu kualitas desain dan kualitas konformasi. Kualitas desain mengacu pada karakteristik yang ditentukan oleh desainer terhadap suatu item tertentu. Kualitas konformansi adalah tingkat dimana spesifikasi desain terus diikuti selama pembuatan. Dalam pengembangan perangkat lunak kualitas desain mencakup syarat, spesifikasi, dan desain sistem. Kualitas konformansi adalah suatu masalah yang difokuskan pada implementasi. Bila implementasi mengikuti desain dan sistem yang dihasilkan memenuhi persyaratan serta tujuan kinerja, maka kualitas konformansi menjadi tinggi.
2. Quality Control Kontrol kualitas merupakan serangkaian pemeriksaan, kajian dan pengujian yang digunakan pada keseluruhan siklus pengembangan untuk memastikan bahwa setiap produk memenuhi persyaratan yang ditetapkan. Kontrol kualitas mencakup perulangan (loop) umpan balik pada proses yang menciptakan produk kerja. Aktivitas kualitas kontrol dapat menjadi otomatis sepenuhnya, manual secara kesuluruhan, atau kombinasi antara piranti otomatis dan interaksi manusia. Konsep kunci kualitas kontrol adalah bahwa semua produk kerja memiliki spesifikasi yang telah ditentukan dan dapat diukur di mana kita dapat membandingkan output dari setiap proses.
24
3. Quality Assurance Jaminan kualitas terdiri atas fungsi auditing dan pelaporan manajemen. Tujuan jaminan kualitas
adalah
untuk
memberikan
data
yang
diperlukan
oleh
manajemen
untuk
menginformasikan masalah kualitas produk, sehingga dapat memberikan kepastian dan kepercayaan bahwa kualitas produk dapat memenuhi sasaran. Jika data yang diberikan melalui jaminan kualitas mengidentifikasikan adanya masalah, maka adalah tanggung jawab manajemen untuk menetapkan masalahnya dan mengaplikasikan sumber-sumber daya yang dibutuhkan untuk memecahkan masalah kualitas tersebut.
4. Cost Of Quality Biaya kualitas menyangkut semua biaya yang diadakan untuk mengejar kualitas atau untuk menampilkan kualitas yang berhubungan dengan aktivitas. Studi tentang biaya kualitas dilakukan untuk memberikan garis besar bagi biaya kualitas yang sedang digunakan untuk mengidentifikasi
kemungkinan
pengurangan
biaya
kualitas
serta
memberikan
basis
perbandingan yang ternormalisasi. Biaya kegagalan adalah biaya yang akan hilang bila tidak ada cacat yang muncul sebelum produk disampaikan kepada pelanggan. Biaya kegagalan dapat dibagi lagi ke dalam biaya kegagalan internal dan eksternal. Biaya kegagalan internal adalah biaya yang diadakan bila kita mendeteksi suatu kesalahan dalam produk sebelum produk dipasarkan.
EVALUASI 1)
Sebutkan 5 kelompok manusia yang terlibat dalam proses pengembangan perangkat lunak?
2)
Bagaimanakah cara membatasi ruang lingkup proyek?
3)
Apakah tujuan dari perencanaan proyek perangkat lunak?
4) Sebutkan dan jelaskan jenis kualitas yang melekat pada perangkat lunak?
25
BAB 3 METODE KONVENSIONAL UNTUK SOFTWARE ENGINEERING
A. SYSTEM ENGINEERING Empat ratus dan lima ratus tahun yang lalu, Machiavelli pernah berkata, “Tidak ada yang lebih sukar untuk dilakukan, lebih membahayakan untuk dilakukan atau lebih tidak pasti dalam keberhasilannya, daripada memimpin di dalam pembukaan orde yang baru.” Selama kuartal terakhir abad ke-20, sistem berbasis komputer telah memperkenalkan tatanan baru. Meskipun teknologi telah membuat langkah benar sejak pernyataan Machiavelli, ungkapan yang dikatakannya itu masih tetap bergema sampai sekarang. Rekayasa perangkat lunak terjadi sebagai konsekuensi dari suatu proses yang disebut rekayasa sistem. Daripada berkonsentrasi semata-mata pada perangkat lunak, rekayasa sistem memfokuskan diri pada berbagai elemen, analisis, perancangan, dan pengorganisasian elemen-elemen tersebut ke dalam suatu sistem yang dapat menjadi sebuah produk , jasa, atau teknologi untuk mentransformasi informasi atau kontrol. Proses rekayasa sistem disebut rekayasa informasi bila konteks kerja rekayasa berfokus pada perusahaan bisnis. Pada saat produk akan dibuat, prose situ disebut rekayasa produk. Baik rekayasa informasi maupun rekayasa produk cenderung untuk membawa orde kepada pengembangan sistem berbasis komputer. Meskipun masing-masing diterapkan di dalam domain aplikasi yang berbeda, keduanya berusaha untuk meletakkan perangkat lunak ke dalam konteks. Baik rekayasa informasi maupun rekayasa produk kerja untuk mengalokasikan suatu peran bagi perangkat lunak ke elemen sistem berbasis komputer lainnya.
1. Computer Based System Tujuannya mungkin adalah untuk mendukung berbagai fungsi bisnis atau untuk mengembangkan suatu produk yang dapat dijual untuk menghasilkan keuntungan bisnis. Untuk mencapai tujuan tersebut, sistem berbasis komputer menggunakan berbagai elemen sistem: 1)
Perangkat lunak.
26
Program computer, struktur data, dan dokumen yang berhubungan yang berfungsi untuk mempengaruhi metode logis, prosedur, dan kontrol yang dibutuhkan. 2)
Perangkat keras Perangkat elektronik yang memberikan kemampuan penghitungan, dan perangkat elektromekanik (misalnya, sensor, rotor, pompa) yang memberikan fungsi dunia eksternal.
3)
Manusia Pemakai dan operator perangkat keras dan perangkat lunak.
4)
Database Kumpulan informasi yang besar dan terorganisasi yang diakses melalui perangkat lunak.
5)
Dokumentasi Manual,
formulir,
dan
informasi
deskriptif
lainnya
yang
menggambarkan
penggunaan dan atau pengoperasian sistem. 6)
Prosedur Langkah-langkah yang menentukan penggunaan khusus dari masing-masing elemen sistem atau konteks prosedural di mana sistem berada.
Satu karakteristik sistem berbasis komputer yang rumit adalah bahwa elemen yang berisi satu sistem juga dapat mewakili satu elemen makro dari suatu sistem yang sangat besar.
Elemen makro adalah suatu sistem berbasis komputer yang merupakan bagian dari sistem berbasis komputer yang lebih besar lagi. Sebagai contoh, perhatikan”sistem otomasisasi pabrik” yang pada dasarnya merupakan hirarki sistem yang diperlihatkan pada gambar 3.1.
Pada
tingkat yang paling rendah dari hirarki tersebut, kita memiliki mesin kontrol numerik, robot, dan perangkat pemasukan data. Masing-masing merupakan sistem berbasis komputer. Elemenelemen dari mesin kontrol numerik tersebut adalah perangkat keras elektronik dan elektromekanik (misalnya, prosesor dan memori, motor, sensor); perangkat lunak (untuk komunikasi, kontrol mesin, dan intrpolasi); manusia (operator mesin); database (program NC yang disimpan); dan dokumentasi serta prosedur. Dekomposisi yang sama dapat juga diterapkan untuk robot dan perangkat pemasukan data. Masing-masing merupakan sistem berbasis komputer.
27
Gam mbar 3.1 Siste em Dari Banya ak Sistem Tingkat selanjutnya pa ada hirarki, (Gambar 3.1 1) adalah se sel pemanukf kfaturan. Sel peman nukfaturan merupakan m s siste berbasiss komputer yang mem miliki elemenn nya sendiri (misaln nya, kompute er, perlengkapan mekaniss) dan juga mengintegras m si elemen-ele emen makro yang kita k sebut messin kontrol nu umerik, robot dan perangka at pemasukan n data. Singkatnya,, sel pemanu ukfaturan dan n elemen ma akro masing--masing terdiri dari dari elemen n-elemen sisttem dengan label generik: perangkat lunak, perrangkat kerass, manusia, databa ase,
prosedu ur,
dan
dokumentasi.
Dalam
banyyak
kasus,
elemen
ma akro
dapat
mengg gunakan elem men generik secara bersam ma-sama. Misalnya, robot dan mesin NC keduanya dapat diatur oleh seorang ope erator tungga al (elemen manusia). m Dalam kasus la ain, elemen generik k eksklusif be ersifat untuk satu s sistem sa aja. Peran reka ayasa sistem adalah me embatasi elemen-elemen tersebut un ntuk sistem berbassis computer tertentu dala am konteks kkeseluruhan hirarki sistem m (elemen makro). Pada subbab b berikut kita akan mengam mati tugas-tugas yang merupakan rekayasa sistem komputer. k
2. Sy ystem Eng gineering g Hierarch hy Tanpa melih hat domain fo okusnya, reka ayasa melingkkupi sekumpu ulan metode dari atas ke bawah (top-down) dan dari ba awah ke atass (bottom-up p) untuk men ngendalikan hirarki h yang diilustrasikan pada gambar g 3.2. Proses rekayasa sistem biiasanya dimulai dengan se ebuah world
view (WV), ( yaitu di mana ke eseluruhan domain d bisniss atau domain produk diuji untuk
28
memastikan bahwa bisnis atau konteks teknologi yang tepat dapat dibangun. WV diperhalus untuk lebih berfokus pada domain interes tertentu. Pada suatu domain tertentu, kebutuhan untuk sistem yang ditargetkan (misalnya data, perangkat lunak, perangkat keras, manusia) dianalisis. Akhirnya, analisis, desain, dan konstruksi dari elemen yang ditargetkan diinisiasi. Pada puncak hirarki, suatu konteks yang luas dibangun, dan di bagian dasarnya aktivitas teknik lengkap yang dilakukan oleh disiplin rekayasa yang relevan (misalnya, rekayasa perangkat keras atau perangkat lunak) dilakukan.
Gambar 3.2 Hirarki Rekayasa Perangkat Lunak Secara lebih resmi dapat dikatakan bahwa WV terdiri dari sejumlah domain (Di) yang masing-masing dapat berupa sebuah system atau system dari system yang lebih besar. WV = {D1 D2 D3 … Dn} Masing-masing domain terdiri elemen-elemen tertentu (Ej) dimana masing-masing berperan dalam mencapai sasaran dan tujuan dari domain:
Di = {E1,E2,E3, …., Em}
29
Akhirnya, masing-masing elemen diimplementasikan dengan mengkhususkan pada komponen-komponen teknis (Ck) yang mencapai fungsi yang diperlukan untuk suatu elemen.
Ej = {C1, C2, C3, … Ck} Dalam konteks perangkat lunak, komponen dapat berupa program computer, komponen program reusable, modul, kelas atau objek, atau bahkan dapat berupa satu pernyataan bahasa pemrograman. Penting untuk dicatat bahwa perekayasa system mempersempit focus kerja ketika ia bergerak ke bawah dalam hirarki tersebut. Tetapi WV menggambarkan definisi yang jelas terhadap keseluruhan fungsionalitas yang memungkinkan perekayasa memahami domain, dan akhirnya system atau produk, dalam konteks yang tepat.
B. REQUIREMENT ENGINEERING Ketika otomasi bisnis diperkenalkan pertama kali pada awal tahun 1960-an, banyak perusahaan yang kemudian mencari berbagai peluang dan mengotomasisasi fungsi-fungsi bisnis yang sebelumnya dijalankan dengan cara manual. Seiring berjalannya waktu, program komputer individu kemudian dikombinasikan untuk menangani banyak aplikasi bisnis. Aplikasi tersebut dikelompokkan ke dalam sistem informasi mayor yang melayani area bisnis yang spesifik. Aplikasi tersebut dapat berjalan, tetapi tetap menimbulkan masalah. Banyak sistem sulit dihubungkan satu dengan lainnya; data redundan ada di mana-mana; pengaruh peubahan terhadap aplikasi yang melayani satu daerah bisnis sulit diproyeksikan dan bahkan lebih sulit untuk diimplementasikan; dan program-program lama menjadi tidak dapat dipakai lagi.tetapi kurangnya sumber daya menyebabkan sistem digunakan dalam waktu yang sangat lama. Tujuan global rekayasa informasi adalah untuk mengaplikasikan”teknologi informasi” dengan cara tertentu yang melayani dengan paling baik kebutuhan bisnis secara keseluruhan. Untuk melakukan hal tersebut, IE harus memulainya dengan menganaisis sasaran dan tujuan bisnis, memahami area-area bisnis yang harus bekerja bersama-sama untuk mencapai sasaran dan tujuan tersebut, dan kemudian harus menentukan kebutuhan informasi bagi masingmasing area bisnis dan bisnis secara keseluruhan. Hanya setelah hal itu dilakukan, IE membuat transisi ke dalam domain rekayasa perangkat lunak yang lebih teknis – proses di mana sistem informasi, aplikasi, dan program dianalisis, didesain, dan dibangun.
30
1. Requirement Elicitation Semua proyek dapat dikerjakan dengan mudah – dengan sumber daya dan waktu yang tidak terbatas! Sayangnya, pengembangan sistem atau produk berbasis komputer lebih banyak terganggu oleh kurangnya sumber daya dan tanggal penyampaian yang sulit (bila tidak benarbenar tidak realistis). Memang perlu dan bijaksana untuk melakukan evaluasi terhadap feasibilitas sebuah proyek pada saat paling awal yang mungkin. Bulan atau tahun kerja, ribuan atau jutaan dolar, dan keadaan melakukan tidak terkatakan dapat terhindar bila sebuah sistem yang sakit dikenali sejak awal, ketika masih dalam fase definisi. 1)
Feasibilitas ekonomis. Evaluasi biaya pengembangan dibobot dengan pemasukan utama atau keuntungan yang didapat dari sistem atau produk yang dikembangkan.
2)
Feasibilitas teknis. Studi mengenai fungsi, kinerja, dan batasan yang dapat mempengaruhi kemampuan untuk mencapai sebuah sistem yang dapat diterima.
3)
Feasibilitas legal. Pertimbangan mengenai pelanggaran, kekasaran,atau liabilitas yang dihasilkan dari pengembangan sistem.
4)
Alterntif. Evaluasi mengenai pendekatan alternatif pada pengembangan sistem atau produk.
5)
Studi feasibilita Tidak dijamin untuk sistem di mana pembenaran ekonomisnya jelas, risiko teknisnya rendah, hanya memiliki sedikit masalah legal, dan tidak ada alternatif yang tidak dipertanggungjawabkan. Tetapi, bila beberapa dari kondisi itu gagal, maka studi mengenai area tersebut dapat dilakukan.
Justifikasi ekonomi biasanya merupakan pertimbangan bottom-line untuk sebagian besar sistem (kecuali kadang-kadang mencakup sistem pertahanan seperti program ruang angkasa). Pembenaran ekonomis menyangkut rentang yang luas dari pertimbangan yang meliputi analisis biaya-keuntungan, stratgi pemasukan yang berhubungan dengan hokum dalam jangka panjang, pengaruhnya pada pusat keuntungan atau produk yang lain, iaya sumber daya yang dibutuhkan untuk pengembangan, dan pertumbuhan pasar potensial. Feasibilitas teknis sering menjadi area yang paling sulit untuk ditaksir pada tingkat proses rekayasa produk. Karena sasaran, fungsi, dan kinerja agak tidak penting bahwa proses analisis dan definisi dilakukan secara paralel dengan sebuah penilaian feasibilitas teknis. Dengan cara inilah spesifikasi yang konkrit dapat diputuskan pada saat ditentukan.
31
2. Analisis Area Bisnis Analisis Area Bisnis membentuk suatu kerangka kerja lengkap untuk membangun perusahaan yang berbasis informasi. Analisis area bisnis menggunakan suatu area bisnis pada suatu waktu dan menganalisisnya secara detail. Analisis area bisnis menggunakan diagram dan matriks untuk memodelkan dan merekam data dan aktivitas pada perusahaan dan memberikan pemahaman yang jelas terhadap cara yang teliti dan cerdik di masa aspek informasi dari perusahaan saling berhubungan.
3. Requirement Spesification Spesifikasi Sistem adalah dokumen yang berfungsi sebagai dasar bagi rekayasa perangkat keras, rekayasa perangkat lunak, rekayasa database, dan rekayasa manusia. Spesifikasi sistem menggambarkan fungsi dan kinerja dari sebuah sistem berbasis computer serta batasan yang mengatur pengembangannya. Spesifikasi tersebut membatasi masingmasing elemen sistem yang teralokasi.
4. System Modelling Sebagai bagian dari persyaratan sistem dan kegiatan perancangan, sistem harus dimodelkan sebagai suatu kumpulan komponen dan hubungan antara komponen-komponen ini. Ini biasanya diilustrasikan secara grafis pada model arsitektur sistem yang memberikan pandangan kepada pembaca mengenai organisasi sistem. Arsitektur sistem biasanya digambarkan sebagai diagram blok yang menunjukkan subsistem direpresentasikan sebagai persegi empat pada diagram blok dan adanya hubungan antara mereka ditunjukkan dengan tanda panah yang menghubungkan persegi empat ini. Hubungan yang digambarkan bisa mencakup aliran data, hubungan menggunakan/digunakan atau jenis hubungan ketergantungan lain. Arsitektur
sistem harus dirancang dalam
bentuk subsistem
fungsional
tanpa
mempedulikan apakah sub sistem tersebut merupakan perangkat keras atau perangkat lunak. Komponen fungsional pada sistem dapat diklasifikasikan dengan berbagai nama: 1)
Komponen sensor
2)
Komponen actuator
3)
Komponen komputasi
4)
Komponen komunikasi
5)
Komponen koordinasi
6) Komponen iterface
32
5. Requirement Validation Validasi perysaratan berkenaan dengan pengidentifikasian bahwa persyaratan benarbenar mendefinisikan sistem yang diinginkan pelanggan. Kegiatan ini memiliki banyak kesamaan dengan analisis karena hubungan dengan penemuan masalah dengan persyaratan. Namun demikian, keduanya merupakan proses yang berbeda karena validasi harus berhubungan dengan naskah dokumen persyaratan yang lengkap, sementara analisis melibatkan pekerjaan dengan persyaratan yang tidak lengkap. Validasi
persyaratan
penting karena error
pada dokumen
persyaratan
dapat
menimbulkan biaya pengerjaan ulang jika ditemukan pada saat pengembangan atau setelah sistem dipakai. Biaya melakukan perubahan sistem yang merupakan akibat dari masalah persyaratan lebih besar dari perbaikan desasin atau kesalahan pengkodean. Alasan untuk hal ini adalah karena perubahan persyaratan biasanya mengharuskan perubahan desain sistem dan implementasinya, beserta pengujian ulang sistem. Pada saat proses validasi persyaratan tipe pemeriksaan yang berbeda harus diterapkan pada persyaratan-persyaratan di dokumen persyaratan. Pemeriksaan ini meliputi: 1)
Pemeriksaan validitas. Seorang user mungkin berpikir bahwa sistem diperlukan untuk melakukan fungsifungsi tertentu. Namun demikian pemikiran dan analisis lebih lanjut dapat mengidentifikasi fungsi tambahan atau fungsi berbeda yang diinginkan. Sistem yang memiliki berbagai user dengan kebutuhan yang berbeda dengan persyaratan apapun pada akhirnya akan merupakan suatu kompromi dari komunitas user.
2)
Pemeriksaan Konsistensi Persyaratan pada dokumen seharusnya tidak bertentangan. Artinya seharusnya ada batasan-batasan yang saling bertentangan atau deskripsi yang berbeda dari fungsi sistem yang sama.
3)
Pemeriksaan Kelengkapan Dokumen persyaratan harus mencakup persyaratan yang mendefinisikan semua fungsi dan batasan yang dimaksud oleh user sistem.
4)
Pemeriksaan realisme Dengan menggunakan pengetahuan mengenai teknologi yang ada, persyaratan harus diperiksa untuk menjamin persyaratan dapat diimplementasi. Pemeriksaan ini harus memperhitungkan anggaran dan jadwal pengembangan sistem.
33
5)
Kemampuan dapat diverifikasi Untuk mengurangi potensi pertentangan antara pelanggan dan kontraktor, persyaratan sistem harus selalu dituliskan sedemikian rupa sehingga dapat diverifikasi. Ini berarti bahwa serangkaian pemeriksaan dapat dirancang untuk mendemonstrasikan bahwa sistem yang diserahkan memenuhi persyaratan tersebut.
6. Requirement Management Persyaratan untuk sistem perangkat lunak besar selalu berubah. Satu alasan untuk hal ini adalah karena sistem-sistem ini biasanya dikembangkan untuk mengatasi masalah. Karena masalah tidak dapat didefinisikan sepenuhnya, persyaratan perangkat lunak cenderung tidak lengkap. Pada saat proses perangkat lunak, pemahaman pengembang akan masalah berubahubah dan perubahan ini diumpan balikkan pada persyaratan. Sistem besar biasanya memiliki komunitas user yang beragam. User yang berbedabeda mempunyai persyaratan dan prioritas yang berbeda pula. Hal-hal ini bias menimbulkan konflik atau kontradiksi. Manajemen persyaratan adalah proses pemahaman dan pengendalian perubahan pada persyaratan sistem. Proses manajemen persyaratan dilakukan bersama dengan proses rekayasa persyaratan yang lainnya. Perencanaan dimulai pada saat yang sama dengan elisitasi persyaratan awal dan manajemen persyaratan aktif harus dimulai segera setelah versi naskah dokumen persyaratan tersedia. Dari sudut pandang evolusi persyaratan terbagi menjadi dua kelas: 1)
Persyaratan yang bertahan. Ini merupakan persyaratan yang relative stabil, yang berasal dari kegiatan inti organisasi dan berhubungan langsung dengan domain sistem.
2)
Persyaratan yang berubah-ubah. Ini merupakan persyaratan yang mungkin berubah pada saat pengembangan sistem, atau setelah sistem dipakai.
EVALUASI 1)
Sebutkan dan jelaskan elemen sistem berbasis komputer!
2)
Apakah fungsi dari studi kelayakan!
3) Apakah yang dimaksud dengan manajemen persyaratan?
34
BAB 4 ANALISIS
A. KONSEP DAN PRINSIP ANALISIS Pemahaman lengkap mengenai persyaratan perangkat lunak sangat penting bagi keberhasilan usaha pengembangan perangkat lunak. Tidak peduli bagaimana perangkat lunak dirancang atau dikodekan, program yang dianalisis dan ditentukan secara tidak baik akan mengecewakan pemakaiannya dan akan membawa kegagalan bagi pengembangnya. Tugas pemodelan
analisis
dan
persyaratan
spesifikasi.
Ruang
merupakan lingkup
sebuah
perangkat
proses lunak
penemuan, yang
perbaikan,
secara
mendasar
dikembangkan oleh perekayasa system dan diperbaiki selama perencanaan proyek perangkat lunak diperbaiki secara detail. Model-model data yang dibutuhkan, aliran kontrol dan informasi, dan tingkah laku operasional diciptakan. Kebutuhan perangkat lunak adalah kondisi, kriteria, syarat atau kemampuan yang harus dimiliki oleh perangkat lunak untuk memenuhi apa yang disyaratkan atau diinginkan pemakai. Bab ini berisi mengenai segala sesuatu yang dibutuhkkan untuk dapat melakukan analisa kebutuhan perangkat lunak. Menurut Kamus Webster seperti dikutip oleh Davis [DAV93], kebutuhan adalah sesuatu yang disyaratkan; sesuatu yang diinginkan atau diperlukan. Sedangkan menurut IEEE [IEE93] kebutuhan adalah: 1)
Kondisi atau kemampuan yang diperlukan pemakai untuk menyelesaikan suatu persoalan, atau untuk mencapai tujuan.
2)
Kondisi atau kemampuan yang harus dimiliki atau dipunyai oleh sistem atau komponen sistem untuk memenuhi kontrak, standar, spesifikasi, atau dokumen formal lainnya.
Dengan mengadopsi pengertian-pengertian di atas, dapat disimpulkan bahwa kebutuhan perangkat lunak adalah kondisi, kriteria, syarat atau kemampuan yang harus dimiliki oleh perangkat lunak untuk memenuhi apa yang disyaratkan atau diinginkan pemakai.
35
Secara kategoris, ada tiga buah jenis kebutuhan perangkat lunak [IEE93] : 1)
Kebutuhan fungsional (functional requirement) Disebut juga kebutuhan operasional, yaitu kebutuhan yang berkaitan dengan fungsi atau proses transformasi yang harus mampu dikerjakan oleh perangkat lunak. Sebagai contoh: a. Perangkat lunak harus dapat menyimpan semua rincian data pesanan pelanggan. b. Perangkat lunak harus dapat membuat laporan penjualan sesuai dengan periode waktu tertentu. c. Perangkat lunak harus mampu menyajikan informasi jalur pengiriman barang terpendek.
2)
Kebutuhan antarmuka (interface requirement) Kebutuhan antarmuka yang menghubungkan perangkat lunak dengan elemen perangkat keras, perangkat lunak, atau basis data. Sebagai contoh: a. Perangkat untuk memasukkan data dapat berupa keyboard, mouse atau scanner. b. Akses ke basisdata menggunakan ODBC (Open Database Connectivity).
3)
Kebutuhan unjuk kerja (performance requirement) Kebutuhan yang menetapkan karakteristik unjuk kerja yang harus dimiliki oleh perangkat lunak, misalnya: kecepatan, ketepatan, frekuensi. Sebagai contoh: a. Perangkat lunak harus bisa mengolah data sampai 1 juta record untuk tiap transaksi. b. Perangkat lunak harus dapat digunakan otoritas yang diberikan pada user. c. Waktu tanggap penyajian informasi maksimal selama satu menit.
1. Analisis Kebutuhan Analisis kebutuhan perangkat lunak (software requirements analysis) merupakan aktivitas awal dari siklus hidup pengembangan perangkat lunak. Untuk proyek-proyek perangkat lunak yang besar, analisis kebutuhan dilaksanakan setelah tahap rekayasa sistem/informasi dan software project planning. Analisis persyaratan adalah sebuah tugas rekayasa perangkat lunak yang menjembatani jurang antara alokasi perangkat lunak tingkat sistem dan perancangan perangkat lunak seperti dilihat pada gambar 6.1.
36
Gambar 4.1 Analisis dan Kesenjangan antara rekayasa sistem dan desain perangkat lunak Analisis persyaratan memungkinkan perekayasa sistem menentukan fungsi dan kinerja perangkat lunak, menunjukkan interface perangkat lunak dengan elemen-elemen sistem. Pendefinisian kebutuhan merupakan aktivitas yang sangat penting, karena sangat mempengaruhi sukses atau gagalnya pelaksanaan pengembangan perangkat lunak. Menurut hasil survey DeMarco, 56% kegagalan proyek pengembangan perangkat lunak dikarenakan ketidaklengkapan pendefinisian kebutuhan dari perangkat lunak tersebut. Perhatikan gambar dampak kesalahan kumulatif akibat kesalahan dalam pendefinisian kebutuhan pada Gambar 4.2.
37
Gambar 4.2 Dampak Kesalahan Kumulatif Dari gambar terlihat bahwa produk perangkat lunak yang tidak sempurna akan dihasilkan karena kesalahan pada saat menentukan spesifikasi kebutuhan. Jika kesalahan tersebut diketahui di akhir siklus hidup pengembangan, usaha untuk memperbaikinya akan sangat mahal. Selain itu, kesalahan penentuan kebutuhan akan memberikan dampak [DAV93]: a. Perangkat lunak yang dihasilkan tidak akan memenuhi kebutuhan pemakai yang sebenarnya. b. Interpretasi
kebutuhan
yang
berbeda-beda
sehingga
dapat
menyebabkan
ketidaksepakatan antara pelanggan dan pengembang, menyia-nyiakan waktu dan biaya, dan mungkin akan menghasilkan perkara hukum.
38
c. Pengujian kesesuaian perangkat lunak dengan kebutuhan yang dimaksud tidak akan mungkin dilaksanakan dengan sesungguhnya.
d. Waktu dan biaya akan terbuang percuma untuk membangun sistem yang salah.
2. Prinsip-Prinsip Analisis Setiap metode analisis memiliki titik pandang yang unik. Tetapi semua metode analisis dihubungkan oleh serangkaian prinsip operasional yang dapat dijabarkan sebagai berikut: 1)
Dominan informasi dari suatu masalah harus direpresentasikan dan dipahami.
2)
Fungsi-fungsi yang akan dilakukan oleh perangkat lunak harus didefinisikan.
3)
Tingkah laku perangkat lunak harus diwakilkan.
4)
Model-model yang menggambarkan informasi, fungsi dan tingkah laku harus dipecah-pecah dalam suatu cara yang membongkar suatu detail dalam bentuk lapisan (hirarki).
5)
Proses analisis harus bergerak dari informasi dasar ke detail implementasi.
Dengan mengaplikasikan prinsip-prinsip tersebut, analis mendekati suatu masalah secara sistematis. Tujuan pelaksanaan analisis kebutuhan adalah: 1)
Memahami masalah secara menyeluruh (komprehensif) yang ada pada perangkat lunak yang akan dikembang seperti ruang lingkup produk perangkat lunak(product space) dan pemakai yang akan menggunakannya.
2)
Mendefinisikan apa yang harus dikerjakan oleh perangkat lunak untuk memenuhi keinginan pelanggan.
Secara teknis pelaksanaan pekerjaan analisis kebutuhan perangkat lunak pada dasarnya terdiri dari urutan aktivitas: 1)
Mempelajari dan memahami persoalan Pada tahap ini, seorang analis mempelajari masalah yang ada pada perangkat lunak yang dikembangkan, sehingga dapat ditentukan. a.
Siapa pemakai yang menggunakan perangkat lunak.
b.
Dimana perangkat lunak akan digunakan
c.
Pekerjaan apa saja dari pemakai yang akan dibantu oleh perangkat lunak.
d.
Apa saja cakupan dari pekerjaan tersebut, dan bagaimana mekanisme pelaksanaannya.
e.
Apa yang menjadi kendala dilihat dari sisi teknologi yang digunakan atau dari sisi hukum dan standar.
39
Cara yang digunakan oleh pengembang khususnya analis dalam memahami masalah perangkat lunak biasanya dilakukan a.
Wawancara dengan pemakai
b.
Observasi atau pengamatan lapangan
c.
Kuesioner
d.
Mempelajari referensi atau dokumen-dokumen yang digunakan, seperti dokumen hasil analisa dan perancangan perangkat lunak.
Hasil dari pemahaman masalah tersebut dapat digambarkan dengan model-model tertentu sesuai dengan jenis permasalahannya. Sebagai contoh jika masalah bisnis dapat digambarkan dengan flowmap atau bussiness use case untuk analisa berorientasi objek. Sedangkan untuk masalah matematika dapat digambarkan dengan graf. 2)
Mengindentifikasi Kebutuhan Pemakai Pada tahap identifikasi kebutuhan pemakai (user requirement) in pada prakteknya menjadi satu pelaksanaannya dengan pemahaman masalah. Hanya saja substansi yang ditanyakan ada sedikit perbedaan, yaitu: a.
Fungsi apa yang diinginkan pada perangkat lunak.
b.
Data atau informasi apa saja yang akan diproses.
c.
Kelakuan sistem apa yang diharapkan.
d.
Antarmuka apa yang tersedia (software interfaces, hardware interfaces, user interfaces, dan communication interfaces)
Untuk menangkap kebutuhan dari pemakai dengan baik,terutama kesamaan persepsi. seorang analis membutuhkan:
3)
a.
Komunikasi dan brainstorming yang intensif dengan pelanggan.
b.
Pembuatan prototype perangkat lunak atau screenshoot.
c.
Data atau dokumen yang lengkap.
Mendefinisikan kebutuhan perangkat lunak Saat melakukan pengidentifikasian kebutuhan pemakai, informasi yang diperoleh masih belum terstruktur. Biasanya pemakai akan mengungkapkan apa yang diinginkan dengan bahasa sehari-hari yang biasa mereka gunakan. Sebagi contoh, ungkapan kebutuhan pemakai dibagian akutansi. a.
Saya ingin data yang dimasukkan oleh bagian penjualan bisa langsung dijurnal.
b.
Informasi neraca keuangan bisa saya lihat kapan saja.
40
Kemudian pada tahap ini, kebutuhan pemakai yang belum terstruktur tersebut akan akan dianalisis, diklasifikasikan, dan diterjemahkan menjadi kebutuhan fungsional, antarmuka dan unjuk kerja perangkat lunak. Sebagai contoh, kebutuhan “data yang dimasukkan oleh bagian penjualan bisa langsung dijurnal” setelah dianalisis, diklasifikasikan dan diterjemahkan, mungki akan menghasilkan pendefinisian kebutuhan sebagai berikut. a.
Kebutuhan fungsional a)
Entri dan rekam data transaksi penjualan.
b)
Retrieve data transaksi penjualan untuk periode tertentu (periode sesuai dengan inputan periode yang diinputkan pada keyboard).
c)
Rekam data akumulasi transaksi penjualan periode tertentu ke jurnal umum berikut account pasangannya (kas).
b.
Kebutuhan antarmuka a)
Antarmuka pemakai untuk memasukkan dan merekam data penjualan.
b)
Antarmuka pemakai untuk menyajikan dan menjurnal informasi transaksi penjualan pada periode tertentu.
c)
Antarmuka untuk jaringan lokal yang menghubungkan perangkat lunak aplikasi dibagian penjualan dengan perangkat lunak aplikasi dibagian akutansi.
c.
Kebutuhan unjuk kerja a)
Proses jurnal hanya bisa dilakukan sekali setelah data transaksi penjualan direkam.
b)
Adanya otoritas pemakaian perangkat lunak dan akses data sesuai dengan bagian pekerjaan masing-masing.
Kemudian kebutuhan tersebut akan dimodelkan atau digambarkan dengan teknik analisis dan alat bantu tertentu. Sebagai contoh kebutuhan fungsional dapat dimodelkan dengan menggunakan a)
Data flow diagram,kamus data,dan spesifikasi proses jika menggunakan anlisis tertsruktur.
b)
Use case diagram dan skenario sistem jika menggunkan analisis berorientasi objek.
41
4)
Membuat dokumen spesifikasi kebutuhan perangkat lunak (SKPL) Semua kebutuhan yang telah didefinisikan selanjutnya dibuat dokumentasinya yaitu Spesifikasi Kebutuhan Perangkat Lunak (SKPL) atau Software Requirement Specification (SRS). Dokumen ini dibuat untuk menyatakan secara lengkap apa yang dapat dilakukan oleh perangkat lunal, termasuk deskripsi lengkap semua antarmuka yang akan digunakan.
5)
Mengkaji ulang (review) kebutuhan Proses untuk mengkaji ulang (validasi) kebutuhan apakah SKPL sudah konsisten, lengkap, dan sesuai dengan yang diinginkan oleh pemakai. Proses ini bisa dilakukan lebih dari satu kali. Dan sering kali akan muncul kebuthan-kebutuhan baru dari pemakai. Oleh karena itu, diperlukannya negosiasi antara pengembang dengan pelanggan sesuai dengan prinsip “win win solution” sampai kebutuhan tersebut disetujui oleh kedua belah pihak.
Sedangkan menurut (Pressman, 2002), analisis kebutuhan perangkat lunak dapat dibagi menjadi lima area pekerjaan, yaitu: a. Pengenalan masalah b. Evaluasi dan sistesis c.
Pemodelan
d. Spesifikasi
e. Tinjau Ulang (Review)
3. Prototipe Software Paradigma prototyping dapat terbatas atau tidak terbatas. Pendekatan terbatas sering disebut throwaway prototyping. Dengan menggunakan pendekatan tersebut prototype merupakan sebuah demonstrasi kasar dari persyaratan. Kemudian prototype dikesampingkan, dan perangkat lunak direkayasa dengan menggunakan suatu paradigm yang berbeda.
B. MODEL ANALISIS Metode atau teknik untuk melakukan analisis kebutuhan perangkat lunak dapat dikelompokkan berdasarkan pendekatan yang diambil pada saat melakukan aktivitas tersebut.
42
1. Data Flow Oriented atau Functional Oriented Sudut pandang analisis pada pendekatan ini difokuskan pada aspek fungsional dan behavioral (perilaku laku) sistem. Pengembang harus mengetahui fungsi-fungsi atau prosesproses apa saja yang ada dalam sistem, data apa yang menjadi masukannya, dimana data tersebut disimpan, transformasi apa yang akan dilakukan terhadap data tersebut, dan apa yang menjadi hasil transformasinya. Selain itu, pengembang harus mengetahui keadaan (state), perubahan (transition), kondisi (condition), dan aksi (action) dari sistem. Salah satu metode yang paling populer untuk pendekatan ini adalah Analisis Terstruktur (Structured Analysis) yang dikembangkan oleh (DeMarco,1976), Chris Gane dan Trish Sarson, dan Edwad Yourdon (Yourdon, 1989). Pada metode ini, hasil analisis dan perancangan dimodelkan dengan menggunakan beberapa perangkat pemodelan seperti: a)
Data
Flow
Diagram
(DFD)
dan
Kamus
Data
(data
dictionary)
untuk
menggambarkan fungsi-fungsi dari sistem (system functions). b)
Entity-Relationship Diagram (ERD) untuk menggambarkan data yang disimpan (data stored).
c)
State Transition Diagram (STD) untuk menggambarkan perilaku sistem.
d)
Structure Chart untuk menggambarkan struktur program.
2. Data Structured Oriented Analisis dengan pendekatan ini difokuskan pada struktur data, dimana struktur tersebut dapat dinyatakan secara hirarki dengan menggunakan konstruksi sequence, selection dan repetition. Beberapa metode berorientasi struktur data ini diantaranya adalah: a. Data Structured System Development (DSSD) Diperkenalkan pertama kali oleh J.D. Warnier [1974] dan kemudian oleh Ken Orr [1977],
sehingga
sering
disebut
juga
metode
Warnier-Orr.
Metode
ini
menggunakan perangkat entity diagram, assembly line diagram dan Warnier-Orr diagram untuk memodelkan hasil analisis dan perancangannya. b. Jackson System Development (JSD) Dikembangkan oleh M.A. Jackson [1975] dengan menggunakan perangkat pemodelan yang disebut structure diagram dan system specification diagram.
43
3. Object Oriented Berbeda dengan pendekatan-pendekatan sebelumnya, pendekatan berorientasi objek memandang sistem yang akan dikembangkan sebagai suatu
kumpulan objek yang
berkorespondensi dengan objek-objek dunia nyata. Pada pendekatan ini, informasi dan proses yang dipunyai oleh suatu objek “dienkapsulasi” (dibungkus) dalam satu kesatuan. Beberapa metode pengembangan sistem yang berorientasi objek ini diantaranya adalah: a)
Object Oriented Analysis (OOA) dan Object Oriented Design (OOD) dari Peter Coad dan Edward Yourdon (1990).
b)
Object Modeling Technique (OMT) dari James Rumbaugh (1987).
c) Object Oriented Software Engineering (OOSE).
C. ANALISIS TERSTRUKTUR Analisis Terstruktur (Structured Analysis) merupakan salah satu teknik analisis yang mengunakan pendekatan berorientasi fungsi. Teknik ini mempunyai sekumpulan petunjuk dan perangkat komunikasi grafis yang memungkinkan analis sistem mendefinisikan spesifikasi fungsional perangkat lunak secara terstruktur. Pada metode ini, semua fungsi sistem direpresentasikan sebagai sebuah proses transformasi informasi, dan disusun secara hirarkis sesuai tingkat abstraksinya (sistem maupun perangkat lunak) yang hasilnya ditujukan untuk entitas-entitas eksternal. Analisis Terstruktur pertama kali diperkenalkan oleh Tom DeMarco sekitar tahun 1978 [DEM79]. Prinsip dari teknik ini adalah dekomposisi fungsi dari sistem berdasarkan aliran data dan proses-prosesnya untuk mendapatkan produk analisis yang dapat diubah dan diperbaiki secara mudah (highly maintainable). Dalam bukunya itu, DeMarco mendefinisikan Analisis Terstruktur sebagai teknik untuk mendeskripsikan spesifikasi sistem baru melalui Data Flow Diagrams, Data Dictionary, Structured English, dan Data Structure Diagrams. Spesifikasi sistem tersebut dinyatakan dalam suatu dokumen yang disebut Spesifikasi Terstuktur (Structured Specification). Dalam
perkembangannya,
teknik
Analisis
Terstruktur
mengalami
perubahan,
penambahan, dan penyempurnaan, baik untuk perangkat pemodelannya maupun mekanisme atau cara pelaksanaannya. Salah satunya oleh Edward Yourdon [YOU89] yang memperkenalkan pendekatan baru dari Analisis Terstruktur, yaitu Analisis Terstruktur Modern (Modern Structures Analysis).
44
1. Perangkat Pemodelan Terstruktur Perangkat Pemodelan Analisis Terstruktur adalah alat bantu pemodelan yang digunakan untuk menggambarkan hasil pelaksanaan Analisis Terstruktur. Perangkat Analisis Terstruktur yang disampaikan oleh DeMarco [DEM78] adalah: a)
Diagram Aliran Data atau Data Flow Diagram (DFD)
b)
Kamus Data atau Data Dictionary
c)
Structured English
d)
Tabel Keputusan atau Decision Table
e)
Pohon Keputusan atau Decision Tree
Kelima perangkat tersebut oleh Yourdon [YOU89] dilengkapi dengan: a)
Diagram Entitas-Relasi atau Entity-Relationship Diagram (ERD)
b)
Diagram Transisi Keadaan atau State Transition Diagram (STD)
Dan sebagai pengembangan untuk menggambarkan sistem waktu nyata, disertakan Diagram Aliran Kendali atau Control Flow Diagram (CFD). Berikut adalah penjelasan rinci untuk masing-masing perangkat, khususnya untuk DFD, Kamus Data, dan Structured English.
2. Spesifikasi Proses Digunakan untuk menggambarkan deskripsi dan spesifikasi dari setiap proses yang paling rendah (proses atomik) yang ada pada sistem dengan menggunakan notasi yang disebut Structured English atau pseudo-code. Penulisannya cukup sederhana sehingga dapat digunakan sebagai media untuk mengkomunikasikan proses yang dilakukan sistem kepada pemakai. Seperti halnya notasi-notasi yang lain, ada cukup banyak variasi penulisan spesifikasi proses dengan Structured English ini. Pada buku ini akan digunakan notasi penulisan yang menggunakan kata-kata bahasa Indonesia, kecuali untuk kata-kata yang sering digunakan dalam penulisan program, misalnya Read, Write, If, While, atau Repeat. Ada tiga struktur dasar yang dapat digunakan untuk menyusun spesifikasi proses, yaitu struktur sekuensi, pemilihan dan pengulangan. Berikut adalah contoh penulisan spesifikasi proses untuk proses pembuatan laporan penjualan. Nomor
: 3.0
Nama Proses
: Buat laporan penjualan
Jenis
: Pembuatan laporan
45
Masukan
: File Barang, file Jual dan periode transaksi
Keluaran
: Laporan penjualan
Deskripsi
:
Begin Buka file BARANG dan file JUAL Baca data periode tanggal transaksi Saring (filter) data pada file JUAL sesuai periode tanggal transaksi Cetak Laporan Penjualan Tutup file BARANG dan file JUAL. End atau secara lebih ringkas: Proses 3.0 Buat Laporan Penjualan Begin Buka file BARANG dan file JUAL Baca data periode tanggal transaksi Saring (filter) data pada file JUAL sesuai periode tanggal transaksi Cetak Laporan Penjualan Tutup file BARANG dan file JUAL. End
D. KAMUS DATA Merupakan suatu tempat penyimpanan (gudang) dari data dan informasi yang dibutuhkan oleh suatu sistem informasi. Kamus data digunakan untuk mendeskripsikan rincian dari aliran data atau informasi yang mengalir dalam sistem, elemen-elemen data, file maupun basis data (tempat penyimpanan) dalam DFD. Ada aturan (konvensi) penulisannya dengan menggunakan notasi atau simbol tertentu sebagai berikut: = sama dengan atau terdiri dari atau terbentuk dari + dan [] pilih salah satu {} iterasi atau pengulangan () pilihan (option) * komentar | pemisah
46
Saat ini ada banyak variasi penulisan kamus data, yang secara umum dibedakan menjadi bentuk lengkap (long form) dan bentuk ringkas (short form). Sebagai contoh dibawah ini bentuk kamus data yang lengkap (long form): Id. Barang = Kode_Brg + Nama_Brg + Satuan + Hrg_Beli + Hrg_Jual + Banyak Kode_Brg = 1{character}6 Nama_Brg = 1{character}20 Satuan = 1{character}3 Hrg_Beli = 3{numeric}10 Hrg_Jual = 3{numeric}10 Banyak = 1{numeric}6 character = [A-Z|a-z|0-9|-| |] numeric = [0-9] Artinya: a) Identitas Barang tersusun dari atribut Kode_Brg dan Nama_Brg dan Satuan dan Hrg_Beli dan Hrg_Jual dan Banyak. b) Kode_Brg tersusun dari minimal 4 karakter dan maksimal 6 karakter. c) Nama_Brg tersusun dari minimal 8 karakter dan maksimal 20 karakter. d) Satuan tersusun dari 3 karakter. e) Hrg_Jual tersusun dari minimal 3 dijit numerik dan maksimal 10 dijit numeric f)
Jml_Stok tersusun dari 1 dijit numerik dan maksimal 6 dijit numerik.
g) Character terdari dari huruf besar A sampai Z, atau huruf kecil a sampai z atau angka 0 sampai 9, atau karakter –, atau karakter spasi. h) Numeric terdiri dari angka 0 sampai 9. Sedangkan contoh bentuk ringkas (short form) dari kamus adalah Identitas Barang = Kode_Brg + Nama_Brg + Satuan + Hrg_Jual + Jml_Stok
EVALUASI 1)
Sebutkan area pekerjaan yang harus dilakukan pada tahap analisis menurut Pressman?
2)
Jelaskan pengertian dari throwaway prototyping?
3)
Apakah Fungsi dari Kamus Data?
4) Buatlah Kamus Data untuk Menyimpan Biodata Mahasiswa!
47
BAB 5 DESAIN
A. PROSES DESAIN Desain adalah langkah pertama dalam fase pengembangan bagi setiap produk atau sistem yang direkayasa. Menurut Taylor dalam (Pressman, 2002) Desain dapat didefinisikan sebagai proses aplikasi berbagai teknik dan prinsip bagi tujuan pendefinisian suatu perangkat lunak, suatu proses atau sistem dalam detail yang memadai untuk memungkinkan realisasi fisiknya. Tujuan dari perancang sistem adalah untuk menghasilkan suatu model atau representasi dari entitas yang akan dibangun. Desain berada pada inti teknik dan proses rekayasa perangkat lunak dan diaplikasikan tanpa memperhatikan model proses perangkat lunak yang digunakan. Langkah desain menghasilkan desain data, desain arsitektur, desain interface serta desain prosedural. Desain data menghasilkan transformasi model domain informasi yang dibuat selama analisis ke dalam struktur data yang akan diperlukan untuk mengimplementasikan perangkat lunak. Objek dan hubungan data yang ditetapkan dalam diagram hubungan entitas (ERD) dan isi detail yang digambarkan di dalam kamus data, menjadi basis bagi aktifitas desain data. Desain arsitektur menentukan hubungan diantara elemen-elemen struktural utama dari program. Representasi desain tersebut berupa kerangka modular dari sebuah program komputer. Desain interface menggambarkan bagaimana perangkat lunak berkomunikasi dalam dirinya sendiri, dengan sistem yang berinteroperasi dengannya dan dengan manusia yang menggunakannya. Interface mengimplementasikan aliran informasi berupa dan kontrol. Desain prosedural mentransformasi elemen-elemen struktural dari arsitektur program ke dalam suatu deskripsi prosedur dari komponen-komponen perangkat lunak. Selama tahap desain kita membuat keputusan yang akan mempengaruhi kesuksesan konstruksi perangkat lunak, dan yang penting kemudahan bagaimana perangkat lunak dapat dipelihara. Pentingnya desain perangkat lunak dapat dinyatakan dengan suatu kata tunggal yaitu kualitas. Desain adalah tempat dimana kualitas dibangun dalam pengembangan
48
perangkat lunak. Desain memberi kita representasi perangkat lunak yang kualitasnya dapat dinilai. Desain adalah satu-satunya cara dimana kita dapat secara akurat menterjemahkan kebutuhan pelanggan ke dalam produk atau sistem perangkat lunak yang sudah selesai. Tanpa desain kita beresiko membangun system yang tidak stabil, sistem yang akan gagal pada saat perubahan kecil dibuat sehingga sulit diuji dan kualitasnya tidak dapat dinilai.
1. Desain dan Software Quality Desain perangkat lunak adalah suatu proses interaktif yang melaluinya. Persyaratan diterjemahkan ke dalam cetak biru (blueprint) untuk membangun perangkat lunak. Cetak biru menggambarkan suatu pandangan menyeluruh rekayasa perangkat lunak. Sepanjang proses desain, kualitas yang melengkapi dinilai dengan serangkaian kajian teknis formal. Terdapat 3 karakteristik yang berfungsi sebagai pedoman bagi evaluasi suatu desain yang baik: a) Desain harus mengimplementasikan keseluruhan eksplisit yang dibebankan dalam model analisis dan harus mengakomodasi semua persyaratan implisit yang diinginkan pelanggan. b) Desain harus menjadi panduan yang dapat dibaca dan dipahami bagi mereka yang menghasilkan kode dan yang menguji serta memelihara perangkat lunak. c) Desain harus memberikan suatu gambaran lengkap mengenai perangkat lunak yang menekankan data, dan perilaku implementasi. Ketiga karakteristik di atas merupakan sasaran dari proses desain. Untuk mengevaluasi kualitas dari suatu desain kita harus membangun kriteria teknis untuk desain yang baik. Criteria desain yang berkualitas baik mengikuti pedoman sebagai berikut: 1) Desain harus memperlihatkan suatu organisasi hirarki yang dengan baik menggunakan kontrol di antara elemen-elemen perangkat lunak. 2) Desain harus modular, yaitu bahwa perangkat lunak harus dipartisi secara logika ke dalam elemen-elemen yang melakukan fungsi dan sub fungsi khusus. 3) Desain harus berisi data dan abstraksi prosedural. 4) Desain harus membawa ke arah modul (misal sub rutin atau prosedur) yang memperlihatkan karakteristik fungsional independen. 5) Desain harus mengarah kepada interface yang mengurangi kompleksitas hubungan antara modul-modul dan dengan lingkungan eksternal. 6) Desain harus didapat dengan menggunakan metode berulang yang dikendalikan oleh informasi yang diperoleh selama analisis persyaratan perangkat lunak.
49
Keenam kriteria di atas tidak dapat dicapai secara kebetulan. Proses desain perangkat lunak memungkinkan adanya desain yang baik melalui aplikasi prinsip-prinsip desain fundamental, metodologi sistematis, dan kajian yang mendalam.
2. Perkembangan Desain Perangkat Lunak Evolusi desain perangkat lunak adalah suatu proses kontinu yang terus berlangsung selama
tiga
dekade.
Desain
decade
awal
dikonsentrasikan
pada
kriteria
untuk
pengembangan program moduler dan metode-metode untuk menyaring arsitektur perangkat lunak dalam cara top-down yang dikemas dalam pemrograman terstruktur. Desain decade kedua mengusulkan aliran translasi aliran data atau struktur data ke dalam definisi desain perangkat lunak. Desain dekade yang lebih baru mengusulkan pendekatan orientasi obyek ke dalam desain perangkat lunak. Banyak metode desain yang tumbuh dari kerja tersebut dan tanpa memperhatikan metode desain yang dipakai, perekayasa perangkat lunak harus mengaplikasikan serangkain prinsip dasar dan konsep dasar terhadap data, arsitektur, interface dan desain prosedural.
B. PRINSIP-PRINSIP DESAIN Desain perangkat lunak berupa proses dan model. Proses desain adalah serangkaian langkah interatif yang memungkinkan desainer menggambarkan semua aspek perangkat lunak yang dibangun. Tetapi perlu dicatat bahwa proses desain tidaklah sederhana. Keahlian kreatif, pengalaman, rasa tentang apa yang membuat perangkat lunak menjadi baik dan keseluruhan komitmen terhadap kualitas adalah faktor sukses. Model desain berbanding lurus dengan recana arsitek untuk rancangan sebuah rumah. Model desain memulai dengan menyajikan totalitas dari hal yang akan dibangun. Prinsip-prinsip desain dasar memungkinkan perekayasa perangkat lunak untuk mengendalikan proses desain. Menurut Davis dalam (Pressman, 2002) mengusulkan serangkaian prinsip bagi desain perangkat lunak yang telah diadaptasi dan diperluas sebagai berikut: a)
Proses desain tidak boleh menderita karena “tunnel vision”. Desain yang baik harus memmperhatikan pendekatan-pendekatan alternative. Menilai masingmasing pendekatan berdasarkan persyaratan masalah.
b)
Desain harus dapat ditelusuri sampai model analisis (reverse engineering).
c)
Desain tidak boleh berulang.
d)
Desain harus meminimalkan kesenjangan intelektual di antara perangkat lunak dan masalah yang ada di dunia nyata.
50
e)
Desain
harus
mengungkap
keseragaman
dan
integrasi.
Desain
seragam
memperlihatkan bahwa satu orang mengembangkan keseluruhannya. f)
Desain harus terukur dan mengakomodasi perubahan.
g)
Desain harus terstruktur dan berdegradasi dengan baik, bahkan pada saat data dan event-event menyimpang atau menghadapi kondisi operasi.
h)
Desain bukanlan pengkodean dan pengkodean bukanlah desain. Bahkan bila dibuat desain procedural detail bagi komponen-komponen program, maka tingkat abstraksi dari model desain adalah lebih tingi daripada kode sumber.
i)
Desain harus dinilai kualitasnya pada saat desain dibuat, bukan setelah jadi.
j)
Desain
harus
dikaji
untuk
meminimalkan
kesalahan-kesalahan
konseptual
(semantic).
C. KONSEP DESAIN Serangkaian konsep desain perangkat lunak fundamental telah berkembang, meskipun tingkat minat pada setiap konsep bervariasi selama bertahun-tahun. Konsep desain membantu perekayasa perangkat lunak untuk menjawab beberapa pertanyaan berikut: 1)
Kriteria apa yang dapat digunakan untuk mempartisi perangkat lunak ke dalam komponen-komponen individual?
2)
Bagaimana detail struktur data atau fungsi dipisahkan dari suatu representasi konseptual perangkat lunak?
3)
Adakah kriteria yang seragam yang menentukan kualitas teknis suatu desain perangkat lunak?
Konsep desain perangkat lunak fundamental memberikan kerangka kerja untuk mendapatkan program yang berfungsi dengan benar.
1. Abstraction Pada saat kita mempertimbangkan solusi modular terhadap setiap masalah, banyak tingkat abstraksi yang dapat diperoleh. Pada tingkat abstraksi tinggi solusi dinyatakan dalam istilah yang luas. Pada saat kita bergerak pada tingkat abstraksi yang berbeda, kita bekerja untuk membuat abstraksi data dan prosedural. Abstraksi prosedural adalah urutan instruksi yang diberi nama dan mempunyai fungsi tertentu dan terbatas. Contoh abstraksi procedural adalah kada Open pada sebuah pintu. Open mengklasifikasikan urutan panjang dari langkahlangkah procedural (misal berjalan ke pintu, menggapai dan meraih tombol; memutar tombol; mendorong pintu; dsb.). Abstraksi data adalah kumpulan data yang bernama yang menggambarkan objek data.
51
Sejumlah bahasa pemrograman (seperti Ada, Modula dan CLU) memberikan mekanisme untuk membuat berbagai tipe data abstrak. Abstraksi kontrol adalah bentuk ketiga
dari abstraksi yang dipakai dalam desain perangkat lunak. Abstraksi kontrol
mengimplementasikan suatu mekanisme kontrol program tanpa menentukan detail-detail internal.
2. Modularity Konsep modularitas dalam perangkat lunak komputer telah didukung selama hampir empat dekade. Modularitas merupakan konsep dimana perangkat lunak dipecah menjadi beberapa komponen dan diberi nama untuk dipanggil secara terpisah. Modularitas adalah attribute tunggal dari perangkat lunak yang memungkinkan sebuah program untuk dikelola secara intelektual. Perangkat lunak monolitik (yakni program besar yang terdiri dari modul tunggal) tidak dapat dipahami dengan mudah oleh pembaca. Jumlah alur kontrol, cakupan referensi, jumlah variable, dan kompleksitas keseluruhan akan membuat pemahaman menjadi hamper tidak mungkin. Ada beberapa kriteria yang menjadi ciri sistem modular yang efektif: a)
Dekomposisi Modular Bila metode desain memberikan suatu mekanisme sistematis untuk melakukan dekomposisi terhadap masalah menjadi sub masalah-sub masalah, maka metode dasain akan mengurangi kompleksitas keseluruhan masalah, sehingga dapat mencapai solusi modular efektif.
b)
Komposabilitas Modular Bila suatu metode desain memungkinkan komponen desain (reuseable) yang ada untuk dipasang ke dalam sebuah sistem baru, maka metode desain akan menghasilkan suatu solusi modular yang tidak berulang.
c)
Kemampuan Pemahaman Modular Jika sebuah modul dapat dipahami sebagai unit yang berdiri sendiri (tanpa referensi dan modul lain), maka modul akan lebih mudah dibangun dan diubah.
d)
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 perubahan dapat diminimalkan.
52
e) Proteksi Modular Bila terjadi kondisi yang menyimpang pada modul tersebut, pengaruh dari efek samping yang disebabkan oleh kesalahan akan diminimalkan.
3. Software Architecture Arsitektur perangkat lunak mencakup struktur keseluruhan perangkat lunak dan cara dimana struktur memberikan integrasi konseptual bagi suatu sistem. Dalam bentuknya yang paling sederhana, arsitektur merupakan struktur hirarki dari komponen program (modul), cara bagaimana komponen tersebut berinteraksi, dan struktur yang digunakan oleh komponen. Secara lebih luas komponen dapat digeneralisir untuk mewakili elemen-elemen sistem mayor dan interaksi mereka. Tujuan desain perangkat lunak adalah untuk mendapatkan gambaran arsitektural sebuah sistem. Gambaran tersebut berfungsi sebagai kerangka kerja yang dari sana aktivitas desain yang lebih detail dilakukan. Serangkaian pola arsitektural memungkinkan perekayasa perangkat lunak untuk menggunakan kembali konsep tingkat desain.
a. Control Hierarchy Hirarki kontrol, disebut juga struktur program mewakili organisasi komponen (modul) serta mengimplementasikan suatu hirarki kontrol. Hirarki kontrol tidak mengimplementasikan aspek procedural dari perangkat lunak, seperti urutan proses, urutan kejadian, keputusan atau pengulangan.
Hirarki kontrol juga mewakili dua karateristik yang berbeda dari arsitektur perangkat lunak yaitu visibilitas dan konektivitas. Visibilitas menunjuk kepada serangkaian komponen yang dapat diminta atau dipakai sebagai daa oleh komponen yang lain. Sedangkan konektivitas menandai serangkain komponen yang diminta secara tidak langsung atau digunakan sebagai data oleh sebuah modul yang ditetapkan. Sebagai contoh sebuah modul yang secara langsung menyebabkan modul lain memulai eksekusi akan disambungkan dengan modul tersebut.
b. Structural Partitioning Struktur program harus dipartisi baik secara horizontal maupun struktural/vertikal. Partisi arsitektural secara horizontal memberikan keuntungan nyata, yaitu: a)
Menghasilkan perangkat lunak yang mudah diuji.
b)
Perangkat lunak mudah dipelihara.
53
c)
Efek samping buruk yang dihasilkan perangkat lunak lebih sedikit.
d) Menghasilkan perangkat lunak yang mudah diperluas.
Gambar 5.1 Partisi Horisontal Partisi vertical seperti gambar 5.2 yang sering disebut pemfaktoran menyatakan bahwa control/pembuat keputusan (decision making modules) dan kerja harus didistribusikan secara
top-down dalam arsitektur program. Modul tingkat puncak harus melakukan fungsi-fungsi kontrol dan melakukan sedikit kerja pemrosesan aktual. Modul-modul yang dalam arsitektur berada di bawah harus menjadi para pekerjanya yaiut melakukan tugas input, komputasi dan output. Sifat perubahan dalam arsitektur program membenarkan kebutuhan akan partisi vertikal. Perubahan pada modul kontrol (tinggi dalam arsitektural) akan memiliki probabilitas penyebaran efek samping yang lebih tinggi ke modul yang menjadi sub ordinatnya. Perubahan pada modul pekerja (worker modules) yang memiliki tingkat rendah dalam arsitektur, lebih kecil kemungkinannya untuk menyebabkan penyebaran efek samping. Secara umum perubahan program komputer berada di seputar perubahan input, komputasi dan transformasi serta output.
Gambar 5.2 Partisi Vertikal/Struktural
54
c. Data Structure Struktur data adalah representasi dari hubungan logis antara elemen-elemen data individual. Karena struktur informasi akan secara bervariasi mempengaruhi desain prosedural akhir, maka struktur data sama pentingnya dengan struktur program pada representasi arstitektur perangkat lunak. Struktur data menentukan organisasi, metode akses, tingkat hubungan dan alternatif pemrosesan untuk informasi. Ada sejumlah struktur data klasik yang membentuk blok bangunan bagi struktur yang lebih canggih. Struktur data yang lain digabungkan atau dikonstruksi dengan menggunakan struktur data fundamental seperti yang telah dijelaskan. Penting
untuk
dicatat
bahwa
struktur
data
seperti
struktur
program
dapat
direpresentasikan pada tingkat abstraksi yang berbeda. Contohnya stack adalah model konseptual dari suatu struktur data yang dapat diimplementasikan sebagai vendor atau sebuah linked list.
d. Software Procedure Struktur program membatasi hirarki kontrol tanpa melihat urutan pemrosesan data keputusan. Prosedur perangkat lunak berfokus pada detail-detail pemrosesan dari masingmasing modul secara terpisah. Prosedur harus memberikan spesifikasi yang teliti terhadap pemrosesan, mencakup urutan event, poin-poin keputusan nyata, operasi repetitive dan bahkan organisasi/struktur data. Ada hubungan antara struktur dan prosedur. Pemrosesan yang diindikasikan bagi masing-masing modul harus mencakup referensi bagi semua sub ordinat modul yang sedang digambarkan, yaitu representasi procedural dari perangkat lunak yang dilapiskan seperti pada gambar 5.3.
55
Gambar 5.3 Prosedur dibuat Berlapis
e. Information Hiding Konsep modularitas membawa setiap desainer perangkat lunak ke suatau pertanyaan mendasar yaitu bagaimana mendekomposisi suatu solusi perangkat lunak untuk mendapatkan serangkaian modul terbaik. Prinsip penyembunyian informasi menyatakan bahwa modul ditandai dengan keputusan desain yang (masing-masing) tersembunyi dari semua desain lain. Dengan kata lain modul seharusnya ditentukan dan didesain sehingga informasi (prosedur dan data) yang diisikan pada sebuah modul tidak dapat diakses ke modul lain yang tidak memiliki kepentingan terhadap informasi tersebut. Penyembunyian informasi memberikan bukti bahwa modularitas efektif dapat dicapai dengan menetapkan serangkaian modul yang independen yang berkomunikasi satu dengan yang lainnya dimana hanya informasi itu yang diperlukan untuk mencapai fungsi perangkat lunak. Penggunaan penyembunyian informasi sebagai suatu criteria desain untuk sistem modular memberikan keuntungan terbesarnya pada saat dibutuhkan modifikasi selama pengujian dan sesudahnya yaitu selama pemeliharaan perangkat lunak. Karena sebagaian besar data dan prosedur disembunyikan dari bagian perangkat lunak lain, maka kesalahan kecil yang
56
terjadi selama modifikasi punya kemungkinan lebih kecil untuk menyebarke lokasi lain dalam perangkat lunak.
D. EFECTIVE MODULAR DESIGN Semua konsep data fundamental yang telah dijelaskan berfungsi untuk mempercepat desain modular.
1. Cohesi Kohesi adalah suatu ekstensi alamiah dari konsep penyembunyian informasi. Modul kohesi melalukan suatu tugas tunggal pada suatu prosedur perangkat lunak yang memerlukan sedikit interaksi dengan prosedur yang sedang dilakukan di bagian lain dari suatu program. Lebih ringkasnya modul kohesi seharusnya hanya melakukan satu hal saja.
2. Coupling Coupling merupakan sebuah perangkaian pengukuran interkoneksi antara modul-modul pada sebuah struktur program. Pada desain perangkat lunak kita mengusahakan perangkaian yang serendah mungkin. Gambar 5.4 memberikan sebuah ilustrasi mengenai tipe coupling modul yang berbedabeda. Modul a dan d adalah sub ordinat bagi modul-modul yang berbeda. Masing-masing tidak berhubungan sehingga tidak terjadi perangkaian langsung. Modul c adalah sub ordinat dari modul a dan diakses melalui sebuah daftar argument yang konvensional di mana data dilewatkan. Selama ada argument sederhana (yakni data sederhana yang dilewatkan; hubungan satu-ke-satu dari item yang ada), perangkaian rendah. Variasi perangkaian data yang disebut perangkaian melekat (stamp coupling) ditemukan jika satu bagian dari suatu struktur data (daripada sebuah argument sederhana) dilewatkan melalui sebuah interface modul. Hal ini terjadi antara modul a dan b.
57
Gambar 5.4 Tipe Coupling/Perangkaian
E. ARCHITECTURAL DESIGN Sasaran utama desain arsitektur adalah untuk mengembangkan struktur program modular dan merepresentasikan hubungan kontrol antar modul. Desain arsitektur juga membentuk struktur program dan struktur data dengan menentukan interface yang memungkinkan data mengalir melalui program. Sistem-sistem besar selalu diuraikan menjadi subsistem-subsistem yang memberikan set layanan yang berhubungan. Proses perancangan awal untuk mengidentifikasi subsistem ini dan menetapkan kerangka kerja untuk kontrol dan komunikasinya disebut perancangan arsitektural dan output proses perancangan ini merupakan deskripsi dari arsitektur perangkat lunak (Sommerville, 2003). Keuntungan perancangan dan dokumentasi arsitektural perangkat lunak memiliki keuntungan sebagai berikut: a)
Komunikasi stake holder. Arsitektur merupakan presentasi tingkat tinggi dari sistem yang dapat digunakan sebagai fokus pembahasan oleh berbagai stake holder.
b)
Analis sistem. Membuat arsitektur sistem yang eksplisit pada tahap dini pengembangan sistem mengandung arti bahwa analisis akan dilakukan.
58
c) Pemakaian ulang berskala besar. Arsitektur sistem merupakan deskripsi yang kompak dan dapat ditangani mengenai bagaimana sistem diorganisir dan bagaimana komponen-komponen saling mengoperasikan.
1. Software Architecture Masing-masing metode desain memiliki kekuatan dan kelemahan. Faktor seleksi yang penting untuk suatu metode desain adalah luasnya aplikasi di mana aplikasi dapat diaplikasikan. Desain berorientasi pada aliran data dapat menyetujui rentang area aplikasi yang luas. Desain yang berorientasi pada aliran data merupakan suatu metode desain arsitektur yang mengijinkan transisi yang baik dari model analisis ke deskripsi desain dari struktur program. Transisi dari aliran informasi (yang ditunjukkan sebagai diagram aliran data) ke struktur dilakukan sebagai bagian dari proses lima langkah : (1) tipe aliran informasi dibangun; (2) batas aliran diindikasikan; (3) DFD dipetakan ke dalam struktur program; (4) hirarki control ditentukan dengan pemfaktoran; (5) struktur disaring atau diperhalus dengan melakukan pengukuran desain.
2. Data Design Model
data
sering
kali
dipakai
bersama
dengan
model
aliran
data
untuk
mendeskripsikan struktur informasi yang sedang diproses. Model data semantic dari desain perangkat lunak dapat dilihat pada Gambar 5.5.
Gambar 5.5 Model Semantik
59
Kebanyakan sistem perangkat lunak yang besar memanfaatkan database sebagai tempat penyimpanan data yang besar. Pada beberapa kasus, database ini ada secara independen terhadap sistem perangkat lunak. Teknik pemodelan data yang paling banyak dipakai adalah pemodelan Entiti Relasi Atribut (pemodelan ERA) yang menunjukkan entitas data, atribut yang berhubungan dan relasi antar entitas-entitas ini. Perancangan Database adalah proses untuk menentukan isi dan pengaturan data yang dibutuhkan untuk mendukung berbagai rancangan sistem. Perancangan sistem terjadi pada dua tingkat , yaitu : 1)
Pada tingkat pertama, perencanaan sistem, analisis dan rancangan umum dilaksanakan untuk menetapkan kebutuhan pemakai. Tingkat perancangan database ini melibatkan tahap front-end, bebas dari perancangan database tertentu atau Database Management System (DBMS).
2)
Pada tingkat kedua, rancangan umum, seperti diagram entitas relasi tingkat tinggi, ditransformasikan (atau didekomposisikan) ke dalam perancangan database rinci untuk sebuah DBMS tertentu yang akan digunakan untuk mengimplementasikan sistem total. Tiga model database yang cukup dikenal adalah: a) Model Hierarkikal b) Model Jaringan c) Model Relasional Pada masa lalu banyak penjual (vendors) menawarkan Database Management Systems
(DBMS) yang berdasarkan pada Model Hierarkikal dan Model Jaringan.
Saat ini Model
Relasional adalah dominan. Karena itu hampir semua penjual perangkat lunak database menawarkan produk perangkat lunak Relational Database Management Systems (RDBMS).
Model Entity Relationship Adalah suatu penyajian data dengan menggunakan Entity dan Relationship.
Entity 1) Entity adalah obyek yang dapat dibedakan dalam dunia nyata 2) Entity set adalah kumpulan dari entity yang sejenis 3) Entity set dapat berupa: a)
Obyek secara fisik
b) Obyek secara konsep
: Rumah, Kendaraan, Peralatan : Pekerjaan, Perusahaan, Rencana
60
Relationship 1) Relationship adalah hubungan yang terjadi antara satu atau lebih entity. 2) Relationship set adalah kumpulan relationship yang sejenis.
Contoh dari relationship dapat dilihat pada Gambar 5.6.
Atribut
Gambar 5.6 Relationship
1) Atribut adalah karakteristik dari entity atau relationship, yang menyediakan penjelasan detail tentang entity atau relationship tersebut.
2) Nilai Atribut merupakan suatu data aktual atau informasi yang disimpan pada suatu atribut di dalam suatu entity atau relationship. Jenis-Jenis Atribut : 1) Key Atribut yang digunakan untuk menentukan suatu entity secara unik. 2) Atribut Simple Atribut yang bernilai tunggal. 3) Atribut Multivalue Atribut yang memiliki sekelompok nilai untuk setiap instan entity, dapat dilihat pada Gambar 5.7.
Gambar 5.7 Atribut Multivalue 4) Atribut Composite
61
Suatu atribut yang terdiri dari beberapa atribut yang lebih kecil yang mempunyai arti tertentu, dapat dilihat pada Gambar 5.8.
Gambar 5.8 Atribut Composite 5) Atribut Derivatif Suatu atribut yang dihasilkan dari atribut yang lain, dapat dilihat pada Gambar 5.9.
Gambar 5.9 Atribut Derivatif
F. USER INTERFACE DESIGN Desain arsitektur memberikan kepada perekayasa perangkat lunak suatu gambaran mengenai struktur program. Desain interface memfokuskan diri pada tiga area perhatian (1) desain interface antara modul-modul perangkat lunak; (2) desain interface antara perangkat lunak dan prosedur dan konsumen informasi bukan manusia lainnya (yakni entitas eksternal lainnya); (3) desain interface antara seorang manusia (seperti pemakai komputer). Interface user harus bersifat tekstual atau form. Hampir semua user komputer sekarang memiliki personal computer. Komputer-komputer ini menyediakan interface user grafis (graphical user interface/GUI) yang mendukung tampilan berwarna dengan resolusi tinggi dan interaksi dengan memakai mouse dan keyboard. Beberapa karakteristik yang mendasar dari tipe interface bersifat GUI adalah:
62
Karakteristik Windows
Keterangan Multiple window memungkinkan berbagai informasi ditampilkan secara simultan pada layar user
Icon
Icon mewakili berbagai tipe informasi, file maupun proses.
Menu
Perintah dipilih dari menu dan bukan diketikkan dalam suatu bahasa perintah.
Pointing (alat penunjuk)
Peranti
penunjuk
seperti
mouse
digunakan
untuk
melakukan pemilihan dari menu atau menunjuk item yang diinginkan pada window. Grafik
Elemen-elemen grafis dapat dicampur dengan teks pada tampilan yang sama.
EVALUASI 1)
Apakah manfaat dari reverse engineering?
2)
Apakah pengertian reverse engineering?
3)
Apakah perbedaan antara cohesi dan coupling?
4) Gambarkan sebuah ERD yang menggambarkan mahasiswa mengambil kartu rencana studi setiap semester akademik!
63
BAB 6 DESAIN UNTUK SYSTEM REAL-TIME
A. SYSTEM REAL-TIME 1. Pengertian System Real-time Real time system disebut juga dengan Sistem waktu nyata. Sistem yang harus menghasilkan respon yang tepat dalam batas waktu yang telah ditentukan. Jika respon komputer melewati batas waktu tersebut, maka terjadi degradasi performansi atau kegagalan sistem. Sebuah Real time system adalah sistem yang kebenarannya secara logis didasarkan pada kebenaran hasil-hasil keluaran sistem dan ketepatan waktu hasil-hasil tersebut dikeluarkan. Aplikasi penggunaan sistem seperti ini adalah untuk memantau dan mengontrol peralatan seperti motor, assembly line, teleskop, atau instrumen lainnya. Peralatan telekomunikasi dan jaringan komputer biasanya juga membutuhkan pengendalian secara Real time. Berdasarkan batasan waktu yang dimilikinya, Real time system ini dibagi atas: 1. Hard Real time 2. Soft Real time 3. Firm Real time
Komponen dari Real time system ini adalah: 1. Perangkat keras 2. Sistem Operasi Real time 3. Bahasa Pemrograman Real time 4. Sistem Komunikasi
Berdasarkan
response
time
dan
dampaknya,
maka
komputasi
real-time
dapat dibedakan menjadi : 1.
Sistem Hard Real-Time (HRTS) Sistem hard real-time dibutuhkan untuk menyelesaikan critical task dengan jaminan waktu tertentu. Jika kebutuhan waktu tidak terpenuhi, maka aplikasi akan gagal. Dalam definisi lain disebutkan bahwa kontrol sistem hard real-time dapat mentoleransi keterlambatan tidak lebih dari 100 mikro detik.Secara umum, sebuah proses di kirim dengan sebuah pernyataan jumlah waktu dimana dibutuhkan untuk menyelesaikan atau menjalankan I/O. Kemudian penjadwal dapat menjamin proses untuk selesai atau menolak permintaan
64
karena tidak mungkin dilakukan. Mekanisme ini dikenal dengan resource reservation. Oleh karena itu setiap operasi harus dijamin dengan waktu maksimum. Pemberian jaminan seperti ini tidak dapat dilakukan dalam sistem dengan secondary storage atau virtual memory, karena sistem seperti ini tidak dapat meramalkan waktu yang dibutuhkan untuk mengeksekusi suatu proses. Contoh dalam kehidupan sehari-hari adalah pada sistem pengontrol pesawat terbang. Dalam hal ini, keterlambatan sama sekali tidak boleh terjadi,karena dapat berakibat tidak terkontrolnya pesawat terbang. Nyawa penumpang yang ada dalam pesawat tergantung dari sistem ini, karena jika sistem pengontrol tidak dapat merespon tepat waktu, maka dapat menyebabkan kecelakaan yang merenggut korban jiwa.
2.
Sistem Soft Real-Time (SRTS) Komputasi soft real-time memiliki sedikit kelonggaran. Dalam sistem ini,proses yang kritis menerima prioritas lebih daripada yang lain. Walaupun menambah fungsi soft real-time ke sistem time sharing mungkin akan mengakibatkan ketidakadilan pembagian sumber daya dan mengakibatkan delay yang lebih lama, atau mungkin menyebabkan starvation, hasilnya adalah tujuan secara umum sistem yang dapat mendukung multimedia, grafik berkecepatan tinggi, dan variasi tugas yang tidak dapat diterima di lingkungan yang tidak mendukung komputasi soft real-time.
Contoh penerapan sistem ini dalam kehidupan sehari-hari adalah pada alat penjual/pelayan otomatis. Jika mesin yang menggunakan sistem ini telah lama digunakan, maka mesin tersebut dapat mengalami penurunan kualitas,misalnya waktu pelayanannya menjadi lebih lambat dibandingkan ketika masih baru. Keterlambatan pada sistem ini tidak menyebabkan kecelakaan atau akibat fatal lainnya, melainkan hanya menyebabkan kerugian keuangan saja. Jika pelayanan mesin menjadi lambat, maka para pengguna dapat saja merasa tidak puas dan akhirnya dapat menurunkan pendapatan pemilik mesin. Setelah batas waktu yang diberikan telah habis, pada sistem hard realtime,aplikasi yang dijalankan langsung dihentikan. Akan tetapi, pada sistem softreal-time, aplikasi yang telah habis masa waktu pengerjaan tugasnya,dihentikan
secara
bertahap
atau
dengan
kata
lain
masih
diberikan
toleransiwaktu.Mengimplementasikan fungsi soft real-time membutuhkan design yang hati-hati dan aspek yang berkaitan dengan sistem operasi. Pertama,sistem harus punya prioritas penjadualan, dan proses real-time harus memiliki prioritas tertinggi, tidak melampaui waktu, walaupun prioritas non real-time dapat terjadi.Kedua, dispatch latency harus lebih kecil. Semakin kecil latency, semakin cepat real-time proses mengeksekusi. Untuk menjaga dispatch tetap rendah, kita butuh agar system call untuk preemptible. Ada beberapa cara untuk mencapai tujuan ini.
65
Pertama adalah dengan memasukkan preemption points di durasi system call yang lama, yang memeriksa apakah prioritas utama butuh untuk dieksekusi. Jika sudah, maka contex switch mengambil alih, ketika high priority proses selesai, proses yang diinterupsi meneruskan dengan system call. Points premption dapat diganti hanya di lokasi yang aman di kernel dimana kernel struktur tidak dapat dimodifikasi. Metoda yang lain adalah dengan membuat semua kernel preemptible.Karena operasi yang benar dapat dijamin, semua struktur data kernel harus diproteksi dengan mekanisme sinkronisasi. Dengan metode ini, kernel dapat selalu di preemptible, karena setiap data kernel yang sedang di update diproteksi dengan pemberian prioritas yang tinggi. Jika ada proses dengan prioritas tinggi ingin membaca atau memodifikasi data kernel yang sedang dijalankan, prioritas yang tinggi harus menunggu sampai proses dengan prioritas rendah tersebut selesai. Situasi seperti ini dikenal dengan priority inversion. Kenyataanya, serangkaian proses dapat saja mengakses sumber daya yang sedang dibutuhkan oleh proses yang lebih tinggi prioritasnya. Masalah ini dapat diatasi dengan priority- inheritance protocol, yaitu semua proses yang sedang mengakses sumber daya mendapat prioritas tinggi sampai selesai menggunakan sumber daya. Setelah selesai, prioritas proses inidikembalikan menjadi seperti semula. 3.
Semi Hard Real-Time System (HRTS) atau Semi Soft Real-Time ( SRTS )
Metoda ini merupakan gabungan antara Semi Hard Real-Time System (HRTS) atau Semi Soft Real-Time ( SRTS ). Dengan demikian waktu deadlinenya lebih pendek jika dibandingkan dengan soft real-time ( SRTS ). 4.
Interaktif Deadline ( Waktu Deadlinenya Bisa Ditawar ) Pada interaktif real-time, maka waktu deadlinennya bisa ditawar, artinya tidak secara
mutlak pada titik tertentu, tetapi tergantung dari kesepakatan yang ditentukan dan fleksibel.
5.
Probabilistic / Statistik Metode ini biasanya menggunakan teori probabilitas / teori kemungkinan dengan metoda
statistik.
6.
Intelligence RTS Metode ini biasanya menggunakan Expert Systems / Kecerdasan buatan / Artifial
Inteligence atau Kendali Cerdas. 2. Karakteristik System Real Time System Real Time umumnya punya karakteristik sebagai berikut:
66
• Biasanya merupakan embedded system • Biasanya membutuhkan pemrosesan konkuren untuk sejumlah input yang masuk, sehingga perlu didefinisikan sejumlah task untuk memrosesnya, serta perlu strategi khusus untuk menjadwalkan eksekusi setiap task • Harus bisa menangani input yang sinkron maupun asinkron • Punya kebutuhan yang tinggi terhadap reliability dan safety, sehingga fault tolerance dan exception handling jadi hal yang penting • Seringkali melibatkan berbagai hardware sehingga ada kebutuhan untuk mendefinisikan antarmuka yang baik Elemen Real Time System umumnya terdiri dari: 1. Sensor control processes; yaitu proses yang menerima input dari berbagai sensor 2. Data processor; yaitu proses yang akan melakukan komputasi terhadap data-data yang diterima dari berbagai sensor
3. Actuator control processes; yaitu proses yang akan membangkitkan sinyal untuk berbagai actuator 3.
Manfaat dan Tujuan System Real Time Manfaat : • Sistem waktu nyata keras menjamin bahwa proses waktu nyata dapat diselesaikan dalam batas waktu yang telah ditentukan. Contoh : sistem safety-critical. • Sistem waktu nyata banyak digunakan dalam bermacam-macam aplikasi. Sistem waktu nyata tersebut dapat pula ditanam di dalam alat khusus seperti di kamera, mp3 players, serta di pesawat dan mobil. • Real time juga berguna untuk pengendali reaktor nuklir atau sistem pengendali rem mobil. Juga sering dijumpai pada peralatan medis, peralatan pabrik, peralatan untuk riset ilmiah, dan sebagainya.
Tujuan : Bertujuan untuk menyelesaikan masalah dengan waktu tertentu dan proses waktu nyata dapat diselesaikan dalam waktu tertentu.
67
B. ANALISIS DAN SIMULASI UNTUK SYSTEM REAL-TIME Serangkain atribut di dinamis yang tidak dapat dipisahkan dari persyaratan fungsional sebuah sistem real-time : -
Penanganan interupsi dan switching konteks
-
Waktu respon
-
Laju transfer data dan throughput
-
Alokasi sumber daya dan penanganan priorotas
-
Sikronisasi tugas dan komunikasi antar tugas Masing-masing atribut kerja itu
dapat ditentukan, tetapi sangat sulit untuk
membuktikan apakah elemen sistem akan mencapai respon yang diinginkan, sumber daya sistem akan memadai untuk memenuhi persyaratan komputasional atau apakah algoritma pemrosesan akan mengeksekusi dengan kecepatan yang memadai. Analisis sistem real-time memungkinkan perekayasa sistem memperkirakan masalah-masalah “timing and sizing”.
1. Piranti Matematis untuk Analisis Sistem Real-Time Serangkaian
peranti
matematis
yang
memungkinkan
perekayasa
sistem
memodelkan elemen sistem real-time dan mengakses masalah ukuran dan timing, telah diusulkan oleh Thomas McCabe. Dengan kurang mendasarkan pada teknik analisis aliran data, pendekatan McCabe membuat analisis mampu memodelkan elemen perangkat lunak dan perangkat keras sistem real-time, merepresentasikan kontrol dengan cara probabilistik dan mengaplikasikan analisis jaringan, teori antrian dan grafik dan model matematis Markovian untuk mendapatkan timing sistem dan ukuran sumber daya. Teknik analisis real-time dari McCabe didasar atas model aliran dari sistem realtime. Daripada menggunakan DFD dengan cara yang konvensional, McCabe berpendapat bahwa transformasi (gelembung) suatu DFD dapat direpresentasikan sebagai keadaan proses dari rantai Markov dan aliran data sendirilah yang merepresentasikan transisi di antara keadaan-keadaan proses. Analisis dapat menunjuk probabilitas transisional pada masing-masing jalur aliran data. 0
View more...
Comments
