arsitektur perangkat lunak


BAB 1
PENDAHULUAN
1.1. Pengertian Rekayasa Perangkat Lunak
Definisi Rekayasa
Engineering = rekayasa
􀂾Pemakaian ‘science’ untuk menyelesaikan ‘masalah praktis’
􀂾Dari tidak ada menjadi ada

Definisi Perangkat Lunak
Ada beberapa definisi perangkat lunak yang pernah dikemukakan antara lain :
• Software = Perangkat lunak
􀂾Kumpulan program komputer dengan fungsi tertentu
• Perangkat lunak adalah
1. Instruksi (program komputer) yang bila dieksekusi dapat menjalankan fungsi tertentu,
2. Struktur data yang dapat membuat program memanipulasi informasi, dan
3. Dokumen yang menjelaskan operasi dan penggunaan program (Pressman, 1997).
• Perangkat lunak adalah program komputer, prosedur, aturan, dan dokumentasi yang berkaitan serta data, yang bertalian dengan operasi suatu sistem komputer (IEEE, 1993).

Karakteristik Perangkat Lunak
Perangkat lunak lebih dikenal sebagai elemen lojik daripada fisik, oleh karena itu perangkat lunak memiliki karakteristik yang berbeda dari perangkat keras :
1. Perangkat lunak dikembangkan atau direkayasa, jadi tidak diproduksi dalam pengertian klasik.
2. Merupakan produk yang unik (tidak ada seri produksi).
3. Perangkat lunak tidak pernah akan rusak/aus karena selalu diperbaharui
4. Tidak terlihat (invisible).
5. Perangkat lunak pada umumnya dibangun sesuai keinginan, jadi tidak dibentuk dari komponen yang sudah ada.
6. Fleksibel, sehingga mudah dimodifikasi.
7. Dihubungkan (linked) dengan sistem komputer.

Rekayasa perangkat lunak (software engineering) adalah suatu proses rancang bangun. Beberapa definisi tentang rekayasa perangkat lunak :
• Pembentukan dan penggunaan prinsip rekayasa (engineering) untuk mendapatkan perangkat lunak secara ekonomis namun andal dan dapat bekerja secara efesien pada komputer (Fritz Bauer, 1968).
• Penerapan pendekatan yang sistematis, disiplin, dan terukur untuk pengembangan, operasi, dan pemeliharaan perangkat lunak (IEEE, 1993).
• Suatu disiplin yang mengintegrasikan proses/prosedur, metode, dan perangkat tools untuk pembangunan perangkat lunak komputer (Pressman, 97).
• Merupakan aplikasi dari prinsip-prinsip sains untuk

Modul Rekayasa Perangkat Lunak Halaman 1 dari 64

o Mengurutkan transformasi masalah menjadi solusi yang dapat bekerja dengan baik
o Urutan pemeliharaan perangkat lunak tersebut sampai tidak dapat digunakan lagi (Alan M. Davis)

Proses RPL dimulai jauh sebelum “Coding” dilakukan dan berlanjut terus setelah versi awal dari program selesai dikerjakan.
Tujuan dari RPL adalah
a. Menghasilkan sebuah perangkat lunak yang berkualitas. Yang dimaksud dengan berkualitas dapat dilihat dari tiga sisi, sisi sponsor (individu atau organisasi yang telah mengeluarkan biaya dalam pembangunan perangkat lunak), sisi pemakai (siapapun yang menggunakan perangkat lunak tersebut), sisi maintainer / modifier (yang memelihara dan memodifikasi perangkat lunak tersebut). Untuk lebih jelasnya lihat gambar 1.1.
Sisi Sponsor :
Tujuan utama sponsor adalah menghasilkan dan atau menghemat uang. Sponsor ingin menggunakan perangkat lunak tersebut untuk meningkatkan produktivitas organisasi. Sponsor mengharapkan untuk dapat menghasilkan sebuah layanan dengan biaya yang rendah tetapi masuk akal. Karena itu sistem yang dibuat harus handal, fleksibel dan efisien. Selain itu biaya dari pemeliharaan, modifikasi dan peningkatan dari sistem tersebut harus serendah mungkin.
Sisi Pemakai :
Bagi pemakai perangkat lunak adalah alat untuk membantu menyelesaikan tugas-tugasnya. Karena itu perangkat lunak harus menyediakan fungsi-fungsi yang dibutuhkan oleh pemakai. Perangkat lunak juga harus handal dan efisien, perangkat lunak harus dapat menghasilkan output yang konsisten. Selain itu pemakai harus merasa perangkat lunak yang dibuat mudah untuk dipelajari, mudah digunakan dan mudah untuk diingat.
Sisi Maintainer/modifier :
Yang diinginkan oleh maintainer/modifier adalah perangkat lunak tersebut memiliki sangat sedikit error pada saat penginstallan pertama (catatan : sangat kecil kemungkinannya untuk menghasilkan perangkat lunak yang 100 % bebas dari bug). Selain itu perangkat lunak tersebut harus terdokumentasi dengan baik. Source code juga harus mudah dibaca, terstruktur dan dirancang dengan baik dan bersifat modular.
b. Tujuan kedua dari RPL adalah menghasilkan perangkat lunak dengan biaya yang efisien.
c. Sedangkan tujuan ketiga dari RPL adalah menghasilkan perangkat lunak tepat pada waktunya.

Modul Rekayasa Perangkat Lunak Halaman 2 dari 64
Gambar 1.1 Paremeter Perangkat Lunak Yang Berkualitas Berdasarkan Sudut Pandang
Rekayasa perangkat lunak merupakan suatu teknologi berlapis, yaitu proses/prosedur, metode, dan perangkat, dengan fokus kualitas sebagai dasar utamanya.
Mengapa Rekayasa Perangkat Lunak ?
Adanya krisis perangkat lunak (NATO conference, 1968) :
• Perangkat lunak lebih banyak menyebabkan masalah daripada menyelesaikannya.
• Peningkatan ukuran perangkat lunak tanpa pengorganisasian.
• Perbaikan suatu kesalahan menyebabkan timbulnya kesalahan lainnya.
• Tidak ada kendali pemeliharaan.

Masalah-masalah perangkat lunak :
• Perangkat lunak telah diselesaikan dan diserahkan (delivered) tetapi tidak pernah digunakan (47%).
• Pemakai (user) sudah membayar untuk perangkat lunak tetapi tidak pernah jadi dan diserahkan (29,7%).
• Perangkat lunak digunakan setelah dilakukan modifikasi (3%).
• Perangkat lunak digunakan sebagaimana mestinya (2%).

Selain itu faktor pendukung kehadiran rekayasa perangkat lunak adalah :
• Ketidak mampuan untuk memprediksi waktu, usaha dan biaya pada pengembangan perangkat lunak.
• Kualitas perangkat lunak yang kurang baik.

Modul Rekayasa Perangkat Lunak Halaman 3 dari 64

• Perubahan perbandingan (rasio) harga perangkat keras dan perangkat lunak.
• Kemajuan teknologi perangkat keras.
• Kemajuan teknik perangkat lunak.
• Kebutuhan yang meningkat terhadap perangkat lunak.
• Kebutuhan akan perangkat lunak yang lebih besar dan kompleks.

1.2. Pengertian Perangkat Lunak
Jenis-jenis Perangkat Lunak
Dilihat dari sudut pandang fungsinya, perangkat lunak dapat dikelompokkan menjadi :
1. Perangkat lunak sistem
Perangkat lunak yang kegunaannya lebih banyak ditujukan untuk operasional komputer.
• sistem operasi
• penerjemah bahasa pemrograman (compiler/interpreter)
2. Perangkat lunak aplikasi
Perangkat lunak yang kegunaannya lebih banyak ditujukan untuk membantu menyelesaikan masalalah-masalah yang dihadapi oleh pemakai.
• program paket yang sudah jadi
• program aplikasi buatan sendiri

Sedangkan dilihat dari aplikasinya, perangkat lunak dibedakan menjadi :
1. Perangkat Lunak Sistem (Sistem Software)
Sekumpulan program yang ditulis untuk kepentingan program lain, contoh editor, driver dan lain-lain
2. Perangkat Lunak Waktu Nyata (Real Time Software)
Perangkat lunak yang digunakan untuk mengukur/menganalisis atau mengontrol proses pemasukan data dari lingkungan luar sampai menghasilkan laporan yang diinginkan
3. Perangkat Lunak Bisnis (Business Software)
Perangkat lunak yang memberikan fasilitas operasi untuk bisnis atau fasilitas pengambilan keputusan manajemen, contoh sistem akuntansi, inventory, payroll dan lain-lain
4. Perangat Lunak Rekayasa dan Sains (Engineering and Scientific Software)
Perangkat lunak yang digunakan di dalam bidang aplikasi teknik dan kerekayasaan
Perangkat lunak jenis ini biasanya berhubungan dengan komputasi data numerik, CAD (Computer Aided Design), simulasi sistem, dan lain-lain.
5. Embedded Software
Perangkat lunak yang digunakan untuk mengontrol suatu produk dan sistem dimana perangkat lunak tersebut disimpan. Biasanya ditempatkan di ROM, contoh Tombol di Microwave Oven
6. Perangkat Lunak Komputer Pribadi (Personal Computer Software)
Banyak digunakan pada aplikasi yang bersifat perorangan, contohnya : pengolah kata, spreadsheet, game, DBMS dan lain-lain.
7. Perangkat Lunak Intelegensia Buatan (Artificial Intelligent Software)

Modul Rekayasa Perangkat Lunak Halaman 4 dari 64

Dibuat dengan menggunakan teknik algoritma non-numerik untuk memecahkan masalah yang kompleks, digunakan dalam bidang aplikasi kecerdasan buatan, contohnya : game, expert sistem, neural network, Turbo Prolog, dan lain-lain

1.3. Mitos Perangkat Lunak
Berkaitan dengan Manajemen :
Biasanya muncul pada manajer yang bertanggung jawab terhadap perangkat lunak. Mereka biasanya ditekan untuk menjaga budget, jadwal harus selalu terpenuhi dan harus meningkatkan kualitas. Mitos tersebut antara lain :
Mitos : Kita sudah punya buku yang berisi standard dan prosedur yang banyak untuk pengembangan perangkat lunak. Bukankah hal ini sudah cukup untuk mencari semua yang ingin diketahui ?
Kenyataan : Buku-buku itu memang lengkap, tapi apakah digunakan ? Apakah praktisi perangkat lunak sadar dengan keberadaannya? Apakah cocok dengan pengembangan yang modern? Apakah benar-benar lengkap ? Pada banyak kasus jawabannya adalah tidak.
Mitos : Staff Kami mempunyai alat Bantu pengembangan yang canggih, bahkan dibelikan komputer generasi terbaru.
Kenyataan : Masalah pengembangan perangkat lunak yang berkualitas lebih penting dari sekedar komputer yang terbaru. CASE (Computer Aided Software Engineering) tools lebih penting daripada perangkat keras untuk mendapatkan kualitas dan produktifitas yang baik, tapi banyak pengembang perangkat lunak yang tidak menyadarinya.
Mitos : Jika Kita dikejar jadwal, tambah programmer untuk mengejarnya
Kenyataan : Membuat perangkat lunak bukan proses mekanis seperti industri manufaktur. Jika kita menambah orang pada proyek yang terlambat itu justru akan lebih terlambat
Berkaitan dengan Klien
Konsumen sering mempercayai mitos karena pembuat perangkat lunak kurang berusaha untuk membetulkan misinformasi ini.
Mitos : Sebuah kalimat umum yang menyatakan objektif sudah cukup untuk memulai menulis program. Kita bias perinci lagi nanti.
Kenyataan : Definisi yang tidak jelas, justru akan menggagalkan usaha pengembangan perangkat lunak. Justru diperlukan deskripsi formal dan detil dari domain informasi, fungsi, performansi, antarmuka, batasan desain, dan kriteria validasi. Karakteristik ini hanya bias didapat melalui komunikasi total antara pelanggan dan pengembang.
Mitos : Kebutuhan proyek akan terus berubah, tapi perubahan ini akan dapat ditanggapi dengan mudah karena perangkat lunak itu bersifat fleksibel
Kenyataan : memang betul kebutuhan perangkat lunak akan berubah, namun dampaknya tergantung pada waktu pemunculannya. Jika muncul pada tahap definisi, pengaruhnya tidak banyak, lebih kebelakang dampaknya akan lebih besar.
Modul Rekayasa Perangkat Lunak Halaman 5 dari 64
Berkaitan dengan Pengembang
Mitos : Setelah program selesai ditulis dan dapat dijalankan, maka tugas sudah selesai.
Kenyataan : Ada yang mengatakan bahwa “Lebih cepat program dibuat, maka lebih lama selesainya”. Dari data industri 50-70% dari usaha pada pembuatan program akan bertambah lagi setelah program dilihat untuk pertama kalinya oleh pelanggan.
Mitos : Selama program belum berjalan, sulit untuk mengetahui kualitasnya
Kenyataan : Software review adalah cara efektif untuk mencari Software defect daripada tahap pengujian
Mitos : Faktor penentu suksesnya proyek adalah program yang dapat berjalan
Kenyataan : Program hanyalah salah satu komponen dari perangkat lunak. Dokumentasi penting sebagai dasar pengembangan yang sukses serta sebagai penunjuk untuk pemeliharaan perangkat lunak
Modul Rekayasa Perangkat Lunak Halaman 6 dari 64
BAB 2
METODOLOGI PENGEMBANGAN PERANGKAT LUNAK
2.1. Latar Belakang
Pada pertengahan tahun 60 sampai 70-an banyak dikembangkan sistem-sistem perangkat lunak yang besar. Sistem-sistem yang dikembangkan ini banyak yang dipandang tidak efisien, kurang berhasil, bahkan banyak yang gagal. Kegagalan ini disebabkan karena tidak tersedianya teknik pengembangan perangkat lunak yang baik. Pada awal tahun 70-an mulai muncul metodologi-metodologi pengembangan perangkat lunak yang cukup baik.
Pengembangan perangkat lunak dapat diartikan sebagai proses membuat suatu perangkat lunak baru untuk menggantikan perangkat lunak lama secara keseluruhan atau memperbaiki perangkat lunak yang telah ada. Agar lebih cepat dan tepat dalam mendeskripsikan solusi dan mengembangkan perangkat lunak, juga hasilnya mudah dikembangkan dan dipelihara, maka pengembangan perangkat lunak memerlukan suatu metodologi khusus. Metodologi pengembangan perangkat lunak adalah suatu proses pengorganisasian kumpulan metode dan konvensi notasi yang telah didefinisikan untuk mengembangkan perangkat lunak. Secara prinsip bertujuan untuk membantu menghasilkan perangkat lunak yang berkualitas. Penggunaan suatu metodologi sesuai dengan persoalan yang akan dipecahkan dan memenuhi kebutuhan pengguna akan menghasilkan suatu produk perekayasaan yang berkualitas dan terpelihara serta dapat menghindari masalah-masalah yang sering terjadi seperti estimasi penjadwalan dan biaya, perangkat lunak yang tidak sesuai dengan keinginan pengguna dan sebagainya.
Metodologi pengembangan perangkat lunak (atau disebut juga model proses atau paradigma rekayasa perangkat lunak) adalah suatu strategi pengembangan yang memadukan proses, metode, dan perangkat (tools).
Menurut Pressman (1997) Komponen metodologi pengembangan perangkat lunak dapat dibagi dalam tiga unit, yaitu :
1. Metode, yaitu suatu cara atau teknik pendekatan yang sistematik yang dipergunakan untuk
mengembangkan perangkat lunak. Metode ini mencakup : Perencanaan proyek dan perkiraan, analisis keperluan sistem dan perangkat lunak, perancangan struktur data, arsitektur program, prosedur algoritma, Coding, uji coba dan pemeliharaan.
2. Alat bantu (Tools), yaitu alat-alat (manual atau otomatis) yang mendukung pengembangan
perangkat lunak. Terdapat 2 alat Bantu yang dapat digunakan yaitu : alat Bantu manual
dan alat Bantu otomatis.
3. Prosedur, yang dipergunakan untuk mendefinisikan urut-urutan pekerjaan (daur) dari
metode dan alat bantu tersebut.
Secara umum daur hidup pengembangan perangkat lunak meliputi tahapan-tahapan atau aktivitas pengembangan yang terdiri dari tahap analisis, tahap perancangan, tahap implementasi serta tahap pengujian dan perawatan perangkat lunak. Tahap analisis dan perancangan merupakan tahapan awal yang penting dalam suatu paradigma pemgembangan perangkat lunak, karena sangat mempengaruhi tahapan selanjutnya. Sehingga jika terjadi kesalahan pada tahap analisis dan perancangan, maka akan terdapat juga kesalahan pada tahap implementasi dan tahapan-tahapan selanjutnya. Tahap implementasi perangkat lunak bertujuan untuk menerapkan spesifikasi kebutuhan perangkat lunak ke dalam bahasa pemrograman tertentu. Tahap pengujian perangkat lunak dilakukan untuk menemukan kesalahan (bug) yang mungkin terdapat di dalam sebuah perangkat lunak. Sedangkan tahap perawatan perangkat lunak fokusnya adalah pengubahan. Ada tiga pengubahan yaitu : pembetulan, adaptasi (perbaikan terhadap lingkungan) dan perluasan (penambahan karena permintaan pemakai).
Sequence diagram
M.Fadly Syahputra, M.Sc.IT
Pengantar
Dalam Perancangan Sistem Hubungan Antara Timeline dan Process Juga Diperhitungkan untuk Digambarkan
Penggambaran Model Dalam Rentang Waktu dan Urutan Proses Adalah Untuk Memastikan Sistem Dapat Berjalan Sesuai Dengan Keinginan Pengguna
Defenisi
Sequence : Urutan, Tahapan
Diagram: Diagram
Sequence Diagram : Penggambaran Model Perangkat Lunak Dalam Urutan Atau Tahapan Tertentu
Elemen
Object Lifeline : Menggambarkan Batasan Objek
Boundary,Controller, Entiti
Massage Arrow: Menggambarkan Alir Proses, Perintah Atau Pengiriman Data
Elemen
Boundary: Berhubungan Dengan Proses Input Output Ataupun Interface
Controller: Berhubungan Dengan Proses
Entiti : Berhubungan Dengan Input-Output Data
Elemen
Activation: Menggambarkan Aktivasi Objek
Actor : Menggambarkan Actor Sebagai Objek
Contoh Sequence Diagram
Contoh Sequence Diagram

2.2. Proses Pengembangan Perangkat Lunak
Proses pengembangan perangkat lunak adalah suatu proses dimana kebutuhan pemakai diterjemahkan menjadi produk perangkat lunak. Proses ini mencakup aktivitas penerjemahan kebutuhan pemakai menjadi kebutuhan perangkat lunak, transformasi kebutuhan perangkat lunak menjadi desain, penerapan desain menjadi kode program, uji coba kode program, dan instalasi serta pemeriksaan kebenaran perangkat lunak untuk operasional (IEEE. 1990). Berdasarkan pengertian tersebut, secara umum dapat dikatakan bahwa proses pengembangan perangkat lunak mengikuti tahap-tahap :
1. Menentukan APA yang harus dikerjakan oleh perangkat lunak dalam satu rentang
waktu tertentu.
2. Mendefinisikan BAGAIMANA perangkat lunak dibuat, mencakup arsitektur
perangkat lunaknya, antar muka internal, algoritma, dan sebagainya.
3. Penerapan (penulisan program) dan pengujian unit-unit program.
4. Integrasi dan pengujian modul-modul program.
5. Validasi perangkat lunak secara keseluruhan (pengujian sistem).

2.3. Siklus Pengembangan Perangkat Lunak
Siklus pengembangan perangkat lunak atau sering disebut juga dengan siklus hidup perangkat lunak adalah (IEEE,1987) :
• Periode waktu yang diawali dengan keputusan untuk mengembangkan produk perangkat lunak dan berakhir setelah perangkat lunak diserahkan. Umumnya siklus pengembangan ini terdiri dari tahap analisis kebutuhan, perancangan, penerapan, pengujian, dan instalasi serta pemeriksaan.
• Periode waktu yang diawali dengan keputusan untuk mengembangkan produk perangkat lunak dan berakhir saat produk tidak dapat ditingkatkan lebih jauh lagi oleh pengembang.

2.4. Model Proses Pengembangan Perangkat Lunak
A. Linear Sequential Model
Linear sequential model (atau disebut juga “classic life cycle” atau “waterfall model”) adalah metode pengembangan perangkat lunak dengan pendekatan sekuensial dengan cakupan aktivitas :
1. Rekayasa sistem dan Analisis (Sistem Engineering and Analysis)
Karena perangkat lunak adalah bagian dari sistem yang lebih besar, pekerjaan dimulai dari pembentukan kebutuhan-kebutuhan untuk seluruh elemen sistem dan kemudian memilah mana yang untuk pengembangan perangkat lunak. Hal ini penting, ketika perangkat lunak harus berkomunikasi dengan hardware, orang dan basis data
2. Analisis kebutuhan perangkat lunak (Software Requirements Analysis)
Pengumpulan kebutuhan dengan fokus pada perangkat lunak, yang meliputi :
Domain informasi, fungsi yang dibutuhkan, unjuk kerja/performansi dan antarmuka. Hasilnya harus didokumentasi dan direview ke pelanggan
3. Perancangan (Design)
Ada 4 atribut untuk program yaitu : Struktur Data, Arsitektur perangkat lunak, Prosedur detil dan Karakteristik Antarmuka. Proses desain mengubah kebutuhan-kebutuhan menjadi bentuk karakteristik yang dimengerti perangkat lunak sebelum

Modul Rekayasa Perangkat Lunak Halaman 8 dari 64

dimulai penulisan program. Desain ini harus terdokumentasi dengan baik dan menjadi bagian konfigurasi perangkat lunak.
4. Pembuatan kode (Coding)
Penterjemahan perancangan ke bentuk yang dapat dimengerti oleh mesin, dengan menggunakan bahasa pemrograman
5. Pengujian (Testing)
Setelah kode program selesai testing dapat dilakukan. Testing memfokuskan pada logika internal dari perangkat lunak, fungsi eksternal dan mencari segala kemungkinan kesalahan dan memriksa apakah sesuai dengan hasil yang diinginkan.
6. Pemeliharaan (Maintenance)
Merupakan bagian paling akhir dari siklus pengembangan dan dilakukan setelah perangkat lunak dipergunakan. Kegiatan :
• Corrective Maintenance : Mengoreksi kesalahan pada perangkat lunak, yang baru terdeteksi pada saat perangkat lunak dipergunakan
• Adaptive Maintenance : Penyesuaian dengan lingkungan baru, misalnya sistem operasi atau sebagai tuntutan atas perkembangan sistem komputer, misalnya penambahan printer driver
• Perfektive Maintenance : Bila perangkat lunak sukses dipergunakan oleh pemakai. Pemeliharaan ditujukan untuk menambah kemampuannya seperti memberikan fungsi-fungsi tambahan, peningkatan kinerja dan sebagainya.

Kelemahan model linear sequential:
1. Proyek yang sebenarnya jarang mengikuti alur sekuensial seperti diusulkan, sehingga perubahan yang terjadi dapat menyebabkan hasil yang sudah didapat tim harus diubah kembali/iterasi sering menyebabkan masalah baru.
2. Linear sequential model mengharuskan semua kebutuhan pemakai sudah dinyatakan secara eksplisit di awal proses, tetapi kadang-kadang ini tidak dapat terlaksana karena kesulitan yang dialami pemakai saat akan mengungkapkan semua kebutuhannya tersebut.
3. Pemakai harus bersabar karena versi dari program tidak akan didapat sampai akhir rentang waktu proyek.
4. Adanya waktu menganggur bagi pengembang, karena harus menunggu anggota tim proyek lainnya menuntaskan pekerjaannya.

B. Prototyping Model
Pendekatan prototyping model digunakan jika pemakai hanya mendefenisikan objektif umum dari perangkat lunak tanpa merinci kebutuhan input, pemrosesan dan outputnya, sementara pengembang tidak begitu yakin akan efesiensi algoritma, adaptasi sistem operasi, atau bentuk antarmuka manusia-mesin yang harus diambil. Cakupan aktivitas dari prototyping model terdiri dari :
1. Mendefinisikan objektif secara keseluruhan dan mengidentifikasi kebutuhan yang sudah diketahui.
2. Melakukan perancangan secara cepat sebagai dasar untuk membuat prototype.

Modul Rekayasa Perangkat Lunak Halaman 9 dari 64

3. Menguji coba dan mengevaluasi prototype dan kemudian melakukan penambahan dan perbaikan-perbaikan terhadap prototype yang sudah dibuat.

Kelemahan prototyping model :
1. Pelanggan yang melihat working version dari model yang dimintanya tidak menyadari, bahwa mungkin saja prototype dibuat terburu-buru dan rancangan tidak tersusun dengan baik
2. Pengembang kadang-kadang membuat implementasi sembarang, karena ingin working version bekerja dengan cepat

C. RAD (Rapid Application Development) Model
Merupakan model proses pengembangan perangkat lunak secara linear sequential yang menekankan pada siklus pengembangan yang sangat singkat. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60-90 hari).
Pendekatan RAD model menekankan cakupan :
1. Pemodelan bisnis (Bussiness Modelling)
Aliran informasi diantara fungsi-fungsi bisnis dimodelkan dengan suatu cara untuk
menjawab pertanyaan-pertanyaan berikut : Informasi apa yang mengendalikan proses
bisnis ? Kemana informasi itu pergi? Siapa yang memprosesnya ?
2. Pemodelan data (Data Modelling)
Aliran informasi yang didefinisikan sebagai bagian dari fase pemodelan bisnis disaring ke dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut. Karakteristik/atribut dari masing-masing objek diidentifikasi dan hubungan antara objek-objek tersebut didefinisikan.
3. Pemodelan proses (Process Modelling)
Aliran informasi yang didefinisikan dalam fase pemodelan data ditransformasikan untuk mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran pemrosesan diciptakan untuk menambah, memodifikasi, menghapus atau mendapatkan kembali sebuah objek data.
4. Pembuatan aplikasi (Application generation)
Selain menciftakan perangkat lunak dengan menggunakan bahasa pemrograman generasi ketiga yang konvensional, RAD lebih banyak memproses kerja untuk memakai lagi komponen program yang telah ada atau menciftakan komponen yang bias dipakai lagi. Pada semua kasus, alat-alat Bantu otomatis dipakai untuk memfasilitasi kontruksi perangkat lunak.
5. Pengujian dan pergantian (Testing and turnover)
Karena proses RAD menekankan pada pemakaian kembali, banyak komponen yang telah diuji. Hal ini mengurangi keseluruhan waktu pengujian. Tapi komponen baru harus diuji.

Kelemahan RAD model :
1. Untuk proyek dengan skala besar, RAD membutuhkan sumber daya manusia yang cukup untuk membentuk sejumlah tim RAD.
2. RAD membutuhkan pengembang dan pemakai yang mempunyai komitmen untuk melaksanakan aktivitas melengkapi sistem dalam kerangka waktu yang singkat.

Modul Rekayasa Perangkat Lunak Halaman 10 dari 64

3. Akan menimbulkan masalah jika sistem tidak dapat dibuat secara modular.
4. RAD tidak cocok digunakan untuk sistem yang mempunyai resiko teknik yang tinggi.

D. Spiral Model
Merupakan model proses perangkat lunak yang memadukan wujud pengulangan dari model prototyping dengan aspek pengendalian dan sistematika dari linear sequential model, dengan penambahan elemen baru yaitu analisis resiko. Model ini memiliki 4 aktivitas penting, yaitu :
1. Perencanaan (Planning), penentuan tujuan, alternatif dan batasan
2. Analisis resiko (Risk Analysis), analisis alternatif dan identifikasi/pemecahan resiko
3. Rekayasa (Engineering), pengembangan level berikutnya dari produk
4. Evaluasi Pemakai (Customer Evaluation) penilaian terhadap hasil rekayasa

Bentuk spiral memberikan gambaran bahwa semakin besar iterasinya, maka menunjukkan makin lengkap versi dari perangkat lunak yang dibuat. Selama awal sirkuit, objektif, alternatif dan batasan didefinisikan serta resiko diidentifikasikan dan dianalisa. Jika resiko menunjukkan ada ketidakpastian terhadap kebutuhan, maka prototyping harus dibuat pada kuadran rekayasa. Simulasi dan pemodelan lain dapat digunakan untuk mendefinisikan masalah dan memperbaiki kebutuhan.
Pelanggan mengevaluasi hasil rekayasa (kuadran evaluasi pelanggan) dan membuat usulan untuk perbaikan. Berdasarkan masukan dari pelanggan, fase berikutnya adalah perencanaan dan analisis resiko. Setelah analisis resiko selalu diperiksa apakah proyek diteruskan atau tidak, jika resiko terlalu besar, maka proyek dapat dihentikan.
Model spiral ini adalah pendekatan yang paling realistic untuk sistem sekala besar. Metode ini menggunakan pendekatan evolusioner, sehingga pelanggan dan pengembang dapat mengerti dan bereaksi terhadap suatu resiko yang mungkin terjadi
Kelemahan spiral model :
1. Sulit untuk meyakinkan pemakai (saat situasi kontrak) bahwa penggunaan pendekatan ini akan dapat dikendalikan.
2. Memerlukan tenaga ahli untuk memperkirakan resiko, dan harus mengandalkannya supaya sukses.
3. Belum terbukti apakah metode ini cukup efisien karena usianya relatif baru.

E. Fourth Generation Techniques (4GT)
Istilah generasi ke empat, mengarah ke perangkat lunak yang umum yaitu tiap pengembang perangkat lunak menentukan beberapa karakteristik perangkat lunak pada level tinggi.
Saat ini pengembangan perangkat lunak yang mendukung 4GT, berisi tool-tool berikut :
• Bahasa non prosedural untuk query basis data
• Report generation
• Data manipulation
• Interaksi layar
• Kemampuan grafik level tinggi
• Kemampuan spreadsheet

Modul Rekayasa Perangkat Lunak Halaman 11 dari 64
Tiap tool ini ada tapi hanya untuk sauatu aplikasi khusus.
Menggunakan perangkat bantu (tools) yang akan membuat kode sumber secara otomatis berdasarkan spesifikasi dari pengembang perangkat lunak. Hanya digunakan untuk menggunakan perangkat lunak yang menggunakan bahasa khusus atau notasi grafik yang diselesaikan dengan syarat yang dimengerti pemakai. Cakupan aktivitas 4GT :
1. Pengumpulan kebutuhan, idealnya pelanggan akan menjelaskan kebutuhan yang akan ditranslasikan ke prototype operasional.
2. Translasi kebutuhan menjadi prototype operasional, atau langsung melakukan implementasi secara langsung dengan menggunakan bahasa generasi keempat (4GL) jika aplikasi relatif kecil.
3. Untuk aplikasi yang cukup besar, dibutuhkan strategi perancangan sistem walaupun 4GL akan digunakan.
4. Pengujian.
5. Membuat dokumentasi.
6. Melaksanakan seluruh aktivitas untuk mengintegrasikan solusi-solusi yang membutuhkan paradigma rekayasa perangkat lunak lainnya.

Salah satu keuntungan penggunaan model 4GT adalah pengurangan waktu dan peningkatan produktivitas secara besar, sementara kekurangannya terletak pada kesulitan penggunaan perangkat bantu (tools) dibandingkan dengan bahsa pemrograman, dan juga kode sumber yang dihasilkannya tidak efisien.
Untuk aplikasi yang yang kecil, adalah mungkin untuk langsung berpindah dari pengumpulan kebutuhan ke implementasi dengan menggunakan 4GL. Tapi untuk aplikasi yang besar, dibutuhkan pengembangan strategi desain untuk sistem, walau digunakan 4GL. Penggunaan 4GT tanpa perencanaan yang matang (untuk proyek skala besar) akan meyebabkan kesulitan yang sama (kualitas dan pemeliharaan yang jelek, ketidakpuasan pelanggan) seperti dengan metode konvensional.
Modul Rekayasa Perangkat Lunak Halaman 12 dari 64
BAB 3
MANAJEMEN PROYEK PERANGKAT LUNAK
3.1. Proses-proses Dalam Manajemen Proyek
Manajemen proyek merupakan lapisan pertama dalam proses rekayasa perangkat lunak skala besar. Untuk menuju pada proyek yang berhasil, perlu dimengerti tentang :
• Lingkup pekerjaan
• Resiko yang dapat ditimbulkan
• Sumber-sumber yang diperlukan
• Tugas yang harus dilaksanakan
• Patokan yang harus diikuti
• Usaha atau biaya yang dikeluarkan
• Dan Penjadwalan

Awal Proyek Perangkat Lunak
Untuk mengestimasi biaya, pembagian tugas, dan penjadwalan, sebelum sebuah proyek direncanakan perlu :
• Memastikan tujuan dan ruang lingkup
• Memperhatikan alternatif-alternatif solusi
• Identifikasi batasan teknik dan manajerial

Pengukuran dan Satuan Ukuran
Pengukuran dan satuan ukuran akan membantu untuk mengerti proses-proses dalam pengembangan produk dan produk itu sendiri. Proses dan produk diukur dalam usaha untuk meningkatkan kualitasnya.
Estimasi
Dalam aktifitas utama proyek yaitu perencanaan, dilakukan estimasi :
• Sunber daya manusia (ukuran orang/bulan)
• Jangka waktu kronologis (Ukuran waktu kalender)
• Biaya (Ukuran uang Rp)

Analisis Resiko
Analisis resiko sangat penting dalam manajemen proyek perangkat lunak. Beberapa hal yang harus diperhatikan berkaitan dengan resiko adalah ;
• Masa yang akan dating : resiko apa yang mempengaruhi trend (kecenderungan) proyek perangkat lunak
• Perubahan : Bagaimana perkembangan dunia mempengaruhi keawetan dan kesuksesan perangkat lunak
• Pilihan : metode apa yang dipakai, berapa orang diperlukan, seberapa tinggi kualitas perangkat lunak dan sebagainya

Analsis resiko merupakan serangkaian langkah untuk menyiasati resiko, yaitu :
• Identifikasi resiko
Identifikasi resiko melist semua resiko sesuai dengan kategori(secara makro) sebagai berikut :
1. Resiko proyek : masalah pembiayaan, penjadwalan, personil, sumber daya, pelanggan dan kebutuhan dikaitkan dengan akibatnya terhadap pelanggan.

Modul Rekayasa Perangkat Lunak Halaman 13 dari 64

2. Resiko teknis : masalah desain, implementasi, antarmuka, verifikasi dan pemeliharaan.
3. Resiko bisnis : termasuk di dalamnya adalah resiko pasar, resiko manajemen, dan resiko pembiayaan.
Salah satu metode terbaik untuk mengerti tiap resiko adalah dengan sejumlah pertanyaan seperti :
1. Adakah orang-orang yang paling top (The best) ?
2. Sesuaikah keahlian orang-orang tersebut?
3. Cukupkah orang-orang yang tersedia?
4. Apakah staf cukup dapat dipercaya untuk keseluruhan proyek?
5. Akan adakah staf yang bekerja paruh waktu?
6. Apakah staf telah memiliki persepsi yang benar tentang pekerjaannya?
7. Sudah cukupkah pelatihan untuk staf?
8. Cukup rendahkah tingkat pelimpahan kerja untuk menjamin kelanjutan proyek?
• Perkiraan resiko
Memperhitungkan lebih lanjut estimasi resiko dalam bentuk : [ri, li, xi] dengan
ri : resiko
li : kemungkinan terjadinya
xi : akibat dari resiko dengan memprioritaskan resiko dan memulai memikirkan cara
mengendalikan dan atau mengurangi resiko yang mungkin terjadi
• Proyeksi resiko
Disebut juga estimasi resiko, adalah usaha untuk mengukur setiao resiko dengan 2 cara :
1. Kemungkinan adanaya resiko
2. Konsekuensi (masalah yang bisa timbul karena resiko)

Ada 4 aktivitas estimasi resiko :
1. Memastikan skala yang merefleksikan kemungkinan resiko
2. Memperkirakan konsekuensi resiko
3. Estimasi efek dari resiko pada proyek dan produk
4. Menentukan akurasi keseluruhan dari proyeksi resiko
• Strategi manajemen resiko
• Putusan (Resolution) resiko
• Dan Pemantauan resiko

Penjadwalan
Langkah-langkah yang dilakukan dalam penjadwalan :
• Identifikasi sekumpulan tugas
• Pastikan keterkaitan antar tugas
• Estimasi usaha untuk tiap-tiap tugas
• Tentukan pekerja dan sumber-sumber lainnya
• Buat jaringan tugas
• Buat jadwal kerja berdasarkan waktu

Penelusuran dan Pengendalian
Penelusuran dan pengendalian dilakukan setelah ada penjadwalan yang pasti, yaitu memeriksa apakah tugas telah dilaksanakan sesuai dengan jadwal.
3.2. Satuan Ukuran Produktivitas dan Kualitas Perangkat Lunak
Modul Rekayasa Perangkat Lunak Halaman 14 dari 64
Pengukuran perangkat lunak dilakukan untuk :
• Indikasi kualitas produk
• Perkiraan produktivitas orang-orang yang menghasilkan produk
• Perkiraan manfaat dari penerapan metode dan tools
• Membentuk dasar dari estimasi
• Menegaskan (Justify) permintaan tools baru dan pelatihan

Satuan ukuran perangkat lunak dikategorikan ke dalam :
• Satuan ukuran produktivitas : Output dari proses rekayasa
• Satuan ukuran kualitas : indikasi tingkat pemenuhan kebutuhan konsumen
• Satuan ukuran teknik : Karakteristik perangkat lunak

Kategori lain untuk pengukuran :
• Pengukuran berorientasi besarnya (Ukuran) : Besarnya perangkat lunak = jumlah baris program
Pengukuran berorientasi ukuran merupakan pengukuran langsung. Pengukuran berorientasi ukuran menggunakan tabel berisi data berorientasi ukuran yang merupakan daftar proyek pengembangan perangkat lunak yang telah diselesaikan dikaitkan dengan data berorientasi ukuran untuk proyek yang bersangkutan
Contoh perhitungan :
o Produktivitas = KLOC (Kilo Line of Code)/Orang-Bulan
o Kualitas = Cacat (Kesalahan)/ KLOC
o Biaya = Satuan uang ($ atau Rp)/KLOC
o Dokumentasi = Jumlah halaman dokumentasi/KLOC
• Pengukuran berorientasi fungsi : fungsi = ruang lingkup informasi dan tingkat kesulitannya
Merupakan pengukuran tidak langsung, yang menitikberatkan pada fungsionalitas atau utilitas program. Disebut juga metode Function Point sesuai dengan informasi-informasi yang didefinisikan sebagai :
o Jumlah masukan dari pemakai
o Jumlah keluaran dari pemakai
o Jumlah penyelidikan dari pemakai
o Jumlah file
o Jumlah antarmuka eksternal

3.3. Satuan Ukuran Kualitas Parangkat Lunak
Kualitas perangkat lunak dihitung pada saat proses rekayasa perangkat lunak ataupun setelah diserahkan kepada pemakai. Satuan ukuran kualitas perangkat lunak pada saat proses rekayasa :
o Kompleksitas program
o Modularitas yang efektif
o Besarnya program

Definisi pengukuran kualitas menurut Gilb:
• Kebenaran (Correctness) : Program harus bekerja dengan benar. Kebenaran merupakan tingkat perangkat lunak bekerja sesuai dengan fungsi yang dibutuhkan. Pengukuran yang umum adalah cacat (defect) /KLOC

Modul Rekayasa Perangkat Lunak Halaman 15 dari 64

• Perawatan (Maintainability) : Kemudahan perbaikan jika ada kesalahan, penyesuaian terhadap perubahan lingkungan atau peningkatan sesuai permintaan pemakai
• Integritas (Integrity) : Pengukuran tingkat ketahanan perangkat lunak terhadap serangan (disengaja/tidak) pada program, data dan dokumen
• Kegunaan (Usability) : Berkaitan dengan kemudahan pemakaian yang diukur berdasarkan keahlian yang diperlukan untuk mempelajari sistem, waktu yang dibutuhkan untuk dapat menggunakan sistem, peningkatan produktivitas dengan penggunaan sistem dan perkiraan yang sifatnya subjektif pada kelakuan pemakai

Menurut Basili dan Zelkowitz ada 5(lima) faktor yang mempengaruhi produktivitas perangkat lunak :
• Faktor manusia : jumlah dan tingkat keahlian tim
• Faktor masalah : Tingkat kerumitan masalah yang harus dipecahkan
• Faktor proses : Teknik analisis dan desain, bahasa dan tools
• Faktor produk : keandalan dan performansi sistem berbasis komputer
• Faktor sumber daya : ketersediaan tools, sumber-sumber perangkat keras dan perangkat lunak

Modul Rekayasa Perangkat Lunak Halaman 16 dari 64
BAB 4
ANALISIS KEBUTUHAN PERANGKAT LUNAK
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 aktivitas sistem information engineering dan software project planning.
Tahap analisis adalah tahapan pengumpulan kebutuhan-kebutuhan dari semua elemen sistem perangkat lunak yang akan di bangun. Pada tahap ini dibentuk spesifikasi kebutuhan perangkat lunak, fungsi perangkat lunak yang dibutuhkan, performansi (unjuk kerja) sistem perangkat lunak, penjadwalan proyek, identifikasi sumber daya (manusia , perangkat keras dan perangkat lunak yang dibutuhkan) dan taksiran biaya pengembangan perangkat lunak.
Kegunaan analisis adalah untuk memodelkan permasalahan dunia nyata agar dapat dimengerti. Permasalahan dunia nyata harus dimengerti dan dipelajari supaya spesifikasi kebutuhan perangkat lunak dapat diungkapkan. Tujuan aktivitas ini adalah untuk mengetahui ruang lingkup produk (product space) dan pemakai yang akan menggunakannya. Analisis yang baik akan mengungkapkan hal-hal yang penting dari permasalahan, dan mengabaikan yang tidak penting.
Setiap metode analisis mempunyai pandangan yang berbeda. Tetapi pada dasarnya semua metode analisis memiliki prinsip analisis yang sama, yaitu :
1. Menggambarkan domain informasi masalah
2. Mendefinisikan fungsi perangkat lunak
3. Menghasilkan model yang menggambarkan informasi, fungsi dan kelakuan yang dibagi secara rinci pada sebuah model lapisan (hirarki)
4. Informasi pokok pada tahap analisis memudahkan tahap implementasi yang lebih rinci.
Tujuan tahap analisis adalah :
1. Menjabarkan kebutuhan pemakai
2. Meletakkan dasar-dasar untuk tahap perancangan perangkat lunak
3. Mendefinisikan semua kebutuhan pemakai sesuai dengan lingkup kontrak yang disepakati kedua belah pihak (pengembang dan pengguna).

4.1. Apa yang Disebut Kebutuhan (Requirement)
Pengertian Kebutuhan
Menurut arti kamus, kebutuhan adalah sesuatu yang diminta, sesuatu yang dibutuhkan. Sedangkan menurut IEEE (The Institute of Electrical and Electronics Engineers) kebutuhan adalah :
• Kondisi atau kemampuan yang diperlukan pemakai untuk menyelesaikan suatu persoalan, atau untuk mencapai sebuah objek.
• Kondisi atau kemampuan yang harus dipenuhi oleh sistem, dalam arti memenuhi kontrak, standar, spesifikasi atau dokumen formal lain yang diinginkan.

Tahap kebutuhan akan perangkat lunak dimulai dengan :
1. Dikenalinya adanya sebuah permasalahan yang membutuhkan sebuah penyelesaian. Identifikasi sebuah permasalahan mungkin dapat dilakukan dengan berorientasi pada aplikasi, berorientasi pada bisnis, atau berorientasi pada kenaikan produktivitas (product improvement oriented).
2. Munculnya ide untuk membuat sebuah perangkat lunak baru (sebagai sebuah kemajuan).

Modul Rekayasa Perangkat Lunak Halaman 17 dari 64

Ada dua jenis kebutuhan :
1. Behavioral
• apa yang dilakukan oleh sistem (input dan output dari dan ke sistem).
• hubungan informasi antara input dan output sehingga menghasilkan sebuah fungsi transformasi.
2. Non-behavioral
Mendefinisikan atribut sistem yang terkait untuk membentuk pekerjaan tersebut. Termasuk deskripsi lengkap tentang efisiensi, keamanan (security), rehability maintenability (bagaimana perawatan untuk sistem), dan portability (bisa dipindahkan dari satu perangkat keras ke perangkat keras lainnya).

Mengapa Kebutuhan Penting ?
Perhatikan gambar dampak kumulatif berikut ini :

Requirements spesifications Correct spesification Erroneous Spesification Design Correct design Erroneous design Design based on erroneous spesification Implementation Correct programs Programing errors Programs based on erroneous design Programs based on erroneous spesification Testing correct functions coretable errors uncoretable errors hidden error The real problemImperfect program product
Gambar 4.1. Dampak Kesalahan Kumulatif
Mencari kesalahan diakhir siklus hidup pengembangan perangkat lunak ternyata akan banyak mengeluarkan uang.
Modul Rekayasa Perangkat Lunak Halaman 18 dari 64

• Jika dapat dideteksi, dilakukan perbaikan pada setiap tahap proses.
• Jika tidak dapat dideteksi, kesalahan baru kelihatan setelah produk selesai dibuat.

4.2. Tahap Analisis Kebutuhan Perangkat Lunak
Tahap pekerjaan analisis kebutuhan perangkat lunak pada dasarnya terdiri dari urutan aktivitas :
1. Menentukan kebutuhan (requirement)
Lebih banyak berhubungan dengan pemakai. Hasil belum terstruktur.
• Data atau informasi apa yang akan diproses
• Fungsi apa yang diinginkan
• Kelakuan sistem apa yang diharapkan
• Antarmuka apa yang tersedia (user interfaces, hardware interfaces, software interface, dan communications interfaces)
2. Sintesis
Mengubah kebutuhan yang belum terstruktur menjadi model atau gambar dengan memanfaatkan teknik dan metodeanalisis tertentu.
3. Membuat dokumen Software Requirements Spesification (SRS).
Sudah merupakan analisis yang lebih rinci, sebagai tahap awal perancangan.

4.3. Metode Analisis
Metode atau teknik untuk melakukan analisis kebutuhan perangkat lunak dikelompokkan berdasarkan pendekatan yang diambil pada saat melakukan aktivitas tersebut.
1. Berorientasi Aliran Data (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 proses-proses apa saja yang ada dalam sistem, data apa yang menjadi masukannya, dimana data tersebut disimpan, transformasi apa yang akan dilakukan terhadap data tersebuat, 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 Tom DeMarco, Chris Gane dan Trish Sarson, dan Edward Yourdon . Pada metode ini, hasil analisis dan perancangan dimodelkan dengan menggunakan beberapa perangkat permodelan seperti :
• Data Flow Diagram (DFD) dan Kamus Data (data dictionary) untuk menggambarkan fungsi-fungsi dari sistem.
• Entity-Relationship Diagram (ERD) untuk menggambarkan data yang disimpan (data storage).
• State Transition Diagram (STD) untuk menggambarkan perilaku sistem.
• Structure Chart untuk menggambarkan struktur program
2. Berorientasi Struktur Data
Analisis 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 :

Modul Rekayasa Perangkat Lunak Halaman 19 dari 64

• 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 rancangannya.
• Jackson Sistem Development (JSD)
Dikembangkan oleh M.A. Jackson [1975] dengan menggunakan perangkat permodelan yang disebut strukture diagram dan sistem spesification diagram.
3. Berorientasi objek
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 :
• Object Oriented Analysis (OOA) dan Object Oriented Design (OOD) dari Peter Coad dan Edward Yourdon [1990].
• Object Modelling Technique (OMT) dari James Rumbaugh [1987].
• Object Oriented Software Engineering (OOSE)

4.4. Analisis Berorientasi Aliran Data
Pendekatan dari sisi bisnis (DeMarco, Yourdan dan Senn). Analisis aliran data adalah analisis yang dilakukan untuk mempelajari pemanfaatan data pada setiap aktifitas. Menampilkan hasil pengamatan dalam apa yang disebut Data Flow Diagram (DFD) atau Diagram Alir Data (DAD).
4.4.1. Diagram Aliran Data (Data Flow Diagram)
Pengertian
• Suatu tampilan grafis yang memunculkan relasi/hubungan antara proses dan data berserta kamus data yang menjelaskan rincian data yang dipergunakan
• Diagram untuk menggambarkan aliran data dalam sistem, sumber dan tujuan data, proses yang mengolah data tersebut, dan tempat penyimpanan datanya.
• Representasi jaringan dari sistem yang menggambarkan sistem berdasarkan komponen-komponennya dengan semua antar muka diantara komponen-komponen tersebut.
• Perangkat permodelan yang dapat menggambarkan sistem sebagai sebuah jaringan proses-proses fungsional yang satu dengan yang lainnya dihubungkan oleh “pipa saluran” data.
• Diagram yang merepresentasikan bagaimana informasi keluar masuk dari ke sistem, proses apa yang mengubah informasi tersebut dan dimana informasi disimpan.
• Diperkenalkan oleh Tom DeMarco serta Chris Gane dan Trish Sarson berdasarkan notasi SADT (Structure Analysis dan Design Technique).
• Merupakan salah satu teknik yang cukup penting dalam menganalisa sistem karena :
􀂾Dapat mendefinisikan batasan sistem.
􀂾Membantu memeriksa kebenaran dan kelengkapan aliran informasi.

Modul Rekayasa Perangkat Lunak Halaman 20 dari 64

􀂾Merupakan dasar perancangan dengan memunculkan proses-proses pengolahan data.
• Dapat digunakan untuk menggambarkan aktivitas proses secara paralel (beberapa aliran data dapat terjadi secara simultan). Bandingkan dengan flowmap yang hanya dapat menggambarkan aliran data (dokumen) secara serial.

Elemen-elemen DFD
Ada empat elemen yang membentuk suatu Data Flow Diagram, yaitu :
1. Aliran Data (Data Flow)
• Pipa saluran dimana paket informasi yang diketahui komposisinya mengalir.
• Penghubung antar proses yang merepresentasikan informasi yang dibutuhkan proses sebagai masukan atau informasi yang dihasilkan proses sebagai keluaran.
• Aliran paket informasi dari satu bagian sistem ke bagian sistem lainnya.
• Umumnya mengalir antar proses, tetapi dapat juga mengalir keluar masuk dari ke file (data store) atau dari ke sumber tujuan data.
• Data yang dinyatakan dengan aliran data boleh datang dari beberapa dokumen, jadi tidak perlu dirinci menjadi dokumen-dokumen tersebut.
• Diberi nama sesuai dengan substansi isi dari paket informasi (bukan nama dokumen) yang mengalir.
• Jumlah aliran data yang masuk dan keluar proses harus sama

2. Proses
• Transformasi aliran data yang datang menjadi aliran data yang keluar.
• Transformasi bagaimana satu atau beberapa masukan diubah menjadi keluaran.
• Menjelaskan proses-proses transformasi data apa saja yang ada dalam sistem atau yang harus dikerjakan oleh sistem. Komponen-komponen fisik tidak dapat diidentifikasikan sebagai proses.
• Diberi nama dan nomor yang akan dipergunakan untuk keperluan identifikasi. Nama yang diberikan harus dapat menjelaskan apa yang dilakukan oleh proses. Nama proses baisanya ditulis dalam kata kerja.

3. Penyimpanan Data (Data Store)
• Tempat penyimpanan data atau tempat data yang dirujuk oleh proses.
• Kumpulan paket data yang harus diingat oleh sistem dalam periode waktu tertentu.
• Pada akhir pembangunan sistem, data store biasanya diimplementasi sebagai file atau basis data.

4. Entitas Eksternal/Terminator/ Source atau Sink
• Menggambarkan entitas yang berinteraksi dengan sistem yang berada diluar ruang lingkup sistem (bukan yang menjalankan sistem tersebut) atau entitas yang berfungsi sebagai producer/consumer dari sistem (sumber atau tujuan data).
• Dapat berupa orang, unit organisasi, komputer eksternal, organisasi eksternal atau sistem lain. Operator yang memasukkan data dalam sistem termasuk entitas internal, karena ia bukan consumer/producer sistem (kecuali untuk ruang lingkup perangkat lunak tertentu).
• Antara terminator tidak boleh berkomunikasi langsung

Modul Rekayasa Perangkat Lunak Halaman 21 dari 64

• Jumlah entitas/terminator yang terkait pada satu level akan muncul dalam jumlah yang sama untuk level lainnya

Berikut adalah tabel yang menunjukkan notasi yang digunakan dalam DFD.
Tabel 4.1. Simbol Data Flow Diagram DEMARCO/YOURDON GANE/SARSON KETERANGAN
Aliran Data
Proses
Entitas Eksternal/
Terminator
Data Store

1
Rekayasa Perangkat Lunak (Software Engineering)
Software Engineering :
Suatu disiplin ilmu yang membahas semua aspek produksi
perangkat lunak, mulai dari tahap awal requirement capturing
(analisa kebutuhan pengguna), specification (menentukan
spesifikasi dari kebutuhan pengguna), design, coding, testing
sampai pemeliharaan sistem setelah digunakan.
Definisi Software Engineering menurut IEEE1 pada projek SWEBOK2
adalah aplikasi sistematik, disiplin, pendekatan kuantitatif untuk
pengembangan, operasi dan pemeliharaan dari software; dapat
disimpulkan sebagai teknik aplikasi untuk perangkat lunak.
Latar belakang munculnya software engineering ketika adanya
krisis software di era tahun 1960-an. Krisis tersebut akibat dari
lahirnya komputer generasi ke III yang ditandai dengan
penggunaan IC (Integrated Circuit).
Kemampuan hardware yang meningkat, membuat adanya
kebutuhan untuk memproduksi software yang lebih baik. Akibatnya
software yang dihasilkan menjadi menjadi beberapa kali lebih besar
dan kompleks.
Pendekatan informal yang digunakan dalam pengembangan
perangkat lunak pada saat itu, menjadi tidak cukup efektif (secara
biaya, waktu dan kualitas). Biaya hardware mulai jatuh dan biaya
perangkat lunak menjadi naik cepat. Oleh karena itu muncul
pemikiran untuk menggunakan pendekatan yang lebih efektif,
standard dan terukur dalam mengembangan perangkat lunak.
Krisis software adalah sekumpulan masalah yang ditemukan dalam
pengembangan software komputer. Masalahnya tidak hanya
terbatas pada software yang tidak berfungsi sebagaimana
mestinya, tetapi krisis software ini terdiri dari masalah yang
berhubungan dengan :
a. Bagaimana mengembangkan software.
b. Bagaimana memelihara software yang ada, yang berkembang
dalam jumlah besar.
c. Bagaimana mengimbangi permintaan software yang makin
besar.
1) IEEE (Institute of Electrical and Electronics Engineers)
2) SWEBOK (Software Engineering Body of Knowledge)
2
Krisis software dipicu oleh beberapa masalah :
a. Estimasi jadwal dan biaya yang seringkali tidak tepat.
b. Produktivitas pembuat software yang tidak dapat mengimbangi
permintaan software.
c. Kualitas software yang kurang baik.
Beberapa mitos software
Mitos management
• Kita tidak perlu mengubah pendekatan terhadap pengembangan
software, karena jenis pemrograman yang kita lakukan sekarang
ini sudah kita lakukan 10 tahun yang lalu.
Realita : Walau hasil program sama, produktivitas dan kualitas
software harus ditingkatkan dengan menggunakan pendekatan
software developments.
• Kita sudah mempunyai buku yang berisi standarisasi dan
prosedur untuk pembentukan software.
Realita : Memang buku tersebut ada, tetapi apakah buku tersebut
sudah dibaca atau buku tersebut sudah ketinggalan jaman (out of
date).
• Jika kita tertinggal dari jadwal yang ditetapkan, kita menambah
beberapa programmer saja. Konsep ini sering disebut Mongolian
harde concept.
Mitos customer
• Pernyataan tujuan umum sudah cukup untuk memulai penulisan
program. Penjelasan yang lebih rinci akan menyusul kemudian.
Realita : Definisi awal yang buruk adalah penyebab utama
kegagalan terhadap usaha-usaha pembentukkan software.
Penjelasan yang formal dan terinci tentang informasi fungsi
performance interface, hambatan desain dan kriteria validasi
adalah penting.
• Kebutuhan proyek yang terus menerus berubah dapat dengan
mudah diatasi karena software itu bersifat fleksibel.
Realita : Jika perubahan mendekati akhir penyelesaian, maka
biaya akan lebih besar.
3
Mitos Praktisi
• Tidak ada metode untuk analisis disain dan testing terhadap
suatu pekerjaan, cukup menuju ke depan terminal dan mulai
coding.
Realita : Metode untuk analisis desain dan testing diperlukan
dalam pengembangan software.
• Segera setelah software digunakan, pemeliharaan dapat
diminimalisasikan dan diatasi.
Realita : Diperlukan budget yang besar dalam maintenance
software. Pemeliharaan software harus diorganisir, direncanakan
dan dikontrol seolah-olah sebagai suatu proyek besar dalam
sebuah organisasi.
Secara umum karakteristik software :
1. Software merupakan elemen sistem logik dan bukan elemen
sistem fisik seperti hardware
2. Elemen itu tidak aus, tetapi bisa rusak.
3. Elemen software itu direkayasa atau dikembangkan dan bukan
dibuat di pabrik seperti hardware
Evolusi Perangkat Lunak
Tahun-tahun pertama :
• Batch Orientation
Suatu orientasi dimana proses dilakukan setelah data
dikumpulkan dalam satuan waktu tertentu, atau proses dilakukan
setelah data terkumpul, kebalikan dari batch adalah online atau
Interactive Process. Keuntungan dari Interactive adalah
mendapatkan data yang selalu up to date.
• Limmited distribution
Suatu penyebaran software yang terbatas pada perusahaanperusahaan
tertentu.
• Custom software
Software yang dikembangkan berdasarkan perusahaanperusahaan
tertentu.
4
Era kedua :
• Multi user
Suatu sistem dimana satu komputer digunakan oleh beberapa
user pada saat yang sama.
• Real Time
Suatu sistem yang dapat mengumpulkan, menganalisa dan
mentransformasikan data dari berbagai sumber, mengontrol
proses dan menghasilkan output dalam mili second.
• Database
Perkembangan yang pesat dari alat penyimpan data yang online
menyebabkan muncul generasi pertama DBMS.
• Product Software
Software dikembangkan untuk dijual kepada masyarakat luas.
Era ketiga :
• Distributed system
Suatu sistem yang tidak hanya dipusatkan pada komputer induk,
daerah atau bidang lainnya yang juga memiliki komputer yang
ukurannya lebih kecil dari komputer induk.
• Embedded Intelegence
Suatu product yang diberi tambahan “Intellegence” dan biasanya
ditambahkan mikroprocessor yang mutakhir. Contohnya adalah
automobil, robot, peralatan diagnostic serum darah.
• Low Cost Hardware
Harga hardware yang semakin rendah, ini dimungkinkan karena
munculnya Personal Computer.
• Consummer Impact
Adanya perkembangan komputer yang murah menyebabkan
banyaknya software yang dikembangkan, software ini memberi
dampak yang besar terhadap masyarakat.
Era keempat :
• Expert system
Suatu penerapan A.I. (Artificial Intellegence) pada bidang-bidang
tertentu, misalnya bidang kedokteran, komunikasi, dll.
• AI Machine
Suatu mesin yang dapat meniru kerja dari sebagian otak
manusia. Misalnya mesin robot, komputer catur.
• Parallel Architecture
Arsitektur komputer yang memungkinkan proses kerja LAN
paralel, yang dimungkinkan adanya prosesor berbeda dalam satu
komputer
5
Dalam membuat software, secara umum ada beberapa fase :
Fase Perencanaan (Planning) :
a. Rencana software
b. Analisa kebutuhan software
c. Analisa cost banefit (Salah satu bagian dari studi kelayakan)
Fase Pengembangan (Development) :
a. Coding
b. Testing
Macam-macam test program :
• Unit test (Test per modul)
• Integreated test (Test penggabungan dari modul-modul yang
telah diuji)
• Validated test (Diuji dengan data sebenarnya)
• System test (Test dilakukan dengan lingkungan sebenarnya)
• Topdown test (Test gabungan dari atas ke bawah)
• Bottom up test (Test gabungan dari bawah ke atas)
Fase Pemeliharaan (Maintenance) :
Jenis-jenis maintenance
a. Koreksi (Corection)
b. Adaptasi (Adaptive)
Adaptasi yang berkembang pada dewasa ini terbagi atas :
• Sistem Operasi
• RDBMS (Relational DataBase Management System)
• Bahasa
• Mengarah pada perkembangan bahasa generasi ke empat
(Fourth Generation Language)
• Perfective
Menyempurnakan software yang biasanya dilakukan karena
permintaan atau saran atau kritik user
Aplikasi perangkat lunak
• System software
Adalah sekumpulan program yang ditulis untuk melayani atau
menunjang program lainnya. Beberapa sistem software seperti
compiler, editor, komponen-komponen sistem operasi, driver dan
prosesor telekomunikasi.
• Real-time software
Software yang mengukur, menganalisis dan mengontrol kejadian
yang sesungguhnya terjadi di dunia.
6
Elemen-elemen real time software terdiri dari :
a. Komponen pengumpulan data
Yang mengumpulkan dan menyusun informasi dari lingkungan
external
b. Komponen analisis
Yang mentransformasikan informasi yang diperlukan oleh
aplikasi
c. Komponen kontrol
Yang memberikan respon kepada lingkungan external
d. Komponen monitor
Yang mengkoordinasi semua komponen-komponen lainnya,
sehingga respons real time yang berkisar 1 milisecond sampai
1 menit dapat dipertahankan.
Istilah real time berbeda dari istilah interactive atau time
sharing. Sistem real time harus memberikan respons pada
waktu yang ditentukan, sedangkan pada sistem interactive
atau time sharing respons time biasanya melebihi batas waktu
yang ditentukan tanpa merusak hasil.
• Business software
Software ini digunakan oleh manajemen untuk mengambil
keputusan dalam bidang bisnis.
Contohnya DEA (DAC EASY ACCOUNTING)
• Engineering and scientific software
Software yang dicirikan dengan algoritma numerik, aplikasinya
berkisar dari astronomi sampai vulkanologi, dari analis
ketegangan otomotif sampai dinamika orbit ruang angkasa.
Software ini banyak digunakan dalam bidang engineering dan
science.
Contohnya CAD dan CAM
• Embedded software
Suatu software disimpan dalam memori tetap – ROM – Read Only
Memory, dan digunakan untuk mengontrol product dan sistem
software ini dijalankan dengan berbagai fungsi terbatas.
• Personal computer software
Software yang banyak digunakan di komputer pribadi.
• Artificial intelligence software
Software yang banyak menggunakan algoritma non numerik
dalam memecahkan masalah kompleks yang tidak dapat
dianalisis dengan analisis komputasi biasa.
7
KUALITAS SOFTWARE: IS01 9126
Karakteristik Sub karakteristik
Functionality : Software untuk
menjalankan fungsinya sebagaimana
kebutuhan sistemnya
Suitability, Accuracy,
Interoperability,Security
Reliability : Kemampuan software
untuk dapat tetap tampil sesuai
dengan fungsinya ketika digunakan
Maturity, Fault tolerance,
Recoverability
Usability : Kemampuan software
untuk mudah dimengerti, dipelajari,
digunakan dan disukai pengguna
Understandability,
Learnability, Operability,
Attractiveness
Efficiency : Kemampuan software
untuk menampilkan performans
relatif terhadap penggunaan
sumberdaya
Time Behavior, Resource
Utilization
Maintainability : Kemampuan
software untuk dimodifikasi
(koreksi,adaptasi,perbaikan)
Analyzability, Changeability,
Stability, Testability
Portability : Kemampuan software
untuk ditransfer dari satu lingkungan
ke lingkungan lain
Adaptability, Installability
1) ISO (International Organization for Standardization)

1
Konsep dan Prinsip Desain
Tujuannya adalah untuk menghasilkan suatu model atau representasi dari
entitas yang kemudian akan dibangun.
Desain Perangkat Lunak dan Rekayasa Perangkat Lunak
Fase pengembangan terdiri dari tiga langkah yaitu design, code generation
(manual or automatic) dan testing.
Setiap langkah melakukan transformasi informasi dengan suatu cara yang
akhirnya menghasilkan software komputer yang valid.
Software Requirements
Dijelaskan dengan information domain, functional and performance
requirments, dan feed the design step.
Dengan menggunakan satu dari sejumlah metode desain, langkah desain
menghasilkan :
a. Desain data (difokuskan pada definisi dari struktur data)
b. Desain arsitektur (mendefinisikan hubungan antara elemen struktur utama
dari program)
c. Desain interface
d. Desain prosedural (mengubah struktur elemen kedalam prosedur
software)
Selama desain, kita dapat membuat keputusan yang akan mempengaruhi
kesuksesan konstruksi software dan kemudahan maintenance-nya. Desain
sangat penting karena dapat menentukan kualitas dari suatu software.
Proses Desain
Software design dibagi dalam 2 tahap :
1. Preliminary Design, Pada tahap ini difokuskan dengan transformasi dari
keperluan/kebutuhan ke dalam data dan arsitektur software
2. Detail Design, Difokuskan pada penghalusan representasi arsitektur yang
berisi struktur data detail dan algoritma untuk software
Agar dihasilkan desain dengan kriteria yang baik, maka suatu desain
haruslah :
1. Memperlihatkan organisasi hirarki yang mengontrol elemen-elemen
software
2. Berkenaan dengan modul. Software secara logika terbagi dalam elemenelemen
yang membentuk fungsi dan sub fungsi
3. Berisi representasi yang berbeda dan terpisah dari data dan prosedur
4. Membentuk modul (contoh subroutine dan procedure) yang
memperlihatkan karakteristik fungsi yang tidak saling bergantung
5. Diturunkan dengan menggunakan metode perulangan yang didukung oleh
informasi yang ada selama analisa kebutuhan software
2
Evolusi Desain Software
Merupakan suatu proses kontinu yang terus berlangsung selama tiga
dekade. Beberapa metodologi telah tumbuh, dan secara umum memiliki
karakteristik sebagai berikut :
a. Mekanisme penerjemahan suatu model analisis ke dalam representasi
desain.
b. Notasi untuk merepresentasikan komponen-komponen fungsional dan
interface-nya.
c. Heuristik bagi penyaringan dan partisi
d. Pedoman bagi penilaian kualitas
Prinsip desain
Desain perangkat lunak berupa model dan proses. Proses desain adalah
serangkaian langkah iteratif yang memungkinkan desainer menggambarkan
semua aspek perangkat lunak yang dibangun. Model desain adalah ekivalen
rencana arsitek untuk sebuah “rumah”, yang dimulai dengan menyajikan
totalitas dari hal yang akan dibangun.
Konsep-konsep desain
1. Abstraksi
Jika kita menggunakan suatu solusi modular untuk beberapa masalah,
maka beberapa level / tingkat abstrasi dapat ditampilkan / diperlihatkan.
• Pada level tertinggi, suatu solusi berada pada term yang umum dengan
menggunakan bahasa natural
• Level yang lebih rendah lebih berorientasi pada prosedur-prosedur
Contoh :
Abstraksi 1
The software will incorporate a computer graphics interface that will
enable visual communication with the drafts person and a digitizer
interface that replace the drafting board and square. All line and
curve drawing, all geometric computation, and all sectioning and
auxiliary views will be performed by the CAD Comp.
Abstraksi 2
CAD Software tasks :
user interaction task ;
2-D drawing creation task ;
graphics display task ;
drawing file management task ;
end.
Abstraksi 3
procedure : 2-D drawing creation ;
repeat until (drawing creation task terminates)
do while (digitizer interaction occurs)
digitizer interface task ;
determine drawing request case ;
line : line drawing task ;
circle : circle drawing task ;


3
end ;
do while (keyboard interaction occurs)
keyboard interaction task ;
process analysis / computation case ;
view : auxiliary view task ;
section : cross sectioning task ;


end


end repetition ;
end procedure.
2. Penyaringan
Penyaringan stepwise adalah strategi desain top-down yang diusulkan
oleh Wiklaus Wirth.
Kajian dari konsep tersebut adalah “Pada setiap langkah (penyaringan),
satu atau beberapa instruksi dari program yang diberikan didekomposisi
ke dalam instruksi-instruksi yang lebih detail. Dekomposisi berurutan atau
penyaringan spesifikasi berhenti bila semua instruksi diekspresikan dalam
bentuk bahasa pemrograman atau komputer yang mendasar. Jika tugastugas
disaring, maka data harus disaring juga, didekomposisi atau
distruktur, dan adalah wajar untuk menyaring program dan spesifikasi data
secara paralel” .
Abstraksi dan penyaringan adalah konsep kompementer. Kedua konsep
tersebut membantu desainer dalam menciptakan suatu model desain
lengkap jika desain berkembang.
3. Modularitas
Software dibagi ke dalam elemen-elemen terpisah yang dapat dipanggil,
yang disebut dengan modul.
Misalkan :
C(x) : fungsi kompleksitas dari suatu masalah
E(x) : fungsi usaha/waktu yang diperlukan untuk memecahkan suatu
masalah
P1 ,P2 = masalah 1, masalah 2
Jika : C(P1) > C(P2) maka : E(P1) > E(P2)
Berdasarkan penelitian :
1. C ( P1 + P2 ) > C ( P1 ) + C ( P2 )
2. E ( P1 + P2 ) > E ( P1 ) + E ( P2 )
4. Arsitektur perangkat lunak
Arsitektur perangkat lunak menyinggung 2 karakteristik penting dari
sebuah program komputer :
1. Hirarki struktur dari komponen-komponen prosedural ( modul )
2. Struktur data
4
5. Partisi structural
Struktur progam harus dipartisi baik secara horizontal maupun vertikal.
Partisi horizontal menentukan cabang-cabang terpisah dari hirarki modular
untuk setiap fungsi program mayor. Keuntungannya :
a. Menghasilkan perangkat lunak yang lebih mudah diuji.
b. Membawa kepada perangkat lunak yang lebih mudah dipelihara.
c. Menghasilkan penyebaran efek samping yang lebih sedikit.
d. Menghasilkan suatu perangkat lunak yang lebih mudah untuk diperluas.
Partisi vertikal menyatakan bahwa kontrol dan kerja harus didistribusikan
secara top-down dalam arsitektur program.
6. Hirarki Kontrol (Program Structure)
• Program structure menampilkan/menyajikan organisasi (seringkali
organisasi hirarki) dari komponen-komponen program (modul-modul)
dan mengandung arti hirarki dari kontrol program
• Notasi yang digunakan adalah diagram tree. Biasanya dinamakan
structure chart
5
7. Prosedur perangkat lunak
Prosedur perangkat lunak berfokus pada detail-detail pemrosesan dari
masing-masing modul secara individual. Prosedur harus memberikan
spesifikasi yang teliti terhadap pemrosesan, mencakup urutan event, poinpoin
keputusan nyata, operasi repetitif, dan organisasi struktur data.
8. Struktur data
Struktur data adalah representasi dari hubungan logis antara elemenelemen
data individual.
Contoh :
type G = array [1..100] of integer;


Procedure S ( var T : G ; n : integer ; sum : integer );
Var
I : integer;
begin
sum := 0;
for I:=1 to n do
sum := sum + t[i];
end;
9. Penyembunyian informasi
Prinsip penyembunyian informasi menyatakan bahwa modul ditandai
dengan keputusan desain tersembunyi dari semua desain lain.
Contoh :
Black Box : input, output, & proses diketahui tetapi proses detail tidak
diketahui.
Bagi Modul B, Modul C adalah Black Box

Prosiding Konferensi Nasional Teknologi Informasi & Komunikasi untuk Indonesia
3-4 Mei 2006, Aula Barat & Timur Institut Teknologi Bandung
276
VALIDASI PERANGKAT LUNAK DENGAN METODE HYBRID
BERBASIS UML
M.Sukrisno Mardiyanto
sukrisno@informatika.org
Teknik Informatika STEI ITB
ABSTRAK
Kecermatan proses verifikasi dan validasi perangkat lunak merupakan kunci keberhasilan penjaminan mutu
(kualitas) perangkat lunak. Proses validasi model dinamis perangkat lunak sangat menentukan kehandalan
perangkat lunak, karena validasi pada tahapan analisis dan desain akan dapat mengurangi resiko kesalahan yang
fatal pada tahap implementasi. Keberhasilan validasi model dinamis ditentukan oleh kecermatan analisis dengan
dukungan metode formal dan kakas verifikasi dan validasi model perangkat lunak. Arah perkembangan validasi
model perangkat berbasis UML menjadi kajian utama, dimana potensi perpaduan dengan metode formal yang berorientasi
objek (antara lain Object-Oriented Petri Net dan Object Z) berpeluang untuk dikembangkan menjadi
metode formal yang bersifat hybrid.
Kata kunci : Validasi Perangkat Lunak, metode formal, UML, Petri Net, bahasa Z
1. PENDAHULUAN
Dalam pembangunan perangkat lunak, langkah penting
yang mutlak dilakukan dalam rangka menjamin mutu
(kualitas) perangkat lunak adalah proses verifikasi dan
validasi (Verification & Validation) yang dilaksanakan
pada setiap tahapan pembangunan.
Verifikasi dan validasi pada tahap desain (perancangan)
bertujuan untuk mengeliminasi dan menghindari
kesalahan pada sa’at implementasi. Proses validasi model
sistem perangkat lunak pada tahap ini menjadi sangat
penting pada pembangunan perangkat lunak yang
tergolong critical system dan/atau critical mission,
olehkarena kesalahan yang terjadi dapat menimbulkan
bencana dan berakibat fatal. Olehsebab itu proses
verifikasi dan validasi hasil desain perangkat lunak
menjadi sangat penting.
Pemodelan sistem perangkat lunak pada tahap desain
direpresentasikan dalam bentuk model statis dan model
dinamis. Model statis menggambarkan arsitektur sistem
perangkat lunak, berupa struktur kendali modul-modul
perangkat lunak dan model pemrosesan dalam setiap
model. Sedangkan model dinamis lebih menggambarkan
model kelakuan sistem (system behavior) termasuk
interaksi dengan pengguna dan lingkungannya.
Proses validasi model dinamis membutuhkan tingkat
ketelitian dan kepastian yang tinggi dalam menghindari
kesalahan desain. Untuk itu perlu dukungan kakas (tools)
yang mampu menganalisis kemungkinan kesalahan dan
menguji hasil desain secara cermat. Beberapa metode
desain (design methods) dan kakas analisis
(analysis tools) telah dikembangkan dan digunakan
dalam proses validasi model dinamis.
Dalam makalah ini permasalahan penggunaan
merode pembangunan perangkat lunak akan
dibatasi pada metode analisis dan desain berorientasi
objek berbasis UML (Unified Modeling
Language). Sedangkan pembahasan kakas analisis
untuk validasi model dinamis bertumpu pada
kemampuan analisis yang dimiliki oleh Petri Net
dan bahasa formal Z (dan/atau sejenisnya).
Dengan penggabungan kemampuan dari Petri Net
dan bahasa formal Z (dan sejenisnya) diperoleh
suatu metode validasi Hybrid yang diharapkan
berkemampuan analisis yang lebih baik dan dapat
menjawab kebutuhan kakas validasi perangkat
lunak yang handal. Di samping itu dengan adanya
upaya pembakuan notasi dan format dari Petri Net
serta bahasa formal yang sejenis akan
memudahkan interkoneksi dan interoperasi antar
kakas verifikasi dan validasi perangkat lunak.
2. VERIFIKASI DAN VALIDASI
PERANGKAT LUNAK DAN
PERMASALAHANNYA
2.1 Verifikasi dan Validasi Perangkat Lunak.
Prosiding Konferensi Nasional Teknologi Informasi & Komunikasi untuk Indonesia
3-4 Mei 2006, Aula Barat & Timur Institut Teknologi Bandung
277
Ada perbedaan makna yang mendasar dalam pemahaman
tentang proses verifikasi dan validasi seperti
diekspresikan dalam pertanyaan berikut :
– Verification : Are we building the product right ?
– Validation : Are we building the right product ?
Arti verifikasi dalam hal ini lebih ditekankan pada
kebenaran pelaksanaan proses pembangunan perangkat
lunak, sedangkan validasi lebih ke arah pembuktian
bahwa perangkat lunak yang dibangun sudah benar
(correct).
Dalam industri perangkat lunak, proses validasi dapat
dilakukan sepanjang langkah pembangunan perangkat
lunak, mulai dari tahapan analisis sampai dengan tahapan
implementasi (coding & testing). Dalam makalah ini
permasalahan yang dibahas difokuskan ke masalah
validasi perangkat lunak pada tahapan desain
(perancangan).
2.2 Metode Formal untuk Validasi Perangkat
Lunak
Proses validasi perangkat lunak pada tahapan desain lebih
sulit dilakukan dibandingkan dengan proses validasi pada
tahapan implementasi yang dilakukan dalam tahap
ujicoba perangkat lunak (software testing). Hal ini
diakibatkan oleh adanya tingkat abstraksi yang lebih
tinggi dalam pemodelan perangkat lunak pada hasil
desain.
Olehsebab itu proses validasi pada tahapan ini
membutuhkan alat bantu (kakas) yang mampu
mendukung pelaksanaan validasi secara cermat, yakni
berupa metode formal (formal methods).
Metode formal tersebut umumnya dilengkapi :
a. Notasi matematis dalam bentuk tekstual, grafis atau
tabular.
b. Proses yang mendeskripsikan bagaimana membuat
artifak perangkat lunak (software artifact) berupa :
spesifikasi perangkat lunak, desain perangkat lunak,
program, dan sebagainya.
c. Kakas untuk memeriksa dan membuktikan kebenaran
artifak perangkat lunak tersebut secara formal.
Secara umum metode formal diklasifikasikan berdasarkan
spesikasi bahasa formal, teknik verifikasi dan teknik
validasi yang diterapkan. Dalam praktek validasi dikenal
2 kelas bahasa spesifikasi formal, yakni:
(1). Model-based specification language, dimana model
sistem dibuat berdasarkan konstruksi matematis
seperti kumpulan (sets) dan urutan (sequences) ,
sedangkan pengoperasian sistem dinyatakan dalam
bentuk perubahan status dari sistem. Bahasa formal
yang termasuk kelas ini adalah : CSP, Petri
Net dan bahasa Z.
(2). Algebra-based specification language, dimana
sistem dinyatakan dalam terminologi operasi
dan hubungan antar operasi tersebut. Yang
termasuk kelas ini adalah bahasa Larch dan
Lotos.
Tabel 2.1 di bawah ini memperlihatkan peta
klasifikasi bahasa spesifikasi formal tersebut [14].
TABEL 2.1. Klasifikasi Bahasa Spesifikasi Formal
Jenis Bahasa Jenis Proses
Spesifikasi Sekuensial Konkuren
Model-based Z, VDM, B CSP, Petri Net
Algebra-based Larch, OBJ Lotos
Dalam perkembangan metodologi pembangunan
perangkat lunak ber-orientasi objek terjadi
konvergensi dalam penggunaan metode formal
yang mengarah ke Unified Modeling Language
(UML) sebagai standar pemodelan perangkat lunak.
Demikian pula yang terjadi dengan bahasa formal
lain yang mengkonsiderasi metode ber-orientasi
objek, seperti halnya : Object Petri Net dan bahasa
Object-Z.
2.3 Permasalahan Verifikasi dan validasi
Perangkat Lunak
Permasalahan yang dihadapi dalam melakukan
validasi model dinamis perangkat lunak secara
umum adalah :
a. Keterbatasan model dinamis berbasis diagram
(diagrammatic notation) dalam proses validasi
hasil rancangan (desain) perangkat lunak yang
disebabkan oleh kelemahan semantik notasi
yang digunakan, sehingga tidak mampu
mendeskripsikan kelakuan sistem (system
behavior) yang rumit
b. Kerumitan (kompleksitas) bahasa spesifikasi
formal berbasis aljabar (algebraic) akibat
penggunaan notasi matematis dan format yang
spesifik, sehingga menyulitkan penerapannya.
c. Dalam proses analisis model perangkat lunak,
kemungkinan adanya jumlah kasus analisis
yang sangat besar akibat ledakan state space
dari model yang dianalisis. Sehingga
diperlukan upaya untuk membatasi atau
menghindari terjadinya hal tersebut.
Guna menanggulangi permasalahan di atas telah
dilakukan analisis lebih mendalam terhadap
pengembangan metode validasi model dinamis
melalui penelitian yang memadukan keunggulan
dari berbagai metode formal ke dalam suatu
metode hybrid. Makalah ini memaparkan arah
Prosiding Konferensi Nasional Teknologi Informasi & Komunikasi untuk Indonesia
3-4 Mei 2006, Aula Barat & Timur Institut Teknologi Bandung
278
strategi perpaduan metode formal tersebut ke bentuk
metode hybrid berbasis UML.
3. VALIDASI MODEL DINAMIS PERANGKAT
LUNAK BERBASIS UML
3.1 Pemodelan dinamis perangkat lunak dengan
UML
UML merupakan kakas analisis dan desain perangkat
lunak yang dikembangkan oleh James Rumbaugh, Grady
Booch dan Ivar Jacobson [6]. Sa’at ini UML secara de
facto sudah menjadi kakas standar dalam metode
pembangunan perangkat lunak ber-orientasi objek. Dalam
hal ini UML dapat diklasifikasikan sebagai metode semiformal.
Model dinamis perangkat lunak dituangkan dalam bentuk
representasi grafis berupa : Diagram status (statechart
diagram), Diagram Interaksi (interaction diagram),
Diagram Kolaborasi (collaboration diagram) dan
Diagram Aktivitas (activity diagram).
Fungsi dari masing-masing diagram dideskripsikan pada
Tabel 3.2.
TABEL 3.2. Deskripsi Diagram dalam UML [6]
Diagram Deskripsi fungsi
Statechart
Diagram
– Specify the sequences of states an object
goes through during its lifetime in response to
events, together with its response to events.
– Models the behavior of a single object.
Interaction
Diagram
Shows an interaction, consisting of a set of
objects and their relationships, including the
messages (or events) that may be dispatched
among them.
Collaboration
Diagram
An interaction diagram that emphasized the
structural organization of the objects that send
and receive messages.
Activity
Diagram
– Depict high-level business process
– Model the logic of complex logic within the
system.
Penerapan diagram-diagram tersebut dalam pemodelan
dinamis secara visual memudahkan pemahaman bagi
pengguna, namun belum sepenuhnya memenuhi syarat
sebagai metode formal, karena :
– Belum dapat memberikan interpretasi / makna yang
pasti dan konsisten,
– Tidak sepenuhnya mampu mendukung validasi model
perangkat lunak secara formal.
Oleh sebab itu UML, yang masih tergolong semi-formal,
perlu dilengkapi dengan deskripsi formal berbentuk notasi
aljabar, guna menghindari kerancuan (ambiguty) yang
mungkin terjadi dalam deskripsi berbasis bahasa alami
(natural language). Sebagai salahsatu bentuk realisasinya
telah dikembangkan Object Constraint Language (OCL)
yang melengkapi model dinamis dan model statis
sehingga UML memiliki semantik yang lebih kuat
[16].
3.2 Metode validasi Model Dinamis berbasis
UML
Validasi model dinamis perangkat lunak yang
menggunakan UML sebagai metode formal
menerapkan salahsatu dari pendekatan berikut :
1. Pemetaan model dinamis UML ke dalam bahasa
deskripsi formal bernotasi diagram, misalnya
General Stochastic Petri Net (GSPN).
2. Penerjemahan (translasi) deskripsi formal UML
ke dalam bahasa spesifikasi formal bernotasi
aljabar, misalnya bahasa Z.
3. Transformasi model dinamis UML ke bentuk
yang executable (misal : xUML, vUML [9]).
Selanjutnya hasil proses pemetaan, penerjemahan
atau transformasi tersebut kemudian dijadikan
masukan dari Model Checker atau Theorem
Prover.
4. VALIDASI PERANGKAT LUNAK
DENGAN METODE HYBRID BERBASIS
UML
Sejumlah penelitian dalam rangka validasi model
dinamis berbasis UML yang dipadukan dengan
berbagai metode formal lain telah dan tengah
dilakukan, antara lain :
a. vUML [9] : merupakan suatu kakas verifikasi
model dinamis dari UML yang
memanfa’atkan kakas analisis SPIN [17]
sebagai model checker. vUML dilengkapi
pula dengan error analyzer yang secara
otomatis akan memperbaiki model yang
divalidasi dan secara simultan memberi
umpan balik bagi pengguna.
b. CO-OPN [7] : adalah sebuah kakas verifikasi
dan validasi model perangkat lunak,
khususnya untuk sistem konkuren, yang
berbasis Petri Net ber-orientasi objek
(Concurrent Object-Oriented Petri Net).
c. ZOOM [18] : merupakan bahasa formal berorientasi
objek dari hasil pengembangan
bahasa Z. ZOOM menyediakan fasilitas
validasi model dinamis, yakni kakas
transformasi (berupa Code Synthetizer) dan
Prosiding Konferensi Nasional Teknologi Informasi & Komunikasi untuk Indonesia
3-4 Mei 2006, Aula Barat & Timur Institut Teknologi Bandung
279
kakas analisis (berupa : theorem prover, static
analyzer dan unit test generator).
Berdasarkan pengkajian berbagai metode validasi model
dinamis perangkat lunak berbasis UML yang telah
dipaparkan di atas, dapat digambarkan arah perpaduan
model yang menggunakan bahasa spesifikasi berbasis
model (model-based specification language) yang
menerapkan notasi diagramatik (diagrammatic notation)
dan notasi aljabar (algebraic notation) seperti
diilustrasikan pada Gambar 4.1.
Metode
Hybrid OO
Object Object
Petri Net Z
vUML
Petri Net Bahasa Z
Mapping Model
dinamis
UML
Translation
OCL
Gambar 4.1 Metode Hybrid berbasis UML
Kekuatan dari bahasa spesifikasi berbasis model yang
menggunakan notasi grafis, seperti halnya Petri Net dan
model dinamis UML, ada pada kemampuannya dalam
pemodelan kelakuan sistem yang bersifat konkuren dan
pemodelan sinkronisasi proses. Sedangkan kekuatan
spesifikasi bahasa formal bernotasi aljabar (algebraic
based), antara lain : bahasa Z dan VDM, terletak pada
kecermatan deskripsi formal dari model perangkat lunak
dan kemampuan analisis matematis dalam pembuktian
kebenaran model. Penggabungan ke dua jenis metode
formal tersebut dapat men-sinergi-kan kekuatannya
melalui validasi model bersilang (model cross validation)
sebagai dasar prinsip kerja model checker dari metode
Hybrid. Sebagai syarat keberhasilan proses cross
validation, dibutuhkan kemampuan interpretasi timbal
balik antara kedua bahasa spesifikasi tersebut.
Selanjutnya metode validasi langsung yang dianut vUML
dapat digunakan sebagai perangkat eksekutor model hasil
validasi (sebagai bagian dari simulasi model dinamis).
Metode Hybrid berbasis UML yang merupakan hasil
perpaduan tersebut diharapkan memiliki keunggulan dan
kehandalan yang lebih baik dibanding jika masingmasing
metode formal diterapkan terpisah.
5. PENUTUP
Kajian terhadap peluang perpaduan dari beberapa
metode formal berbasis model dan ber-orientasi
objek bertujuan untuk meningkatkan kemampuan
analisis model dinamis perangkat lunak yang
berbasis UML melalui sinergi kekuatan analisisnya.
Untuk mendukung realisasi metode Hybrid tersebut
perlu dikembangkan kakas validasi model dinamis
perangkat lunak yang dapat menangani analisis
model dengan representasi diagramatik dan/atau
representasi dalam notasi aljabar, serta
berkemampuan validasi secara timbal balik ( model
cross validation).
Dalam penelitian selanjutnya metode formal
berbasis model Concurrent Object-oriented Petri Net
dan Object-Z dipilih sebagai kasus kajian lebih
lanjut dalam mengembangkan metode Hybrid
berbasis UML.
6. REFERENSI
[1] Abrial, J.R., “B-Tool Reference Manual”,
version 1.1, 1997
[2] Arcoverde, Adilson, et al., “Petri Nets tools
integration through Eclipse”,–,
[3] Back, Ralph-Johan, et al., “Formalizing UML
Uses Cases in the Refinement Calculus”, TUC
Technical Report no.279, Turku Center for
Computer Science, Finland, May 1999.
[4] Bause, Falko, et al., “Abstract Petri Net
Notation”, –,1994
[5] Bjorner, Dines, et al., “UML-ising” Formal
Techniques, Third INT Workshop, Barcelona,
March 2004.
[6] Booch, G.,Jacobson, Ivar, Rumbaugh, James,
“The Unified Modeling Language User Guide”,
Addison Wesley, 1999.
[7] Buch, Didier, “Concurrent Object-Oriented
Petri Nets”, —,
[8] Gogolla, Martin, “Benefits and Problems of
Formal Methods”, –, 2003.
[9] Lillius, Johan, Paltor, Ivan Porres,” vUML : A
tool for verifying UML Models”, TUCS Technical
report no.272, may 1999.
[10]Merseguer, Jose, et al., “A Compositional
semantics for UML state machine aimed at
performance evaluation”, —, 2002.
Prosiding Konferensi Nasional Teknologi Informasi & Komunikasi untuk Indonesia
3-4 Mei 2006, Aula Barat & Timur Institut Teknologi Bandung
280
[11] Saldhana, John Anil, et al., “Formalizing of Object
Behavior and Interactions from UML Models”, –, 2000.
[12] Silva, Jose Reinaldo, dos Santos, Eston A.,
“Applying Petri Nets to Requirement Validation”,
Proceeding of COBEM 2003, 17th International Congress
of Mechanical Engineering, Sao Paulo, November 2003.
[13] Sheldon, Frederick, “A Review of Some Rigorous
Software design and Analysis Tools”, Sofware Focus,
vol.4, no.2, John Wiley & Sons, 2002.
[14] Sommerville, Ian, “Software Engineering”, 7th
edition, Addison Wesley, 2004
[15] Soon-Kyeong,K., Carrington,D., “Formalizing UML
Class diagram using Object-Z”, Proceeding of 2nd
International Conference of the UML : Beyond the
standard”, LNCS, Springer, 1999.
[16] –, “Object Constraint Language Specification”,
version 1.1, September 1997.
[17] SpinRoot, The Model Checker SPIN,
http://spinroot.com/spin.html , February 20, 2006
[18] ZOOM Project, “Z-based Object Oriented
Modeling”, http://se.cs.depaul.edu/ise/zoom/zoom.html,
March 29, 2006.

1
Pembuatan Perangkat Lunak untuk Menentukan Panjang Gelombang
Berdasarkan Spektrum Cahaya Tampak dengan Metode Jaringan Syaraf
Tiruan Menggunakan Matlab 7.0
Oleh:
Fahmi Ardi1), Jatmiko Endro Suseno, S.Si, M.Si 2), Drs. K Sofyan Firdausi 3)
1), 2), 3). Jurusan Fisika Undip
INTISARI
Telah dibuat program jaringan syaraf tiruan untuk menentukan panjang
gelombang pada spektrum cahaya tampak menggunakan metode backpropagation
dengan algoritma Levenberg Marquardt. Bahasa pemrograman yang digunakan
adalah MATLAB versi 7.0.
Jaringan syaraf tiruan ini memilki satu buah lapisan tersembunyi. Sebelum
digunakan, program harus dilatih terlebih dahulu. Data pelatihan dan data uji
berupa nilai warna dasar RGB beserta nilai panjang gelombangnya. Proses
pelatihan jaringan syaraf tiruan dilakukan dengan mengenalkan pola input dan
target pada jaringan. Jumlah iterasi yang dibutuhkan pada proses pelatihan
dipengaruhi oleh penentuan nilai parameter-parameter pelatihan (jumlah neuron
pada lapisan tersembunyi, target error, mu, mu_dec dan mu_inc). Proses pelatihan
terdiri dari perambatan maju (feedforward) dan perambatan mundur
(backpropagation), selama proses pelatihan nilai bobot dan bias pada tiap lapisan
diperbaiki hingga harga target error yang diinginkan tercapai.
ABSTRACT
Neural network program for determined wavelength in visible spectrum has
been made using back propagation method with levenberg Marquardt algorithm.
The programming language which is used is MATLAB 7.0.
This neural network has a single hidden layer. Before used, program must
have been training. Training and testing data are value of primary color RGB with
its wavelength. Neural network training process is done by introducing input and
target pattern into network. Required epoch along training process is determined by
the value of training parameters (number of hidden layer’s neuron, error, mu,
mu_dec and, mu_inc). Training process was separated to be feed forward and back
propagation phase, all values of weights and biases had been fixed during training
process until error or maximum epoch value were met.
Neural network program has been successful to identify connection pattern
from value of primary color RGB and value of wavelength. This neural network
program will produce effective training process if used 30 neuron in hidden layer’s
with additional parameter (mu=10 5 , mu_dec=0.1, and mu_inc=10). Accuracy
neural network to identify wavelength’s value for each input colors is determined by
the value of error. The level of acuracy in error 10-8 is 100% for data after training
(data1) and 97.11% for data never been training (data2).
2
Program jaringan syaraf tiruan telah berhasil mengenali pola hubungan
antara nilai warna dasar RGB dan nilai panjang gelombang. Program jaringan
syaraf tiruan ini akan menghasilkan proses pelatihan secara efektif jika
menggunakan 30 buah neuron pada lapisan tersembunyi dengan parameter
tambahan (mu=10 5 , mu_dec=0.1, dan mu_inc=10). Keakuratan jaringan syaraf
tiruan dalam mengenali nilai panjang gelombang untuk tiap masukan warna
ditentukan oleh besarnya harga target error. Tingkat keakuratan pada target error
10-8 adalah 100% untuk data yang dilatih (data1) dan 97.11% untuk data yang
tidak dilatih (data2).
PENDAHULUAN
Sekarang ini teknologi telah
berkembang dengan pesat. Begitu pula
dalam penelitian mengenai cahaya,
instrumen optik yang digunakan dalam
penelitian juga semakin canggih. Banyaknya
perangkat yang dapat digunakan dalam
penelitian memudahkan kita dalam
mengamati perilaku cahaya, khususnya
cahaya sebagai gelombang. Salah satu
contoh penelitian mengenai optik adalah
penentuan panjang gelombang spektrum
cahaya tampak.
Penentuan panjang gelombang
sangat penting fungsinya, yaitu untuk
mengetahui sifat dan karakteristik dari
gelombang itu sendiri. Pada spektrum
gelombang elektromagnetik, telah
dikelompokkan menjadi beberapa bagian
sesuai dengan jenis dan sifatnya. Daerah
spektrum cahaya tampak merupakan daerah
sempit antara sinar inframerah dan
ultraviolet dengan nilai interval panjang
gelombang (380-780) nm. Pada daerah ini
cahaya dapat ditangkap oleh mata manusia
dan direpresentasikan dalam bentuk warna
(Anonim,2006).
Selama ini yang kita ketahui
penentuan panjang gelombang cahaya
tampak dilakukan secara manual yaitu
dengan menggunakan sumber cahaya putih
dan sebuah prisma. Cahaya putih tersebut
akan terurai sesuai sudut yang dibentuk oleh
prisma menjadi beberapa cahaya
monokromatik sehingga bisa diperoleh nilai
panjang gelombang dari tiap warna
(Rusydi,2006). Apabila setiap sudut pada
prisma kita variasi nilainya, maka akan
menghasilkan susunan pola warna yang
memiliki nilai interval panjang gelombang
antara (380-780) nm.
Seiring dengan berkembangnya
teknologi, adanya pembuatan perangkat
lunak pada komputer semakin
mempermudah pengguna dalam menentukan
panjang gelombang pada warna. Pada proses
pembuatan perangkat lunak, data yang
digunakan pada penelitian dimasukkan pada
database program. Sebagai contoh adalah
pada program spectra yang dibuat oleh
Bruton pada tahun 2006. Program ini dibuat
dengan menggunakan bahasa Delphi dengan
input berupa panjang gelombang dan output
berupa warna dasar RGB. Adanya perangkat
lunak ini dapat mempermudah pengguna
untuk melihat secara langsung nilai panjang
gelombang dan warna yang dihasilkan
(Bruton,2006). Namun pada program
tersebut masih memiliki kelemahan yaitu
nilai input dan output dihasilkan hanya
berasal dari database saja sehingga
keterbatasan data pada database akan
mempengaruhi kemampuan program. Oleh
sebab itu dibutuhkan perangkat lunak yang
dapat menghasilkan seluruh nilai panjang
gelombang dari input (warna) tanpa
terpengaruh keterbatasan data pada database
program.
Jaringan syaraf tiruan merupakan
bagian dari ilmu kecerdasan buatan yang
berhubungan dengan pengenalan pola.
Jaringan syaraf tiruan tidak diprogram untuk
menghasilkan keluaran tertentu. Semua
keluaran atau kesimpulan yang ditarik oleh
jaringan didasarkan pada pengalamannya
selama mengikuti proses pelatihan
(Puspitaningrum,2006). Dengan mengetahui
komposisi warna monokromatik dan nilai
panjang gelombang yang dihasilkan, maka
jaringan syaraf tiruan dapat digunakan untuk
mengenali pola hubungan antara warna yang
dihasilkan oleh sudut dari prisma terhadap
nilai panjang gelombang. Apabila jaringan
syaraf tiruan yang sudah dilatih bisa
mengenali pola hubungan antara warna
3
dengan panjang gelombang, maka kita bisa
menentukan nilai panjang gelombang dari
seluruh warna pada spektrum cahaya
tampak.
Metode jaringan syaraf tiruan yang
digunakan tersebut dibuat dengan
menggunakan bahasa pemrograman Matlab
yang memiliki fungsi-fungsi jaringan syaraf
lengkap sehingga tidak perlu menuliskan
banyak perintah pemrograman untuk
membentuk suatu jaringan syaraf, cukup
menggunakan fungsi-fungsi yang sudah
disediakan Matlab secara lengkap untuk
membentuk suatu jaringan syaraf. Dengan
adanya fasilitas Graphical User Interface
(GUI) dalam Matlab maka dapat dibuat
program yang mudah dioperasikan pemakai.
DASAR TEORI
Gelombang Elektromagnetik
Gelombang elektromagnetik adalah
suatu bentuk energi yang memiliki
kecepatan rambat sangat tinggi. Dalam
perambatannya jenis gelombang ini tidak
memerlukan media. Salah satu contoh yang
paling nyata dari gelombang
elektromagnetik adalah cahaya yang
merupakan bagian kecil dari keseluruhan
spektrum elektromagnetik. Gelombang
elektromagnetik dikatakan memiliki dua
sifat, yaitu memiliki sifat sebagai gelombang
dan sifat sebagai partikel. Dualitas ini tidak
hanya berlaku pada cahaya tampak tapi pada
keseluruhan spektrum elektromegnetik.
Gelombang elektromagnetik
memiliki komponen elektrik dan komponen
magnetik. Dua komponen ini berosilasi
saling tegak lurus satu sama lain dan
terhadap arah perambatannya. Gambar 2.1
adalah representasi vektor dari gelombang
elektromagnetik yang merambat kearah
sumbu x. Medan listrik H berosilasi searah
sumbu y dan medan magnet B berosilasi
searah sumbu z
Gambar 2.1. Representasi gelombang
elektromagnetik (Chatwal dan Anand, 1985)
Sumbu y dan z mengindikasikan bahwa
medan listrik dan medan magnet saling
tegak lurus satu sama lain dan memiliki arah
perambatan ke arah x. Jika berkas sinar
seperti pada gambar 2.1 maka disebut
koheren, tetapi jika memiliki fase yang
berbeda maka disebut tidak koheren.
Kecepatan gelombang
elektromagnetik pada ruang hampa tidak
dipengaruhi oleh frekuensi dan memiliki
kecepatan 3×108 meter per detik.
Bertentangan dengan dengan fenomena
gelombang lain seperti gelombang suara,
bagaimanapun gelombang elektromagnetik
tidak membutuhkan medium untuk
merambat (Chatwal dan Anand, 1985).
Seluruh kisaran daerah radiasi
elektromagnetik disebut spektrum
elektromagnetik. Spektrum elektromagnetik
meliputi kisaran panjang gelombang yang
sangat lebar. Spektrum radiasi
elektromagnetik mencakup daerah sinar
gamma, daerah sinar x, daerah ultraviolet
dan cahaya tampak, daerah gelombang
mikro dan daerah gelombang radio. Pada
gambar 2.2 dapat dilihat spektrum
elektromagnetik (Harrison, Lord dan
Loofbourow, 1959).
Gambar 2.2 Spektrum gelombang
elektromagnetik
Masing–masing dari gelombang
tersebut memiliki daerah interval panjang
gelombang yang berbeda–beda, sehingga
setiap gelombang memiliki sifat fisis yang
berbeda dalam perilakunya terhadap
frekuensi.
Cahaya Tampak pada Spektrum
Gelombang Elektromagnetik
Cahaya tampak (380-780) nm,
seperti yang dapat dilihat pada spektrum
elektromagnetik, diberikan dalam Gambar
2.2, menyatakan gelombang pada daerah
sempit yang terletak di antara ultraviolet
(UV) dan inframerah. Pada daerah inilah
4
panjang gelombang tersebut dapat ditangkap
oleh mata manusia dan direpresentasikan
dalam bentuk warna (Anonim,2006).
Sinar putih yang biasa kita lihat
(disebut juga cahaya tampak) sebenarnya
terbentuk dari komponen cahaya
monokromatik yang terdapat pada interval
panjang gelombang (380-780) nm
(Rusydi,2006). Alat paling sederhana yang
sering dipakai untuk menguraikan warna
putih adalah prisma kaca seperti dalam
gambar 2.3.
Gambar2.3 Sebuah prisma kaca menguraikan
cahaya putih yang datang menjadi komponenkomponen
cahayanya (Rusydi,2006)
Suatu cahaya dikatakan
monokromatik apabila hanya memiliki 1
panjang gelombang saja, sedangkan cahaya
putih merupakan cahaya polikromatik.
Apabila cahaya putih dibelokkan dengan
menggunakan prisma pada sudut-sudut
tertentu, kita bisa mengetahui komponen
penyusun dari cahaya putih yang tediri dari
seluruh warna cahaya monokromatik. Pada
gambar 2.4 kita bisa melihat warna-warna
yang dihasilkan dari cahaya putih pada
spektrum cahaya tampak.
Gambar 2.4 warna yang dihasilkan pada
spektrum cahaya berdasarkan nilai panjang
gelombang (Rusydi,2006)
Dari gambar 2.4, kita bisa
menentukan nilai panjang gelombangnya
() dari tiap warna monokromatik.
Meskipun setiap panjang gelombang
memiliki bentuk warna yang berbeda-beda,
namun secara umum bisa kita kelompokkan
menjadi 7 warna. Pada table 2.1 kita bisa
lihat tabel hubungan antara warna terhadap
panjang gelombang () (Hecht, 1990).
Tabel 2.1 Tabel hubungan antara warna terhadap
nilai panjang gelombang ().

Tiga Warna Dasar pada Spektrum
Cahaya Tampak
Cahaya putih tersusun dari seluruh
komposisi warna pada spektrum cahaya
tampak. Ketika distribusi energi pada suatu
berkas cahaya tidak seragam terhadap
spektrum, cahaya akan terlihat berwarna.
Gambar 2.5 melukiskan distribusi frekuensi
yang khas untuk berkas cahaya merah, hijau,
dan biru.
(a) (b) (c)
Gambar 2.5 Kurva refleksi untuk berkas
merah(a), hijau(b) dan biru(c)
Kurva ini menunjukkan daerah
frekuensi yang utama, tetapi pada daerah ini
bisa merupakan suatu variasi yang banyak
dari distribusi, dan mereka masih akan
dipengaruhi oleh warna merah, hijau dan
biru (Hecht, 1990).
Pada awal 1800an Thomas Young
menunjukkan bahwa suatu jangkauan yang
luas dari warna bisa dihasilkan dengan
mencampurkan tiga berkas cahaya,
menyajikan masing–masing frekuensinya
yang secara luas dipisahkan. Ketika tiga
berkas cahaya tersebut berkombinasi
menghasilkan cahaya putih, mereka disebut
warna primer.
Gambar 2.6 Komposisi warna RGB
5
Dengan mengetahui tiga warna
dasar, maka dari gambar 2.6 bisa diperoleh
pola kombinasi yang dihasilkan dari ketiga
warna dasar tersebut. Penjumlahan dari
warna merah, hijau dan biru akan
menghasilkan warna putih (Hecht, 1990).
Jaringan Syaraf Tiruan
Jaringan syaraf tiruan (artificial
neural network) adalah sistem komputasi
dimana arsitektur dan operasi diilhami dari
pengetahuan tentang sel syaraf biologis
dalam otak. Istilah jaringan syaraf tiruan
digunakan karena jaringan syaraf ini
diimplementasikan dengan menggunakan
program komputer yang mampu
menyelesaikan sejumlah proses perhitungan
selama proses pembelajaran, cara kerja
jaringan syaraf tiruan meniru cara kerja otak
manusia.
Salah satu contoh pengambilan ide
dari jaringan syaraf biologis adalah adanya
elemen–elemen pemrosesan pada jaringan
syaraf tiruan yang saling terhubung dan
beroperasi secara pararel. Ini meniru
jaringan syaraf biologis yang tersusun dari
sel–sel syaraf (neuron). Cara kerja dari
elemen–elemen pemrosesan jaringan syaraf
tiruan juga sama seperti cara neuron mengencoude
informasi yang diterimanya.
Hal yang perlu mendapat perhatian
istimewa adalah bahwa jaringan syaraf
tiruan tidak diprogram untuk menghasilkan
keluaran tertentu. Semua keluaran atau
kesimpulan yang ditarik oleh jaringan
didasarkan pada pengalamannya selama
mengikuti proses pembelajaran. Pada proses
pembelajaran, kedalam jaringan syaraf
tiruan dimasukkan pola-pola (input dan
output) lalu jaringan akan diajari untuk
memberikan jawaban yang bisa diterima
(Puspitaningrum,2006).
Secara umum cara kerjanya adalah
dengan memproses sinyal yang diterima
kemudian didistribusikan melewati jaringan
dan disimpan sebagai bobot di setiap neuron.
Selama proses pelatihan, dilakukan proses
penyesuaian bobot dan batas nilai-nilai
diperoleh output yang diinginkan.
Jaringan syaraf tiruan dibentuk
sebagai generalisasi model matematika dari
jaringan syaraf biologi dengan asumsi
bahwa:
•Pemrosesan informasi terjadi pada banyak
elemen sederhana yakni neuron.
•Sinyal dikirim antar neuron melalui
penghubung–penghubung.
•Penghubung antar neuron memiliki bobot
yang akan memperkuat atau
memperlemah sinyal.
•Untuk menentukan output, setiap neuron
menggunakan fungsi aktivasi yang
dikenakan pada jumlah input yang
diterima. Besarnya output ini selanjutnya
dibandingkan dengan suatu nilai ambang
(Siang, 2005).
Komponen Jaringan Syaraf Tiruan
Seperti halnya otak manusia,
jaringan syaraf juga terdiri dari beberapa
neuron dan ada hubungan antara neuronneuron
tersebut. Beberapa neuron akan
mentransformasikan informasi yang
diterimanya melalui sambungan keluaran
menuju neuron-neuron yang lain. Dengan
kata lain, neuron / sel syaraf adalah sebuah
unit pemroses informasi yang merupakan
dasar operasi jaringan syaraf tiruan. Neuron
ini dimodelkan deri penyederhanaan sel
syaraf manusia yang sebenarnya
(Hermawan,2006).
Beberapa komponen yang terdapat pada
jaringan syaraf tiruan antara lain:
Input
Input merupakan data masukan
pada jaringan syaraf tiruan. Data ini
merupakan data awal sebelum diproses.
Setiap input dihubungkan ke satu atribut
tunggal.
Output
Output merupakan data keluaran
pada jaringan syaraf tiruan. Output
berisi solusi untuk permasalahan dari
input.
Bobot
Unsur kunci dari jaringan syaraf
tiruan adalah bobot. Bobot
menunjukkan nilai matematik dari input
data atau banyaknya koneksi yang
memindahkan data dari satu lapisan ke
lapisan lainnya. Dengan kata lain, bobot
menunjukkan kepentingan relatif dari
setiap input ke elemen pemrosesan dan
akhirnya menghasilkan output. Bobot
adalah hal yang penting sekali dimana
mereka menyimpan pola pembelajaran
dari informasi.
Fungsi penjumlahan
Fungsi penjumlahan menghitung
bobot jumlah dari semua elemen input
6
yang dimasukkan pada setiap
pemrosesan elemennya. Fungsi
penjumlahan merupakan perkalian
setiap nilai input dan bobotnya.
Fungsi transfer
Fungsi penjumlahan menghitung
tingkat aktivasi dari neuron.
Berdasarkan tingkatan ini, neuron bisa
menghasilkan suatu output dan bisa
juga tidak. Hubungan antara tingkat
aktivasi internal dan output dapat
berupa linier atau non linier. Hubungan
tersebut dinamakan fungsi transfer
(Desiani dan Arhami,2006).
Arsitektur Jaringan
Jaringan syaraf tiruan di rancang
dengan menggunakan suatu aturan yang
bersifat menyeluruh dimana seluruh model
jaringan memiliki konsep dasar yang sama.
Arsitektur jaringan akan menentukan
keberhasilan target yang akan dicapai karena
tidak semua permasalahan dapat
diselesaikan dengan arsitektur yang sama.
1. Jaringan dengan lapisan tunggal
Jaringan dengan lapisan tunggal hanya
memiliki satu lapisan dengan bobot
terhubung. Jaringan ini hanya menerima
input kemudian secara langsung akan
mengolahnya menjadi output tanpa harus
melalui lapisan tersembunyi.
Gambar 2.7 Jaringan lapisan tunggal
2. Jaringan dengan banyak lapisan
Jaringan dengan banyak lapisan
memiliki satu atau lebih lapisan
tersembunyi yang terletak diantara lapisan
input dan lapisan output. Jaringan dengan
banyak lapisan ini dapat menyelesaikan
permasalahan yang lebih sulit daripada
lapisan dengan lapisan tunggal, dengan
pembelajaran yang lebih rumit.
Gambar 2.8 Jaringan lapisan banyak
Metode Backpropagation
Dalam jaringan syaraf tiruan ada
bermacam–macam metode pelatihan,
diantaranya adalah perceptron, jaringan
basis radial, backpropagation, jaringan
reccurent dan lain–lain. Metode
Backpropagation merupakan metode
pembelajaran lanjut yang dikembangkan
dari aturan perceptron. Hal yang ditiru
dalam perceptron adalah tahapan dalam
algoritma jaringan. Hal yang membedakan
antara backpropagation dengan perceptron
adalah arsitektur jaringannya. Perceptron
memiliki jaringan lapis tunggal sedangkan
backpropagation memiliki lapisan jamak
(Desiani dan Arhami,2006).
Metode Backpropagation merupakan
metode yang sangat baik dalam menangani
masalah pengenalan pola–pola kompleks.

Gambar 2.9 Alur kerja metode backpropagation
Algoritma perhitungan jaringan
syaraf tiruan backpropagation terdiri atas
dua langkah yaitu perambatan maju dan
perambatan mundur. Kedua langkah ini
dilakukan pada jaringan untuk setiap pola
yang diberikan selama jaringan mengalami
pelatihan.
Jaringan backpropagation terdiri
atas tiga lapisan atau lebih pengolah.
Gambar 2.9 menunjukkan jaringan
backpropagation dengan tiga lapisan
pengolah. Bagian kiri sebagai masukan,
bagian tengah sebagai lapisan tersembunyi
dan bagian kanan sebagai lapisan keluaran.
Ketiga lapisan ini terhubung secara penuh
(Hermawan, 2006).
Cara kerja dari backpropagation
adalah dengan menginisialisasi jaringan
dengan bobot yang diset dengan bilangan
acak. Kemudian data pelatihan dimasukkan
kedalam jaringan. Data pelatihan terdiri dari
pasangan input dan output target. Keluaran
dari jaringan berupa sebuah nilai output
aktual. Selanjutnya nilai output aktual
jaringan dibandingkan dengan nilai target
7
untuk mengetahui apakah output jaringan
sudah sesuai dengan output target.
Error yang ditimbul akibat
perbedaan antara nilai output dengan target
tersebut kemudian dihitung dan digunakan
untuk mengubah bobot–bobot yang relevan
dengan jalan mempropagasikan kembali
error. Setiap perubahan bobot yang terjadi
diharapkan dapat mengurangi besar error.
Epoch (Siklus setiap pola pelatihan) seperti
ini dilakukan pada semua set pelatihan
sampai unjuk kerja jaringan mencapai
tingkat yang diinginkan atau sampai kondisi
berhenti terpenuhi. Setelah proses pelatihan
selesai, barulah diterapkan algoritma
aplikasi. Dari respon jaringan dapat dinilai
kemampuan memorisasi dan generalisasi
jaringan dalam menebak output berdasarkan
pada apa yang telah dipelajarinya selama ini
(Puspitaningrum ,2006).
Fungsi Aktivasi pada Backpropagation
Dalam jaringan syaraf tiruan, fungsi
aktivasi merupakan bagian penting dalam
tahapan perhitungan keluaran suatu
algoritma. Argumen fungsi aktivasi adalah
net masukan (kombinasi linier masukan dan
bobotnya). Jika net= i i x w , maka fungsi
aktivasinya adalah f(net)=f( i i x w ).
Beberapa fungsi aktivasi yang sering dipakai
adalah sebagai berikut:
a. Fungsi sigmoid
Dalam backpropagation, fungsi
aktivasi yang dipakai harus memenuhi
beberapa syarat yaitu: kontinu,
terdiferensial dengan mudah dan
merupakan fungsi yang tidak turun. fungsi
yang memenuhi ketiga syarat tersebut
adalah fungsi sigmoid. Terdapat 2 buah
fungsi sigmoid yaitu sigmoid biner
(logsig) dan sigmoid bipolar (tansig).
Grafik fungsinya tampak pada gambar
2.10
Gambar 2.10 Grafik fungsi sigmoid biner (a)
dan sigmoid bipolar (b)
Sigmoid biner memiliki nilai interval (0,1)
dan memiliki bentuk fungsi:
f (x) = 1ex
1
dengan turunan
f ‘(x) = f (x) (1- f (x) )
Sedangkan pada sigmoid bipolar yang
bentuk fungsinya mirip dengan fungsi
sigmoid biner, tapi dengan interval (-1,1).
f (x) = 1ex
2
-1 dengan turunan
f ‘(x) =
2
(1f (x))(1f (x))
b. Fungsi identitas
fungsi identitas dipakai apabila kita
menginginkan keluaran jaringan berupa
sembarang bilangan riil (bukan hanya
pada interval [0,1] atau [-1,1]). f (x) = x
grafik fungsi identitas tampak pada
gambar 2.11
Gambar 2.11 Grafik fungsi identitas (purelin)
Pelatihan dengan Algoritma Levenberg-
Marquardt (trainlm)
Pelatihan standar backpropagation
merupakan metode yang paling sederhana
dalam proses pengaturan bobot. Dalam
standar backpropagation, bobot
dimodifikasi pada arah penurunan tercepat.
Pengaturan bobot selalu dilakukan dalam
arah negatif (gradien negatif). Meskipun
penurunan fungsi berjalan cepat, tapi tidak
menjamin akan konvergen dengan cepat
(Siang, 2005).
Oleh sebab itu digunakan beberapa
perbaikan metode pada pengaturan bobot
untuk mempercapat proses pelatihan. Salah
satu metode tersebut adalah perbaikan
dengan teknik optimasi numeris. Ada 3 buah
algoritma yang terdapat pada metode ini
yaitu algoritma conjugate gradient, quasi
Newton dan levenberg marquardt.
Pada algoritma-algoritma yang
menggunakan conjugate gradient,
pengaturan bobot tidak selalu dalam arah
menurun, tapi disesuaikan dengan arah
konjugasinya. Pada metode Newton
merupakan salah satu alternatif conjugate
gradient yang bisa mendapatkan nilai
optimum lebih cepat. Namun metode ini
8
sangat kompleks, memerlukan waktu lama
dan memori yang cukup besar karena pada
setiap iterasinya harus menghitung turunan
kedua.
Seperti halnya metode Quasinewton,
algoritma Levenberg-Marquadrt
dirancang dengan menggunakan turunan
kedua tanpa harus menghitung matriks
Hessian. Apabila jaringan syaraf
feedforward menggunakan fungsi kinerja
sum of square, maka matriks Hessian dapat
didekati sebagai:
H=J’*J
Dan gradien dihitung sebagai:
gW=J’*e
dengan J adalah matriks Jacobian yang
berisi turunan pertama dari error jaringan
terhadap bobot, dan e adalah suatu vektor
yang berisi error jaringan. Matriks dapat
dihitung dengan teknik backpropagation
standar, yang tentu saja lebih sederhana
dibanding menggunakan matriks Hessian.
Algoritma Levenberg-marquardt
menggunakan pendekatan untuk menghitung
matriks Hessian, melalui perbaikan metode
Newton:
W W J J I J e k k [ ‘* * ] 1 * ‘*
1


Apabila bernilai 0, maka
pendekatan ini akan sama seperti metode
Newton. Namun apabila terlalu besar,
maka pendekatan ini akan sama halnya
gradient descent dengan learning rate yang
sangat kecil. Metode Newton sangat cepat
dan akurat untuk mendapatkan error
minimum, sehingga diharapkan algoritma
sesegera mungkin dapat mengubah nilai 
menjadi sama dengan 0. Untuk itu, setelah
beberapa iterasi, algoritma akan menurunkan
nilai . Kenaikan nilai hanya dilakukan
apabila dibutuhkan suatu langkah
(sementara) untuk menurunkan fungsi
kinerja (Kusumadewi,2003).
METODE PENELITIAN
Pada penelitian ini, data input
berupa sekumpulan nilai seluruh warna
monokromatik cahaya tampak yang
diletakkan pada matrik (3346 ).
Sedangkan data target berupa nilai panjang
gelombang dari tiap warna input yang
diletakkan pada matrik (1346 ). Kedua
data tersebut digunakan sebagai data
pelatihan dan data pengujian.
Masing-masing dari data tersebut
kemudian dibagi menjadi 2 buah data
dengan komposisi genap dan ganjil. Data
pertama digunakan sebagai data pelatihan
dan pada pengujian digunakan data pertama
dan data kedua. Pengujian terhadap data
kedua bertujuan untuk mengetahui perilaku
jaringan terhadap data yang sama sekali
belum dikenal / belum dilatih. Apabila
keluaran dari jaringan syaraf tiruan bisa
sama / mendekati nilai target dari kedua data
tersebut, berarti jaringan syaraf tiruan bisa
mengenali pola hubungan antara nilai warna
monokromatik terhadap panjang gelombang.
Jaringan saraf tiruan yang dibuat
menggunakan metode backpropagation
dengan tiga input, 1 lapisan tersembunyi,
dan satu output. Input berupa toleransi nilai
warna dasar RGB antara 0-255 yang
menunjukkan tingkatan warna dari masingmasing
nilai merah (R), hijau (G), dan biru
(B). Nilai dari input ini akan masuk menuju
hidden layer (lapisan tersembunyi) melalui
fungsi aktivasi sigmoid bipolar. Nilai dari
lapisan tersembunyi akan masuk menuju
output melalui fungsi identitas (purelin).
Output berupa nilai panjang gelombang
yang dihasilkan dari kombinasi nilai warna
pada input. Nilai output yang dihasilkan dari
jaringan syaraf tiruan ini akan dibandingkan
hasilnya dengan nilai panjang gelombang
spektrum cahaya tampak pada referensi
(target).

Gambar 3.1 Arsitektur JST Backpropagation
Setiap neuron pada lapisan input
akan berhubungan dengan setiap neuron
pada lapisan tersembunyi melalui fungsi
aktivasi sigmoid bipolar. Fungsi aktivasi
digunakan untuk menentukan keluaran suatu
neuron. Sigmoid bipolar akan merubah nilai
input menjadi nilai dengan interval [-1,1]
menuju lapisan tersembunyi. Keluaran dari
lapisan tersembunyi akan diteruskan menuju
output melalui fungsi identitas.
Backpropagation tidak membatasi
berapa jumlah neuron pada lapisan
tersembunyi. Apabila jumlah neuron sedikit
maka proses komputasinya akan menjadi
9
lebih sederhana, namun jaringan tidak akan
bisa mengenali bentuk pola dengan baik.
Sedangkan apabila jumlah neuron banyak
maka bentuk pola yang rumit akan bisa
dikenali jaringan dengan baik, namun proses
komputasinya menjadi lebih rumit sehingga
memerlukan waktu yang lebih lama. Oleh
sebab itu, pada penelitian ini diperlukan
jumlah neuron yang tepat sehingga proses
pelatihan menjadi efektif.
HASIL DAN PEMBAHASAN
Semua parameter pelatihan seperti
jumlah neuron pada lapisan tersembunyi dan
parameter tambahan (mu, mu_dec, mu_inc)
berpengaruh terhadap kecepatan proses
pelatihan. Karakteristik jaringan syaraf
tiruan pada program ini juga ditentukan oleh
parameter-parameter tadi.
Untuk mengetahui karakteristik
jaringan syaraf tiruan, dilakukan berbagai
pengujian dengan melakukan variasi pada
parameter-parameter pelatihan. Pengujian
dilakukan dengan melihat pengaruh hargaharga
parameter pelatihan terhadap
kecepatan pelatihan.
Pengaruh Jumlah Neuron Tersembunyi
Terhadap Jumlah Iterasi
Setiap neuron pada lapisan input
maupun output akan terhubung dengan
neuron pada lapisan tersembunyi melalui
bobot dan fungsi aktivasi. Apabila jumlah
neuron pada lapisan tersembunyi sedikit
maka proses pelatihan menjadi lebih
sederhana, tapi sulit untuk pengenalan pola
hubungan antara input dan target sehingga
iterasi yang diperlukan menjadi lebih lama.
Dengan adanya penambahan jumlah neuron
diharapkan pengenalan pola menjadi lebih
mudah sehingga diperoleh jumlah iterasi
yang sedikit. Namun apabila jumlah neuron
terlalu banyak maka proses pelatihan
menjadi rumit sehingga proses pelatihan
menjadi lambat.
Untuk mengetahui pengaruh jumlah
neuron pada lapisan tersembunyi terhadap
jumlah iterasi (epoch), dilakukan beberapa
pengujian dimulai dari bentuk jaringan yang
paling sederhana dengan target error 10-8.
Parameter-parameter lain pada pelatihan
dibuat nilai default dari matlab (mu=0.001 ,
mu_dec=0.1, mu_inc=10). Dari pengujian
yang dilakukan, jumlah neuron yang paling
efektif untuk melakukan pelatihan jaringan
pada program ini adalah 30 buah dengan
jumlah iterasi yang terjadi sebanyak 256
iterasi. Hasil pengujian dapat dilihat pada
tabel 4.1.
Tabel 4.1. Pengaruh jumlah neuron pada lapisan
tersembunyi terhadap Jumlah iterasi (epoch)
Pada jaringan yang paling
sederhana yaitu dengan menggunakan 10
neuron, target 10-8 tidak dapat tercapai.
Penurunan nilai error hanya sampai pada
10 7 , Dan setelah itu tidak terjadi
penurunan error lagi meskipun iterasi terus
berjalan. Hal ini disebabkan bentuk jaringan
yang sederhana tidak dapat mengenali
bentuk pola yang rumit dengan target error.
Dengan adanya penambahan jumlah neuron,
jaringan dapat mencapai nilai target 10-8 .
Pengujian terbaik diperoleh pada neuron 30
buah yaitu hanya dengan 256 iterasi.
Pengujian dihentikan pada neuron 60 buah,
hal ini dikarenakan disamping tidak terjadi
penurunan iterasi yang berarti, kerja
pelatihan menjadi semakin lambat, karena
memproses neuron yang terlalu banyak.
Secara grafik hubungan antara banyaknya
neuron pada lapisan tersembunyi dan jumlah
iterasi yang terjadi terlihat pada gambar 4.1.
Gambar 4.1. Grafik pengaruh jumlah neuron
terhadap jumlah iterasi
10
Pengaruh mu () , mu_dec, dan mu_inc
Terhadap Jumlah Iterasi
Pada algoritma levenbergmarquardt,
mu () sangat berpengaruh
pada proses perubahan bobot dengan
persamaan
W W J J I J e k k [ ‘* * ] 1 * ‘*
1

.
Besarnya nilai mu () akan berubah untuk
setiap perubahan iterasi. Untuk itu, setelah
beberapa iterasi, algoritma akan menurunkan
nilai mu () dengan mengalikan
mu=mu*mu_dec. Karena mu_dec berfungsi
untuk menurunkan nilai mu (), maka
mu_dec bernilai antara 0 sampai 1.
Kenaikan nilai mu () hanya dilakukan
apabila dibutuhkan suatu langkah
(sementara) untuk menurunkan fungsi
kinerja. Untuk menaikkan nilai mu (),
digunakan mu_inc dengan mengalikan
mu=mu*mu_inc. Nilai mu_inc bernilai lebih
dari 1.
Ketiga faktor tersebut saling
berhubungan dalam proses perubahan bobot
untuk menurunkan nilai error. Proses
pengujian dimulai dari mu () terlebih
dahulu dengan mu_dec dan mu_inc bernilai
default. Hasil pengujian dapat dilihat pada
tabel 4.2.
Tabel 4.2. Pengaruh mu (μ) (a), mu_dec (b),dan
mu_inc (c) terhadap Jumlah iterasi (epoch)
a b c
Dari tabel 4.2a semakin besar nilai
mu, maka iterasi yang diperlukan untuk
mencapai target error menjadi semakin
besar. Nilai mu terbaik terdapat pada nilai
10 5 yaitu dengan 32 iterasi saja. Nilai ini
menghasilkan jumlah iterasi yang lebih kecil
dibandingkan dengan nilai default mu 10 3
dengan 256 iterasi. Ketika nilai mu
diperkecil, iterasi akan terus bernilai konstan
sebesar 194 iterasi.
Pengujian dilanjutkan dengan
merubah besarnya nilai mu_inc dan mu_dec.
Dari tabel 4.2b dan 4.2c, Adanya perubahan
mu_dec dan mu_inc tidak menurunkan
jumlah iterasi, sehingga tetap digunakan
nilai default (mu_dec=0,1 dan mu_inc=10)
sebagai parameter efektif.
Pengaruh Target Error Terhadap Jumlah
Iterasi
Target error adalah target nilai
fungsi kinerja yang menunjukkan
kemampuan jaringan dalam mengenali pola
hubungan antara input dengan target. Error
diperoleh dengan menghitung selisih antara
keluaran jaringan dan target pelatihan,
semakin kecil harga target error maka
kemungkinan kesalahan jaringan dalam
mengenali pola menjadi semakin kecil.
Setiap proses iterasi akan
mengubah bobot jaringan dan menunjukkan
error. Dalam satu iterasi setiap data dihitung
selisih keluarannya terhadap target
pasangannya. Selisih ini adalah harga error
pelatihan data tersebut, harga error satu
iterasi merupakan rata-rata kuadrat dari
error pelatihan semua data tadi, apabila
harga error pada iterasi tertentu lebih kecil
atau sama dengan harga target error maka
iterasi dihentikan.
Dalam pengujian digunakan
parameter-parameter pelatihan yang telah
diuji menghasilkan proses pelatihan yang
efektif. Parameter tersebut antara lain:
jumlah neuron pada lapisan tersembunyi=30,
mu=10 5 , mu_dec=0.1, dan mu_inc=10.
Pada tabel 4.3 menunjukkan pengaruh target
error terhadap jumlah iterasi (epoch).
Tabel 4.3. Pengaruh target error terhadap
jumlah iterasi
Pada penelitian ini target bernilai
antara 0.380-0.780, sehingga pengujian
11
dengan target error dimulai dari 10 3 . Pada
target error 10 9 ,iterasi tidak dapat
mencapai nilai tersebut. Untuk melihat
gambaran hubungan antara target error dan
jumlah iterasi yang terjadi secara lebih jelas,
dapat dilihat dari gambar 4.2 .
Gambar 4.2. Grafik pengaruh target error
terhadap jumlah iterasi
Pengujian Jaringan Menggunakan Data 1
Data 1 merupakan data yang
digunakan dalam proses pelatihan. Proses
pengujian ini bertujuan untuk mengetahui
kemampuan jaringan untuk mengingat dan
mengidentifikasi data yang sudah dilatih.
Karena data 1 merupakan data pelatihan,
maka kemampuan dalam mengidentifikasi
target akan lebih baik dibandingkan dengan
menggunakan data 2 dalam pengujian.
Secara umum pengujian menggunakan data
1 dapat dilihat pada tabel 4.4
Tabel 4.4 Tabel pengujian menggunakan data 1
Dari tabel 4.4 menunjukkan bahwa
pada target error 10 4 sebagian besar data
belum dapat mengenali target. Hanya
sebanyak 19 dari 173 data saja yang dapat
dikenali. Secara umum error yang
dihasilkan masih bernilai sangat besar dalam
skala ratusan sampai ribuan persen dengan
error terbesar bernilai 2965% . Pengujian
dilanjutkan dengan menggunakan target
error 10 5 . Hasil yang diperoleh yaitu
sebanyak 84 data yang dapat dikenali. Hasil
ini jauh lebih baik dibandingkan dengan
pengujian sebelumnya. Error rata-rata yang
dihasilkan juga tidak sebesar pada pengujian
awal yaitu dengan error terbesar bernilai
354%.
Pada pengujian dengan target error 10 6
diperoleh hasil yang agak mengecewakan
dibandingkan dengan pada target error
10 5 . Hal ini dikarenakan pengujian ini
hanya menghasilkan 78 dari 173 data yang
dapat dikenali. Namun secara keseluruhan,
error mengalami penurunan dengan error
terbesar hanya 186% saja. Pada target error
10 7 memiliki peningkatan yang cukup
drastis dalam mengenali target yaitu
sebanyak 168 dari 173 data telah dapat
dikenali. Error terbesar pun hanya bernilai
65% saja. Pada pengujian terakhir dengan
target error 10 8 , jaringan telah mengenali
seluruh target dengan error terbesar bernilai
29%.
Pengujian Jaringan Menggunakan Data 2
Data 2 merupakan data yang sama
sekali belum dilatih oleh jaringan. Pengujian
ini bertujuan untuk mengetahui output dari
jaringan untuk data yang belum dikenal
dengan menggunakan pola pada pelatihan
data 1. Karena data 1 dan data 2 memiliki
bentuk karakteristik yang sama yaitu antara
nilai warna RGB dengan panjang
gelombang, maka diharapkan data 2 dapat
menghasilkan keluaran yang sesuai dengan
target. Secara umum pengujian
menggunakan data 1 dapat dilihat pada tabel
4.5
Tabel 4.5 Tabel pengujian menggunakan data 2
Dari tabel 4.5 menunjukkan bahwa
pada target error 10 4 sebagian besar data
belum dapat mengenali target. Hanya
sebanyak 12 dari 173 data saja yang dapat
dikenali. Pengujian dilanjutkan dengan
Target Error Σ Data yang sesuai Σ Data yang tidak sesuai
10
4
19 154
10
5
84 89
10
6
78 95
10
7
168 5
10
8
173 0
Target Error Σ Data yang sesuai Σ Data yang tidak sesuai
10
4
12 161
10
5
80 93
10
6
78 95
10
7
162 11
10
8
168 5
12
menggunakan target error 10 5 . Hasil yang
diperoleh yaitu sebanyak 80 data yang dapat
dikenali. Pada pengujian dengan target error
10 6 diperoleh hasil yang agak
mengecewakan dibandingkan dengan pada
target error 10 5 . Hal ini dikarenakan
pengujian ini hanya menghasilkan 78 data
yang dapat dikenali. Pada target error 10 7
memiliki peningkatan yang cukup drastis
dalam mengenali target yaitu sebanyak 162
data telah dapat dikenali. Pada pengujian
terakhir dengan target error 10 8 ,
meskipun tidak dapat mengenali seluruh
data seperti pada data 1, jaringan telah
mengenali 168 data.
Meskipun dalam pengenalan
terhadap target data 2 tidak sebaik data 1,
Namun secara keseluruhan hasil pada data 2
memiliki bentuk yang sama seperti pada
data1. Penyimpangan terbesar untuk seluruh
pengujian pada data 2 terjadi pada input
warna merah (255 0 0) yaitu sebesar 5000%-
6000%. Namun penyimpangan tersebut
masih berada pada interval warna merah.
Kesimpulan
Dari penelitian yang sudah dilakukan,
didapatkan kesimpulan sebagai berikut:
1. Program Jaringan Syaraf Tiruan yang
telah dibuat dapat digunakan untuk
menentukan panjang gelombang
spektrum cahaya tampak dengan pola
hubungan warna dasar dan panjang
gelombang.
2. Dari pengujian karakteristik jaringan,
arsitektur jaringan yang paling baik
adalah (3-30-1), 3 buah neuron pada
layer input, 30 buah neuron pada
layer tersembunyi dan 1 buah pada
layer output.
3. Dari proses pelatihan menggunakan
trainlm diperoleh nilai parameter
efektif yaitu mu=10-5 , mu_dec=0.1,
dan mu_inc=10.
4. Dari hasil uji penelitian menggunakan
target error terkecil 10-8, jaringan
dapat mengenali data 2 (data uji yang
merupakan data yang sama sekali
belum dilatihkan pada jaringan)
sebesar 97.11%.
DAFTAR PUSTAKA
Anonim,2006, warna,

http://id.wikipedia.org/wiki/Warna,

20 Agustus 2007
Bruton, D, 2006, Visible light spectrum,
http://www.efg2.com/Lab/ScienceAndEngine
ering/spectra.htm.
Chatwal, G dan Anand, S,1985,
Spectroscopy (Atomic and Molecular),
Bombay, Himalaya Publishing House.
Desiani, A dan Arhami M,2006, Konsep
Kecerdasan Buatan, Andi, Yogyakarta.
Harrison, Lord dan Loofbourow, 1959,
Practical Spectroscopy ,Massachusetts,
Prentice Hall Inc.
Hecht, E,1990, Optics, Addison wesley
publishing company inc,Canada.
Hermawan, A, 2006, Jaringan Saraf
Tiruan Teori dan Aplikasinya, Andi,
Yogyakarta.
PERANCANGAN PERANGKAT LUNAK
Oleh : Dr. Asep Juarna, SSi, MKom
I. Pengantar
♦ Definisi :
Perancangan perangkat lunak adalah disiplin manajerial dan teknis yang berkaitan
dengan pembuatan dan pemeliharaan produk perangkat lunak secara sistematis,
termasuk pengembangan dan modifikasinya, yang dilakukan pada waktu yang tepat
dan dengan mempertimbangkan faktor biaya.
♦ Tujuan :
Tujuan perancangan perangkat lunak adalah untuk memperbaiki kualitas produk
perangkat lunak, meningkatkan produktivitas, serta memuaskan teknisi perangkat
lunak.
♦ Pengertian produk perangkat lunak :
Produk perangkat lunak adalah perangkat lunak yang digunakan oleh berbagai
pengguna, bukan untuk pengguna pribadi.
♦ Hal-hal yang perlu diperhatikan dalam pengembangan sebuah produk
perangkat lunak :
• kebutuhan dan batasan-batasan yang diinginkan pengguna harus ditentukan dan
dinyatakan secara tegas,
• produk perangkat lunak harus dirancang sedemikian rupa sehingga mampu
mengakomodasi paling tidak kepentingan tiga pihak berikut : pelaksana
implementasi, pengguna, dan pemelihara produk,
• penulisan source code harus dilakukan dengan hati-hati dan senantiasa melalui
tahap uji,
• dilengkapi dengan dokumen-dokumen pendukung seperti : prinsip pengoperasian,
user’s manual, instruksi instalasi, dokumen pemeliharaan,
• menyiapkan bantuan pelatihan.
♦ Tugas-tugas pemeliharaan perangkat lunak meliputi :
• analisa terhadap permintaan perubahan,
• perancangan ulang dan modifikasi terhadap source code yang diikuti dengan
serangkaian proses uji,
• dokumentasi perubahan dan pembaruan dokumen-dokumen yang berkaitan
dengan modifikasi,
• penyebaran produk yang telah mengalami modifikasi ke situs-situs pengguna.
♦ Jarak inteletual
• Pemetaan antara model dengan realitas yang dimodelkan dikenal sebagai jarak
intelektual antara suatu persoalan dengan komputerisasi solusi atas persoalan
tersebut.
• Prinsip dasar perancangan rekayasa perangkat lunak adalah merancang produk
perangkat lunak yang meminimalkan jarak intelektual.
♦ Modul
• Prinsip dasar untuk menangani kerumitan dalam perancangan perangkat lunak
adalah dengan melakukan dekomposisi terhadap sistem yang berukuran besar ke
dalam beberapa subsistem yang lebih kecil.
• Unit dekomposisi tersebut dinamakan modul.
• Dalam dekomposisi tersebut harus ditetapkan pengantarmukaan (interfacing)
antar setiap subunit, baik pengantarmukaan kendali maupun data.
• Pengantarmukaan kendali dilakukan dengan mekanisme hubungan pemanggilan
(calling) antar modul.
• Pengantarmukaan data dilakukan dengan mekanisme penyampaian parameter
(parameter passing) antar modul.
♦ Programmer
Programer adalah individu yang bertugas dalam hal rincian implementasi,
pengemasan, dan modifikasi algoritma serta struktur data, dituliskan dalam sebuah
bahasa pemrograman tertentu.
♦ Software Engineer
• Software engineer bertugas melakukan analisa, rancangan, uji dan verifikasi,
dokumentasi, pemeliharaan perangkat lunak, serta pengelolaan proyek.
• Software engineer harus mempunyai keterampilan dan pengalaman seorang
programmer
♦ Kualitas Produk Perangkat Lunak
Beberapa atribut yang merupakan ukuran kualitas perangkat lunak adalah :
• kegunaan, yaitu pemenuhan terhadap kebutuhan pengguna,
• keandalan, yaitu kemampuan melaksanakan fungsi yang diinginkan,
• kejelasan, yaitu penulisan program dilakukan secara jelas dan mudah dimengerti,
• efisiensi, terutama dalam waktu eksekusi dan penggunaan memory,
II. Beberapa Ukuran Yang Berkaitan Proyek
♦ Total Upaya Yang Dicurahkan Untuk Perangkat Lunak
100 %
Hardware
80
Pengembangan s/w
60
40
Pemeliharaan s/w
20
0
1955 1960 1978 1985
Perubahan rasio biaya untuk h/w terhadap biaya untuk s/d 1985
♦ Distribusi Upaya
• Masa hidup sebuah produk perangkat lunak adalah 1 s/d 3 tahun dalam
pengembangan dan 5 s/d 15 tahun dalam pemakaiannya (pemeliharannya).
• Distribusi upaya antara pengembangan dan pemeliharaan bervariasi antara 40/60,
30/70, dan bahkan 10/90.
• Tiga aktivitas pengembangan perangkat lunak adalah : analisa dan perancangan,
implementasi dan pengujian.
• Tiga aktivitas pemeliharaan perangkat lunak adalah : peningkatan kemampuan
produk, penyesuaian produk dengan lingkungan pemrosesan baru, dan perbaikan.
Upaya pengembangan pemeliharaan
Relatif (40%) (60%)
36%
16% 16%
8% 12% 12%
analisa dan implementasi uji penyesuaian peningkatan perbaikan
perancangan
Diagram distribusi upaya dalam putaran hidup sebuah perangkat lunak
(software life cycle, SLC)
♦ Katagori Ukuran Proyek
Katagori Jumlah Lama Jumlah Contoh proyek
programmer pengerjaan Baris
Trivial 1 1-4 minggu 500 keperluan pribadi seorang programmer
Kecil 1 1-6 bulan 1K-2K penyelesaian numerik masalah sains
Menengah 2-5 1-2 tahun 5K-50K compiler berukuran tidak terlalu besar
Besar 5-20 2-3 tahun 50K-100K paket data base
Sangat Besar 100-1K 4-5 tahun 1M sistem operasi besar
Extra Besar 2K-5K 5-10 tahun 1M-10M sistem pertahanan balistik
♦ Penggunaan Waktu Seorang Programmer
Tabel aktivitas programmer (Bell Lab. Study, sampel : 70 programmer)
Aktivitas %
Waktu
Keterangan
Penulisan program 13 waktu efektif
Membaca program dan membuat manual 16 upaya perbaikan atas
Mengkomunikasi pekerjaan 32 kegagalan (48%)
Kegiatan pribadi (libur, sakit, dsb) 13
Lain-lain (kamar kecil, telefon pribadi, rehat kopi, dsb) 15 waktu
Pelatihan 6 overhead (39%)
Surat menyurat 5
Proyek 1
40% Proyek 2
30
20
10
Baca Rancang Rencana Program Dokumen Uji Review Rapat Perbaikan
Diagram distribusi aktivitas programer untuk dua buah proyek perangkat lunak.
Perhatikan bahwa sekitar 40% aktivitas adalah : baca, review, rapat, dan
perbaikan
♦ Faktor Yang Mempengaruhi Kualitas Produk dan Produktivitas Programmer
• Kemampuan pribadi :
– dua aspek dasar kemampuan : kecakapan umum dan terbiasa dengan aplikasi
tertentu.
– seorang yang cakap dalam pemrograman belum tentu cakap pula dalam aplikasi
sains, atau sebaliknya.
– ketidakakraban dengan lapangan aplikasi akan menghasilkan produktivitas
rendah dan kualitas yang buruk.
– yang dimaksud dengan kecakapan umum adalah kemampuan dasar dalam
menulis program komputer dengan benar sedangkan ukuran produktivitas
seorang programmer adalah banyak baris yang dihasilkan oleh programmer
tersebut per hari.
• Komunikasi team
– meningkatnya ukuran produk yang dihasilkan akan menurunkan produktivitas
programmer akibat meningkatnya kerumitan antara komponen-komponen
program dan akibat meningkatnya komunikasi yang perlu dilakukan antara
programmer, manajer, dan pelanggan.
– jumlah lintasan komunikasi antar programmer yang terjadi dalam sebuah
proyek adalah n(n-1)/2, dimana n adalah jumlah programmer yang terlibat
dalam proyek tersebut.
– penambahan lebih banyak programmer dalam sebuah proyek yang sedang berjalan
akan menurunkan produktivitas, kecuali jika para programmer baru
tersebut mempunyai tugas yang tidak bergantung kepada hasil kerja
programmer lama.
– Hukum Brooks : Adding more programmers to a late project may make it later.
• Kerumitan produk
– tiga level kerumitan produk : program aplikasi, program utility, program level
sistem.
level produktivitas relatif contoh bahasa
produk terhadap level sistem produk pemrograman
aplikasi 25 s/d 100 pengolahan data Pascal, Cobol
utility 5 s/d 10 compiler Pascal, C
sistem 1 sistem operasi bahasa rakitan
• Notasi yang tepat
– bahasa pemrograman menetapkan notasi (baca : token, reserve word) baku,
terutama untuk hal-hal yang berkaitan dengan matematika.
– penetapan notasi antar programer (baca : perancang produk) harus dilakukan
sehingga dapat dimengerti dengan jelas.
• Pendekatan sistematis
– sistem menetapkan teknik dan prosedur baku.
– pembakuan dalam pengembangan dan pemeliharaan perangkat lunak masih belum
mantap.
• Kendali perubahan
– kelenturan sebuah produk perangkat lunak merupakan sebuah kekutan, tetapi di
pihak lain juga merupakan sumber kesulitan dalam proses perancangannya.
– perubahan terhadap produk harus tetap meminta persetujuan manajer sebagai
penanggung jawab proyek.
– dampak perubahan harus dapat ditelusuri, diuji, dan didokumentasikan.
• Tingkat teknologi
– peran penggunaan teknologi dalam proyek perangkat lunak misalnya menyangkut
bahasa pemrograman, lingkungan mesin yang digunakan, teknik pemrograman, dan
penggunaan tools tertentu.
– bahasa pemrograman modern menyediakan fasilitas penyesuaian pendefinisisan dan
penggunaan data, konstruksi aliran kendali, fasilitas modular, dan concurent
programming
• Tingkat keandalan
– setiap produk harus mempunyai keandalan standar.
– peningkatan keandalan dihasilkan melalui perhatian yang sangat besar pada tahap
analisa.
– peningkatan keandalan akan menurunkan produktivitas.
– Boehm : rasio produktivitas antara dua produk dengan keandalan terendah dengan
yang tertinggi adalah 2:1.
• Pemahaman permasalahan
– pelanggan adalah penyumbang utama terhadap kegagalan dalam memahami
masalah adalah : (1) tidak memahami permasalahan perusahaannya, (2) tidak
mengerti kemampuan dan keterbatasan komputer, (3) tidak mempunyai
pengetahuan dasar tentang logika dan algoritma.
– software engineer tidak memahami lapangan aplikasi, gagal mendapatkan informasi
kebutuhan pelnggan karena pelanggan bukan seorang end user.
• Ketersediaan waktu
– penetapan lama proyek dan jumlah programmer terlibat harus mempertimbangkan
kemampuan pribadi setiap programmer serta kemapuan komunikasi antar mereka.
– jumlah programmer yang makin banyak akan meningkatkan overhead di antaranya
akibat keperluan komunikasi.
– jumlah programmer yang makin sedikit berarti memperbanyak beban kerja kepada
setiap programmer.
– proyek 1 bulan dengan 6 programmer bisa saja diganti dengan proyek 6 bulan
dengan 1 programmer ata proyek 3 bulan dengan 3 programmer.
• Persyaratan keterampilan
– berbagai keterampilan harus ada dalam sebuah proyek perangkat lunak, misalnya :
(1) keterampilan berkomunikasi dengan pelanggan untuk memastikan keinginannya
dengan sejelas-jelasnya, (2) kemampuan dalam pendefinisian masalah dan
perancangan, (3) kemampuan implementasi dengan penulisan program yang benar,
(4) kemampuan debugging secara deduktif dengan kerangka “what if ”, (5)
dokumentasi, (6) kemampuan bekerja dengan pelanggan.
– semua keterampilan tersebut harus senantiasa dilatih.
• Fasilitas dan sumber daya
Fasilitas non teknis yang tetap perlu diperhatikan yang berkaitan dengan motivasi
programmer misalnya : mesin yang baik, serta tempat yang tenang, atau ruang
kerjanya dapat ditata secara pribadi.
• Pelatihan yang cukup
Banyak programmer yang dilati dalam bidang-bidang : ilmu komputer, teknik elektro,
akuntansi, matematika, tetapi jarang yang mendapat pelatihan dalam bidang teknik
perangkat lunak.
• Kemampuan manajemen
– seringkali manajer proyek tidak mempunyai, atau hanya sedikit mengetahui, latar
belakang teknik perangkat lunak.
– di sisi lain terjadi promosi jabatan menjadi manajer dimana yang berpromosi tidak
atau kurang mempunyai kemampuan manajemen.
• Sasaran yang tepat
Sasaran utama dari tekni perangkat lunak adalah pengembangan produk-produk
perangkat lunak yang tepat untuk digunakan.
• Peningkatan kualitas
Dua aspek yang menimbulkan keinginan untuk meningkatkan kualitas produk adalah
: (1) seberapa banyak fungsi, keandalan, dan kemampuan dapat diberikan melalui
sejumlah pengembangan, (2) masalah mendasar dariketerbatasan teknologi perangkat
lunak.
• Faktor lain
Faktor lain di antaranya adalah : keakraban, akses, dan stabilitas terhadap sistem
komputer dalam mengembangkan atau memodifikasi perangkat lunak.
♦ Masalah Manajerial
• Sejumlah masalah yang seringkali muncul :
1. buruknya perencanaan proyek
2. buruknya prosedur dan teknik pemilihan manajer proyek
3. tidak diketahui dengan tepat siapa penanggung jawab buruknya hasil proyek
4. buruknya kemampuan untuk menetapkan sumber daya yang dibutuhkan
proyek
5. kriteria keberhasilan proyek tidak tepat
6. buruknya struktur organisasi proyek
7. pemilihan teknik menajemen yang tidak tepat
8. tidak diterapkan prosedur, metoda, dan teknik dalam perancangan sistem
kendali yang memungkinkan manajer dapat mengontrol proyeknya dengan
baik
9. tidak digunakannya prosedur, teknik, dan strategi yang dapat menyediakan
kejelasan perkembangan proyek
10. standar dan teknik untuk mengukur kualitas kerja dan produktivitas
programmer dan analis pengolahan data tidak dijalankan
• Beberapa solusi yang dapat dilakukan :
1. lakukan pendidikan dan pelatihan terhadap menejen puncak dan manajer
proyek
2. laksanakan penggunaaan standar, prosedur, dan pendokumentasian
3. lakukan analisa data dari proyek sebelumnya untuk menentukan metda efektif
4. tetapkan tujuan dengan menyatakan kualitas yang diinginkan
5. tetapkan kualitas dengan acuan standar peluncuran produk
6. tetapkan kriteria keberhasilan proyek
7. siapkan rencana darurat
8. kembangkan kejujuran, akurasi biaya, dan perkiraan jadwal proyek yang dapat
diterima manajemen dan pelanggan
9. pilih manajer proyek berdasarkan kemampuannya memimpin proyek, bukan
berdasarkan kemampuan teknik atau (apalgi) memang tidak ada orang lain
lagi
10. buat penetapan kerja yang spesifik untuk setiap pelaksana dan tetapkan
standar kerja.
PERANCANGAN PERANGKAT LUNAK
Oleh : Asep Juarna, SSi, MKom
II. Perencanaan Proyek Perangkat Lunak
3 langkah perencanaan : pendefinisian masalah, pengembangan strategi solusi, rencana
proses pengembangan.
A. Pendefinisian Masalah
1. Nyatakan masalah yang akan diselesaikan secara tegas, termasuk di dalamnya batasan
masalah dan sasaran yang ingin dicapai. Pernyataan masalah ditetapkan dalam sudut
pandang pelanggan.
• pernyataan masalah dalam sudut pelanggan misalnya : masalah penggajian,
masalah inventory, atau masalah pengendalian lalu lintas udara
• pernyataan masalah dalam sudut pengembang misalnya : masalah relational data
bases, masalah algoritma sorting.
• Teknik-teknik yang digunakan untuk mendapatkan informasi kebutuhan
pelanggan meliputi : wawancara dengan pelanggan, pengamatan terhadap gugus
tugas yang bermasalah, kinerja sebenarnya dari gugus tugas.
2. Rancang sebuah strategi solusi berbasis komputer.
• Solusi harus ekonomis dan dapat diterima secara sosial maupun secara politik.
• Solusi yang ekonomis adalah sistem komputerisasi yang memberikan pelayanan
dan informasi yang sama dengan sistem lama tetapi membutuhkan waktu dan
personal yang lebih sedikit dalam pengoperasiannya.
• Sistem baru mungkin akan mengurangi keterlibatan personal; hal ini mungkin
akan menimbulkan dampak sosial, bahkan politik.
3. Identifikasi sumber daya yang tersedia.
• Tiga subsistem dalam sistem komputerisasi adalah : perangkat keras, perangkat
lunak, dan personal. Identifikasi juga keterkaitan antar ketiga subsistem tersebut.
• Subsistem perangkat keras meliputi perangkat keras beserta periferalnya, dan
dalam beberapa kasus juga meliputi peralatan lain seperti sensor kendali proses,
antena, dan radar.
• Subsistem perangkat lunak meliputi perangkat lunak yang akan dikembangkan
ditambah dengan perangkat lunak yang ada yang boleh jadi digunakan seadanya
atau dalam versi modifikasinya.
• Subsistem personal meliputi para operator, pemelihara, dan end user.
4. Tetapkan sasaran dan persyaratan, baik untuk proses pengembangan maupun produk.
• Sasaran adalah tujuan yang ingin dicapai. Sasaran digunakan sebagai dasar bagi
kerangka kerja proyek pengembangan perangkat lunak, baik dalam proses
pengembangan maupun untuk produk kerja.
• Sasaran dapat dinyatakan secara kualitatif maupun kuantitatif. Contoh :
♦ proses (kualitatif) : harus meningkatkan keterampilan personal
♦ proses (kuantitatif) : sistem harus selesai dalam 12 bulan
♦ produk (kualitatif) : sistem harus membuat pekerjaan user maikin menarik
♦ produk (kuantitatif) : sistem harus mengurangi biaya transaksi sebesar 25%.
• Persyaratan menetapkan spesifikasi kemampuan sistem dalam menyelesaikan
masalah.
• Persyaratan mencakup aspek-aspek : fungsional, kinerja, perangkat keras,
perangkat lunak, personal, dan pengantarmukaan.
• Kalau memungkinkan, nyatakan persyaratan secara kuantitaif untuk menghindari
ketidakjelasan dan perselisihan antara pengembang dengan pelanggan.
• Contoh persyaratan kuantitatif :
♦ akurasi sudut fase harus berada pada kisaran 0.5 derajat
♦ tanggapan maksimum terhadap interrup adalah 0.25 detik
♦ space maksimum yang digunakan sistem adalah 50 KB memori utama, tidak
termasuk space untuk file-file buffer
♦ sistem harus dapat beroperasi dengan kemampuan 95% ketika dioperasikan
selama 24 jam penuh
• Contoh persyaratan kualitatif :
♦ akurasi harus cukup tinggi
♦ sistem harus mempunyai tanggapan yang baik
♦ sistem harus hemat dalam penggunaan memori utama
♦ keandalan sistem harus 99%
• Sasaran dan persyaratan dapat juga ditetapkan melalui atribut-atribut kualitas
yang harus dimiliki sistem, di antaranya : portability (S/W tidak bergantung
mesin), realiability (kemampuan program melakukan fungsi yang diinginkan),
efficiency (menggunakan sumber daya minimal), accuracy (ukuran besarnya
error), robustness/integrity (kemampuan bekerja dengan baik walau mendapat
input yang tidak benar), correctness (hasil sesuai dengan yang diharapkan).
5. Tetapkan kriteria penerimaan sebuah sistem
• Kriteria harus dinyatakan sedemikian rupa sehingga tidak akan menimbulkan
perselisihan antara pengembang dan pelanggan. Kriteria harus dapat diverfikasi
dengan suatu metoda baku seperti : peninjauan langsung, analisa, atau
serangkaian uji, terhadap produk yang dihasilkan.
B. Pengembangan Strategi Solusi
• Kecenderungan untuk menerima begitu saja solusi pertama yang terlintas di benak
kita adalah masalah utama dalam perkeayasaan perangkat lunak. Ini tidak memberi
peluang terhadap solusi lain yang sebenarnya masih mungkin untuk dipertimbangkan.
• Kembangkan strategi solusi. Strategi bukan merupakan solusi rinci tetapi penyataan
umum tentang sifat-sifat dari solusi yang mungkin.
• Langkah-langkah pengembangan strategi solusi adalah sebagai berikut :
1. Uraikan beberapa strategi solusi tanpa memperhatikan batasan-batasan apapun
2. Adakan studi kelayakan terhadap setiap strategi. Perhatikan bahwa an unreasonable
idea will lead to other ideas, some of which may be very reasonable.
3. Rekomendasikan sebuah strategi solusi, beri catatan mengapa solusi lain ditolak
4. Buat sebuah daftar prioritas karakteristik produk. Daftar ini penting jika kondisi tidak
memungkinkan untuk mengimplementasikan seluruh kemampuan produk yang
diinginkan seperti yang telah ditentukan sebelumnya.
C. Perencanaan Proses Pengembangan
1. Tentukan sebuah model life-cycle dan struktur organisasi proyek.
2. Rencanakan konfigurasi managemen, jaminan kualitas, dan kegiatan validasi
3. Tentukan tools setiap fase proyek, serta teknik-teknik dan notasi yang digunakan
4. Tetapkan perkiraan biaya untuk pengembangan sistem
5. Tetapkan jadwal pengembangan
6. Tetapkan perkiraan susunan personalia proyek
7. Tetapkan perkiraan sumber daya sistem komputaerisasi yang diperlukan untuk
mengoperasikan dan memelihara sistem
8. Siapkan daftar istilah
9. Identifikasi sumber-sumber informasi dan jadikan sebagai acuan proyek
Life Cycle
Life-cycle sebuah perangkat lunak mencakup semua kegiatan yang yang perlu dilakukan
untuk mendefinisikan, mengembangkan, menguji, mengantarkan, mengoperasikan, dan
memelihara produk perangkat lunak. Beberapa model yang akan dibahas adalah : model
fase (phased model), model biaya (cost model), model prototipe (prototype model), dan
model berurutan (successive model).
Model Fase
Model ini membagi life cycle ke dalam sederetan kegiatan (fase). Setiap fase
membutuhkan informasi masukan, proses, dan produk yang terdefinisi dengan baik.
Deretan fase tersebut adalah : analisa, perancangan, implementasi, pengujian, dan
pemeliharaan. Berikut ini model fase dasar yang dinyatakan sebagai waterfall chart :
Analisis Perancangan Implementasi Pengujian Pemeliharaan
-perencanaan
-penetapan
persyaratan
arsitektur
rinci
verifikasi
coding, debugging,
dan uji code
verifikasi
– uji integrasi
– uji penerimaan
verifikasi
verifikasi – peningkatan
– adaptasi
– perbaikan
Life cycle mode fase dari sebuah perangkat lunak
• Subfase perencanaan menghasilkan dua produk : System Definition dan Poject Plan.
Format kedua produk adalah sebagai berikut :
Format System Definition Format Project Plan
Bab 1 : Pendefinisian masalah Bab 1 : Model life cycle : terminologi, tonggak penting,
Bab 2 : Justifikasi sistem produk kerja
Bab 3 : Sasaran sistem dan proyek Bab 2 : Struktur organisasi : struktur manajemen/
Bab 4 : Batasan sistem dan proyek struktur team, gambaran kerja
Bab 5 : Fungsi yang harus disiapkan Bab 3 : Perkiraan personal & persyaratan sumber daya
(H/W, S/W, personal) Bab 4 : Jadwal awal pengembangan
Bab 6 : Karakteristik pengguna Bab 5 : Perkiraan awal biaya
Bab 7 : Lingkungan pengembangan/ Bab 6 : Pengawasan proyek dan mekanisme kontrol
operasi/pemeliharaan Bab 7 : Alat bantu dan teknik yang digunakan
Bab 8 : Strategi solusi Bab 8 : Bahasa pemrograman
Bab 9 : Prioritas gambaran sistem Bab 9 : Persyaratan pengujian
Bab 10: Kriteria penerimaan sistem Bab 10: Dokumen pendukung yang diperlukan
Bab 11: Sumber informasi Bab 11: Cara demonstrasi
Bab 12: Daftar istilah Bab 12: Jadwal dan materi pelatihan
Bab 13: Rencana pemasangan (instalasi)
Bab 14: Pokok perhatian dalam pemeliharaan
Bab 15: Metoda dan waktu pengantaran
Bab 16: Metoda dan waktu pembayaran
Bab 17: Sumber informasi
• Subfase penetapan persyaratan menghasilkan sebuah produk : Software Requirements
Specifications. Format produk ini adalah sbb :
Format Software Requirements Specifications
Bab 1 : Gambaran dan penjelasan ringkasan produk
Bab 2 : Lingkungan pengembangan, pengoperasian, dan pemeliharaan
Bab 3 : Pengantarmukaan eksternal dan aliran data : format tampilan, user command,
DFD, kamus data
Bab 4 : Persyaratan fungsional : fungsi-fungsi yang diinginkan
Bab 5 : Persyaratan kinerja : tanggapan, waktu proses
Bab 6 : Penanganan kesalahan : aksi dan pesan yang harus dilakukan sebagai
tanggapan atas input atau situasia yang tidak dikehendaki produk
Bab 7 : Subset permulaan dan prioritas implementasi : ‘versi’ awal produk
Bab 8 : Perkiraan modifikasi dan peningkatan
Bab 9 : Kriteria penerimaan
Bab 10 : Petunjuk dan panduan perancangan
Bab 11 : Index acuan
Bab 12 : Daftar istilah
• Fase perancangan melakukan identifikasi terhadap komponen perangkat lunak
(fungsi, arus data, penyimpanan data), hubungan antar komponen, struktur perangkat
lunak (dekomposisi menjadi modul-modul dan pengatarmukaannya). Fase ini
menghasilkan arsitektur rinci, terutama dalam bentuk algoritma-algoritma.
• Fase implementasi adalah terjemahan langsung arsitektur rinci ke dalam bahasa
pemrograman tertentu.
• Subfase uji integrasi melakukan pengujian terhadap semua modul dan
pengantarmukaan sehingga pada level sistem dapat beroperasi dengan benar
• Subfase uji penerimaan melakukan baerbagi pengujian mengacu kepada berbagai
persyaratan yang telah ditentukan.
• Kegiatan yang meliputi fase pemeliharaan adalah : peningkatan kemampuan, adaptasi
terhadap lingkungan pemrosesan, dan melakukan berbagai koreksi atas kesalahan
yang terjadi
Penilaian kemajuan proyek akan lebih mudah jika pada model fase tersebut ditetapkan
beberapa tonggak penting (milestone) yang pada setiap fase atau antar setiap dua fase
yang berurutan. Berikut ini Life cycle mode fase dari sebuah perangkat lunak yang
dilengkapi dengan kegiatan review dan tonggak penting :
Analisis Perancangan Implementasi Pengujian Pemeliharaan
-perencanaan
-penetapan
persyaratan
arsitektur
rinci
verifikasi
coding, debugging,
dan uji code
verifikasi
– uji integrasi
– uji penerimaan
verifikasi
verifikasi – peningkatan
– adaptasi
– perbaikan
PFR SRR PDR CDR SCRs ATR PRR
PPM
Review Produk Kerja yang direview
PFR (Product Feasibility Review) System Definition
Project Plan
Spsesifikasi persyaratan perangkat lunak
SRR (Software Requirements Review) User’s Manual awal
Rencana awal verifikasi
PDR (Preliminary Design Review) Dokumen disain arsitektur
CDR (Critical Design Review) Spesifikasi disain rinci
SCR (Source Code Review) Penelusuran dan Pemeriksaan source code
ATR (Acceptance Test Review) Rencana uji penerimaan
PRR (Product Release Review) Semua produk kerja sebelumnya
PPM (Project Post-Mortem) Catatan umum pelaksanaan proyek
Model Biaya
Model biaya adalah cara pandang lain model fase sebuah perangkat lunak dengan cara
memperhatikan biaya berbagai kegiatan dalam proyek perangkat lunak. Biaya proyek
adalah jumlah biaya dari setiap fase proyek. Biaya setiap fase mencakup biaya kegiatan
dan penyiapan produk pada fase tersebut ditambah dengan biaya verifikasi konsistensi
produk suatu fase terhadap semua fase sebelumnya.
Plan
Verify
SD SD : System Definition, Project Plan
S/W
requirements
analysis
Modify SD Fix SD
Verify Verify Verify
SRS SRS : Software Requirement Spesification, preliminary User’s Manual
Design Modify SD/SRS Fix SD/SRS
Verify Verify Verify
DD DD : Software Design Spesification, Software Verification Plan
Build Modify SD/SRS/DD Fix SD/SRS/DD
Verify Verify Verify
SC SC : Source Code, Acceptance Test Plan
System test Modify SD/SRS/DD/SC Fix
SD/SRS/DD/SC
Verify Verify Verify
SS SS : Source Code, User’s Manual, Principles of Operation
Operate and Maintain Modify
SS
Adapt
SS
Fix SS
Verify Verify Verify Verify
Ada 2 sisi penting dari model biaya :
• Karena modl biaya hanyalah cara pandang lain dari model fase maka semua dokumen
yang dihasilkan tepat sama dengan yang dihasilkan pada model fase.
• Biaya verifikasi, apalagi perbaikan, atas suatu produk akan makin besar jika produk
tersebut dihasilkan oleh suatu fase yang jauh di belakang fase saat verifikasi
dilakukan.
Model Prototipe
Marketing Business Customer Internal
Requirements Plans Request Request
Authorize
Feasibilty
Study
Preliminary Preliminary
Requirements Requirements
Analysis Spesification
Autorize
Prorotype
Prototype
Formal Preliminary Implementation Implementation Preliminary
Equirements Design Design Plan Test Plan
Spesification Spesification Code
Test
Demo
Authorize
Project
Final Product Final Maintenance
Design Implementation Test Spesification
Spesification Detailed design Spesification
Coding
Checkout
Integration
Document Quality
Demo Assurance
Final
Validation Evaluation
Report
Product
Release
Beberap catatan tentang model prototipe :
• Sebuah prototipe adalah model dari sebuah produk perangkat lunak tetapi dengan
beberapa keterbatasan, misalnya : keterbatasan kemampuan, keandalan yang rendah,
dan kinerja yang tidak efisien.
• Alasan penggunaan model prorotipe adalah :
1. untuk menggambarkan format data masukan, pesan-pesan, laporan, dan dialog
interaktif
2. untuk mengeksplorasi isu-isu teknis dalam produk yang diusulkan
3. model fase ‘analisis → perancangan → implementasi’ tidak dapat digunakan
Versi Succesive
Planning &
analysis
Design
Versi I
Build
Version I
Assess
Version I
No
Good ?
Maintenance
Planning &
analysis
Design
Versi I
I = 1..N
Build
Version I
Assess
Version I
No
I=N?
Maintenance
Perancangan dan implementasi model
berurutan
Analisa dan perancangan yang diikuti
implementasi dari model berurutan
Perencanaan Struktur Organisasi
Struktur Pelaksana Proyek
Ada 3 format struktur pelaksana proyek : format proyek, format fungsional, dan formta
matriks
1. Format Proyek
• Dibentuk sebuah team yang melakukan pekerjaan proyek dari awal sampai akhir
• Annggota team mendefinisikan produk, merancang produk, mengimplementasikan,
melakukan uji, melakukan review, dan mempersiapkan dokumen-dokumen
pendukung
• Sebagian anggota team melakukan instalasi dan pemeliharaan, dan melanjutkan ke
proyek baru
• Team proyek biasanya bekerja selama 1-3 tahun dan ditugaskan untuk proyek
berikutnya jika proyek pertama sudah selesai
2. Format Fungsional
• Dalam format ini dibentuk beberapa team untuk melaksanakan pekerjaan proyek
setiap fase. Semua team tidak dibentuk pada saat yang sama. Anggota team dapat
dirotasi.
• Team analisis dan perancangan bertugas untuk mengembangkan System Definition
(SD) dan Project Plan (PP).
• Team pendefinisian produk menerima produk SD dan PP, melakukan analisa persyaratan
perangkat lunak, dan menyiapkan Software Requirement Specification (SRS).
• Team perancangan merancang produk yang sesuai dengan SRS dan SD.
• Team implementasi mengimplementasi, debugging, dan melakukan uji per unit
sistem
• Team uji sistem melakukan uji integrasi
• Team kualitas melakukan sertifikasi terhadap semua produk kerja
• Team pemelihara melakukan pemeliharaan produk
3. Format matriks
• setiap gugus fungsional memiliki team manajemen dan kelompok spsialis yang hanya
melaksanakan fungsinya sendiri.
General
Management
Development Services Publications Test Maintenance
Product
manager 1
Subproject 1 Subproject 1 Subproject 1 Subproject 1 Subproject 1
Product
manager 2
Subproject2 Subproject 2
Product
manager 3
Subproject3 Subproject 3 Subproject3
Struktur Tim Pemrograman
Demokrasi
Struktur Jalur komunikasi
• Berbagai keputusan dilakukan melalui kesepakatan kelompok
• Kepemimpinan berotasi sesuai dengan jenis pekerjaan yang sedang dilaksanakan dan
spesialisasi anggota
Kepemimpinan
pimpinan
Pustakawan
back-up
programmer
Programer
Struktur Jalur Komunikasi
• pimpinan merancang produk, mengimplementasikan bagian kritis dari produk, dan
membuat semua keputusan teknis utama
• programer menuliskan source code, debugging, dokumentasi, dan uji unit
• pustakawan mengurus listing program, merancang dokment-dokumen, membuat
rencana uji
back-up programmer berperan sebagai konsultan bagi pimpinan untuk berbagai masalah
teknis, memelihara hubungan dengan pelanggan dan kelompok publikasi serta kelompok
jaminan kualitas, dan melakukan sejumlah analisis-perancangan-implementasi di bawah
pengawasan pimpinan.
PERANCANGAN PERANGKAT LUNAK
Oleh : Asep Juarna, SSi, MKom
III. Perkiraan Biaya Perangkat Lunak
3.1. Faktor-faktor yang mempengaruhi perkiraan biaya
• Sulit untuk menentukan perkiraan biaya secara akurat selama fase perencanaan pengembangan
S/W karena terlalu banyaknya faktor yang tidak diketahui pada saat itu.
• Perkiraan awal disiapkan selama fase perencanaan dan dikemukakan pada saat
presentasi kelayakan proyek. Perbaikan dikemukakan pada saat presentasi persyaratan
S/W, dan perkiraan akhir dikemukakan pada saat presentasi perancangan awal.
• Faktor-faktor utama yang mempengaruhi biaya perangkat lunak : (1) kemampuan
programmer, (2) kompleksitas produk, (3) ukuran produk, (3) waktu yang tersedia,
(4) keandalan yang diperlukan, (5) tingkat teknologi.
1. Kemampuan Programmer
Programmer dengan produktivitas tinggi ekuivalen dengan biaya yang kecil.
2. Komplekasitas Produk
• Tiga katagori produk : aplikasi, utility, dan system
• Rasio kompleksitasi ketiganya adalah :
aplikasi : utility : system = 1 : 3 : 9
• Jika PM adalah total upaya (dalam
programmer-months) dan KDSI adalah
baris instruksi dalam product (thousands
of delivered source instructions) maka
estimator PM menurut Boehm adalah :
aplikasi : PM = 2.4 × (KDSI)1.05
utility : PM = 3.0 × (KDSI)1.12
system : PM = 3.6 × (KDSI)1.20
• Untuk jumlah baris program 60.000, rasio
PM aplikasi : utility : system ≈ 1 : 1.7 : 2.8
(tepatnya 176.6 : 294.2 : 489.6).
(Lihat gambar)
PM
500 system
400 utility
300
200 aplikasi
100
0 20 40 60 80 KDSI
Estimasi upaya COCOMO
• Jika TDEV adalah waktu (dalam bulan) pengembangan sebuah program (development
time), maka estimator TEDV menurut Boehm TDEV adalah :
aplikasi : TDEV = 2.5 × (PM) 0.38
utility : TDEV = 2.5 × (PM) 0.35
system : TDEV = 2.4 × (PM) 0.32
• Untuk jumlah baris program 60.000, ketiga program memerlukan waktu
pengembangan sekitar 18 bulan (tepatnya TDEV aplikasi : utility : system = 17.9 :
18:3 : 17.4).
• Rata-rata jumlah programmer yang diperlukan untuk membuat 60 KDSI per bulan
adalah :
aplikasi : 176.6 PM / 17.9 Months = 9.9 programmer
utility : 294.2 PM / 18.3 Months = 16.1 programmer
system : 489.6 PM / 17.4 Months = 28.1 programmer
3. Ukuran Produk
• Beberapa persamaan lain yang menyatakan upaya (PM) dan jadwal (TDEV)
berdasarkan berbagai penelitian tersaji pada tabel berikut :
Upaya Jadwal Author
PM = 5.2 × (KDSI) 0.91 TDEV = 2.47 × (PM) 0.35 Waltson
PM = 4.9 × (KDSI) 0.98 TDEV = 3.04 × (PM) 0.36 Nelson
PM = 1.5 × (KDSI)1.02 TDEV = 4.38 × (PM) 0.25 Freburger
PM = 2.4 × (KDSI)1.05 TDEV = 2.50 × (PM) 0.38 Boehm
PM = 3.0 × (KDSI)1.12 TDEV = 2.5 × (PM) 0.35 Boehm
PM = 3.6 × (KDSI)1.20 TDEV = 2.4 × (PM) 0.32 Boehm
PM = 1.0 × (KDSI)1.40 − Jones
PM = 0.7 × (KDSI)1.50 − Halstead
PM = 28 × (KDSI)1.83 − Schneider
• Berdasarkan persamaan milik Boehm, PM = 2.4 × (KDSI)1.05 , upaya akan meningkat
faktor 2.07 jika ukuran produk (KDSI) diperbesar 2 kali, dan naik dengan faktor
11.22 jika ukuran produk diperbesar 10 kali. Ini menunjukkan bahwa pengembangan
produk S/W yang besar akan lebih mahal.
• Peningkatan upaya untuk keseluruhan formula berkisar antara 1.88 s/d 3.56 jika
KDSI diperbesar menjadi dua kalinya, dan antara 8.13 s/d 67.61 jika KDSI diperbesar
menjadi sepuluh kalinya.
4. Waktu Yang Tersedia
• Berbagai penelitian (kecuali Putnam) menunjukkan bahwa proyek S/W membutuhkan
upaya lebih jika waktu pengembangan diperpendek atau diperpanjang (dimodifikasi)
dari waktu normal.
Putnam
Upaya Relatif 1.4 RCA
=
Nor
Mod
U
U
1.3 US Air Force
1.2
1.1 Boehm
1.0
0.5 0.75 1.0 1.25 1.5
0.9 Jadwal Relatif =
Nor
Mod
T
T
• Menurut Putnam upaya proyek S/W berbanding terbalik dengan pangkat empat dari
waktu pengembangan, yaitu : PM = k/((TDEV) 4 ).
• Berdasarkan formula Putnam maka perpanjangan jadwal 2 kali jadwal normal akan
menurunkan upaya 100 programmer dalam satu bulan menjadi : (100/2 4 ) = 6.25
programmer. Lebih tidak masuk akal bahwa lagi upaya akan menjadi nol jika jadwal
pengembangan menjadi tak hingga.
• Putnam juga mengisyaratkan bahwa kompresi jadwal terbatas sampai 86% jadwal
normal, walaupun menurut formulanya kompresi sebesar ini hanya akan menaik-kan
jumlah personal sebesar 1.82 kalinya.
• Melalui penelitian terhadap 63 proyek perangkat lunak, Boehm mencatat bahwa
hanya 4 proyek yang memungkinkan dilakukannya kompresi jadwal menjdi kurang
dari 75% jadwal awal. Berdasarkan penelitian ini Boehm menyatakan bahwa
kompresi terhadap jadwal tidak dapat dilakukan di bawah 75%.
5. Tingkat Keandalan Yang Diperlukan
Lima katagori keandalan, efek kegagalan, beserta pengali upaya (effort multiplier)
pengembangan yang direkomendasikan Boehm ditunjukkan melalui tabel berikut :
Katagori Efek kegagalan Pengali upaya
Sangat rendah tidak nyaman digunakan 0.75
Rendah kesalahan mudah dipulihkan 0.88
Nominal tidak terlalu sulit memulihkan kesalahan 1.00
Tinggi kerugian finansial tinggi 1.15
Sangat tinggi resiko terhadap kehidupan manusia 1.40
6. Tingkat Teknologi
• Tingkat teknologi dalam proyek pengambangan S/W direfleksikan dengan empat
komponen yang digunakan, yaitu : (1) bahasa pemrograman, (2) mesin abstrak (H/W
dan S/W), (3) praktek-praktek pemrograman, dan (4) tools
• Bahasa Pemrograman : Sebaris statement program dalam high level language identik
dengan beberapa baris statement dalam low level language, dengan demikian
penggunaan high level language akan menaikkan produktivitas 5 sampai 10 kalinya.
• Mesin Abstrak : Mesin abstrak adalah sekumpulan fasilitas H/W dan S/W yang
digunakan selama proses pengembangan. Produktivitas akan buruk jika programmer
harus belajar lebih dahulu mesin dan lingkungan baru sebagai bagian dari proses
pengembangan.
• Praktek-Praktek Pemrograman : Praktek pemrograman modern meliputi : (1) analisis
sistematik dan teknik-teknik perancangan, (2) notasi perancangan terstruktur, (3)
pemeriksaan, (4) pengkodean (coding) terstruktur, (5) pengujian yang sistematis, dan
(6) perpustakaan pengembangan program.
• Tools : Tools yang berwujud S/W terdiri dari : assembler dan debugger, compiler dan
linker, DBMS, dan tools lain yang lebih advanced.
• Pengali upaya dalam praktek pemrograman yang direkomendasikan Boehm bervariasi
antara 1.24 (tanpa praktek pemrograman modern) sampai 0.82 (sepenuhnya
menggunakan praktek pemrograman modern), antara 1.24 (menggunakan tools dasar
seperti compiler dan debugger) sampai 0.83 (menggunakan tools pengembangan yang
paling advanced).
3.2. Teknik-teknik perkiraan biaya S/W
• Perkiraan biaya S/W seringkali bersandar kepada data historis.
• Perkiraan biaya bisa dilakukan secara top-down atau bottom-up.
• Top-down : fokus pertama adalah perkiraan biaya tingkat sistem seperti sumber daya
komputasi, personal yang diperlukan, pengaturan konfigurasi perangkat lunak,
jaminan kualitas, integrasi sistem, pelatihan, dan publikasi.
Bottom-up : fokus pertama adalah perkiraan biaya pengembangan setiap modul atau
subsistem, sedemikian rupa sehingga sampai pada perkiraan biaya sistem secara
keseluruhan.
• Teknik top-down sangat baik dalam memandang sistem secara keseluruhan, tetapi
kadang-kadang melupakan berbagai masalah teknis pada pengembangan beberapa
modul.
• Teknik bottom-up menekankan perkiraan biaya setiap modul, tetapi kadang-kadang
gagal dalam mengakomodasi perkiraan biaya level sistem seperti pengaturan
konfigurasi perangkat lunak dan jaminan kualitas.
1. Pendapat Pakar (Expert Judgment)
• Teknik ini merupakan teknik perkiraan biaya yang sering digunakan yang juga
merupakan teknik top-down.
• Contoh proses perkiraan seorang pakar adalah sbb.:
i. Sistem yang akan dikembangkan adalah sebuah sistem kendali proses yang mirip
dengan sistem yang dikembangkan tahun lalu dengan biaya US$ 1 juta dan waktu
10 bulan.
ii. Tidak ada pembengkakan biaya (mark-up) tetapi mempertimbangkan keuntungan
yang cukup baik.
iii. Diinginkan sistem yang mempunyai fungsi kendali 25% lebih aktif sehingga
perkiraan waktu dan biaya akan dinaikkan sebesar 25%.
iv. Dalam pengambangan tersebut digunakan komputer dan peralatan lain serta
personal yang sama dengan yang digunakan pada pengembangan sistem
sebelumnya sehingga perkiraan biaya dapat direduksi sebesar 20%.
v. Kita dapat memanfaatkan cukup banyak code produk sebelumnya sehingga
mereduksi waktu dan biaya sebesar 25%.
vi. Berbagai pertimbangan di atas menghasilkan perkiraan sebesar :
Biaya : 125% × US$ 1 juta × 80% × 75% = US$ 750 ribu
Waktu : 125% × 10 bulan × 75% = 9.4 bulan
vii. Untuk nyamannya kita bisa melakukan pengajuan proyek sebesar US$ 850 ribu
dalam 10 bulan.
2. Estimasi biaya Delphi (dikenal juga sebagai : Group Consensus)
Sangat mungkin pendapat seorang pakar berbeda dengan pendapat pakar lainnya.
Untuk itu perlu dilakukan sebuah konsensus. Teknik Delphi adalah teknik yang
memungkinkan dilakukannya konsensus ini. Teknik ini termasuk teknik top-down,
dengan langkah-langkah sebagai berikut :
i. Seorang koordinator menyebarkan dokumen System Definition dan formulir yang
mencatat nilai usulan perkiraan biaya kepada setiap estimator.
ii. Setap estimator mempelajari System Definition dan mengisikan sebuah nilai
perkiraan biaya pada formulir yang tersedia, termasuk alasan-alasan atas nilai
perkiraan tersebut, tanpa mencantumkan namanya. Bila perlu setiap estimator
dapat mengajukan pertanyaan kepada koordinator tetapi dialog anatar para
estimator tidak diperbolehkan.
iii. Koordinator merangkum dan mengolah semua angka, menyebarkan form baru
yang disertai nilai rangkuman (nilai median perkiraan atau nilai rata-rata
perkiraan), serta catatan tentang pertimbangan khusus yang diberikan estimator.
iv. Setiap estimator kembali melakukan langkah (ii). Proses diulang beberapa
putaran, tergantung keperluan. Jika terdapat estimator yang memberikan nilai
perkiraan yang sangat berbeda dengan para estimator lainnya, dia dapat dimintai
penjelasannya.
Berikut ini contoh sebuah formulir perkiraan biaya :
Proyek : Sistem Operasi
Tanggal : 25 Agustus 2000
Selang nilai perkiraan hasil putaran ke-3
Nilai perkiraan anda
√ √ Programmer-months
0 20 40 60 80 100
Nilai Median
Nilai perkiraan anda untuk putaran berikutnya : 35 PM
Alasan atas nilai perkiraan :
Personal kita sudah berpengalaman dengan sistem seperti ini.
Mereka tidak akan menemui masalah. Saya menaikkan nilai
perkiraan saya karena mempertimbangkan channel DMA yang
disampaikan oleh salah seorang estimator.
3. Work Breakdown Structures (WBS)
WBS termasuk teknik bottom-up. WBS adalah diagram hirarkis yang mencantumkan
setiap subsistem. Dengan WBS dapat ditunjukkan hirarki produk maupun proses.
Hirarki produk memperlihatkan setiap komponen produk dan hubungan antar
komponen tersebut. Hirarki proses memperlihatkan aktivitas kerja dan hubungan
antar aktivitas tersebut.
Product
Input Transform Output
sistem subsistem subsistem
Read Parser Data Result
module validator computer
Hirarki produk WBS
Process
QA
Project Dvmt. System Services
Mgmt. test
Review Code Unit Computer Publi-
Plan and Design debug test Integration Accept services cations
audit
Hirarki proses WBS
4. Model Biaya Algoritmis
• Teknik ini termasuk teknik bottom-up. Teknik ini menghitung perkiraan biaya sistem
sebagai jumlah dari perkiraan biaya semua modul dan susbsistem yang membangun
sistem.
• Salah satu teknik ini yang terkenal adalah Constructive Cost Model (COCOMO) yang
digambarkan oleh Boehm.
• COCOMO menggunakan formula PM dan TDEV (lihat pasal 1). Selanjutnya pengali
upaya digunakan untuk koreksi terhadap perkiraan atribut-atribut produk, komputer,
personal, dan proyek.
• Berikut ini tabel beberapa pengali upaya COCOMO yang diperoleh dari penelitian
63 proyek perangkat lunak :
Pengali Selang Nilai
Atribut produk
Keandalan yang diinginkan 0.75 s/d 1.40
Ukuran database 0.94 s/d 1.16
Kompleksitas produk 0.70 s/d 1.65
Atribut komputer
Batasan waktu eksekusi 1.00 s/d 1.66
Batasan memori utama 1.00 s/d 1.56
Virtual machine volatiliry 0.87 s/d 1.30
Computer turnaround time 0.87 s/d 1.15
Atribut personal
Kapabilitas analist 1.46 s/d 0.71
Kapabilitas programmer 1.42 s/d 0.70
Pengalaman dengan aplikasi 1.29 s/d 0.82
Pengalaman dengan virtual machine 1.21 s/d 0.90
Pengalaman dengan bahasa pemrograman 1.14 s/d 0.95
Atribut proyek
Penggunaan praktek pemrograman modern 1.24 s/d 0.82
Penggunaan tools 1.24 s/d 0.83
Jadwal pengembangan yang diperlukan 1.23 s/d 1.1.0
Pengali upaya untuk contoh embedded system telekomunikasi
Pengali Dasar Pemikiran Nilai
Keandalan Penggunaan lokal. Tidak ada masalah pemulihan 1.00
kesalahan yang serius (nominal)
Database 20.000 byte (rendah) 0.94
Kompleksitas Pemrosesan tekomunikasi (sangat tinggi) 1.30
Timing Menggunakan 70% waktu pemrosesan (tinggi) 1.11
Storage 45 K dari 64 K yang tersedia (tinggi) 1.06
Machine Stabil. mikroprosesor pasaran sudah cukup (nominal) 1.00
Turnaround Rata-rata dua jam (nominal) 1.00
Analyst Senior (tinggi) 0.86
Programmer Senior (tinggi) 0.86
Pengalaman 3 tahun di bidang telekomunikasi (nominal) 1.00
Pengalaman 6 bulan di bidang mikroprosesor (rendah) 1.10
Pengalaman 12 bulan dengan bahas pemrograman (nominal) 1.00
Praktek > 1 tahun pengalaman dengan teknik modern (tinggi) 0.91
Tools Dasar (rendah) 1.10
Jadwal 9 bulan, perkiraan 8.4 bulan (nominal) 1.00
Faktor effort adjustment = 1.17 (hasil kali semua nilai)
Formula produk ini adalah : PM = 2.8 × (KDSI)1.20 dan TDEV = 2.5 × (PM) 0.32 . Jika
produk yang dikembangkan berukuran 10-KDSI maka PM = 44.4 dan TDEV = 8.4. Jika
faktor 1.17 dilibatkan maka akan diperoleh nilai perkiraan 51.9 programmer-bulan dan
waktu pengembangan 8.8 bulan. Selanjutnya jika diasumsikan biaya programmer dan
analyst adalah US$ 6000 per orang per bulan maka biaya total untuk kedua katagori
personal adalah (51.9 PM) × US$ 6000 = US$ 311.400.
3. Perkiraan tingkat staff
• Jumlah personal yang diperlukan sepanjang proyek pengembangan S/W tidak tetap.
Perencanaan dan analisis dilakukan oleh grup kecil personal. Perancangan arsitekstur
dilakukan oleh grup yang sedikit lebih besar. Perancangan rinci dilakukan oleh grup
yang besar. Implementasi dan pengujian memerlukan personal dalam jumlah terbesar
di antara fase-fase lainnya. Awal fase pemeliharaan melibatkan beberapa personal,
tetapi dengan cepat jumlah personal yang diperlukan tersebut menurun.
• Tahun 1958 Norden mencatat bahwa penelitian dan pengembangan proyek mengikuti
siklus : perencanaan, perancangan, prototipe, pengembangan, dan pemakaian.
Upaya
kurva proyek
Test dan modifikasi (25%)
spesifikasi validasi (20%)
rancangan Perluasan (10%)
fungsional
(~20%)
0 1 2 Waktu
Perancangan dan Manajemen (10%) Pemeliharaan (20%)
Coding (15%)
• Setiap kurva memenuhi persamaan Rayleigh :
E = K
t
t e
d 2
-t2 t
d 2
2
t d adalah waktu ketika kurva mencapai puncak. K adalah luas daerah di bawah kurva
yang menyatakan total upaya yang diperlukan untuk proyek pada fase tersebut, kirakira
40 % di kiri t d dan sisanya di kanan t d .
• Putnam menafsirkan bahwa t d berkaitan dengan waktu pengujian sistem dan
pemasaran produk. Tafsiran Putnam ditunjukkan pada gambar 3.8.
Boehm mengamati bahwa kurva Rayleigh dapat didekati dengan melibatkan faktor PM
dan TDEV sehingga persamaannya menjadi :
2
2
0.5 (TDEV)
(0.15 TDEV 0.7t)
2 e
0.25 (TDEV)
FSP = PM 0.15 TDEV + 0.7 t ×
− × +
 


 


×
×
× ×
dimana FSP = full-time software personal.
4. Perkiraan biaya pemeliharaan
• Jika rasio aktivitas (ACT) adalah cacahan instruksi yang ditambahkan dan
dimodifikasi pada suatu periode dibagi dengan cacahan instruksi total, yaitu :
ACT = (DSI add + DSI mod ) / DSI tot
• maka banyaknya programmer dalam satu bulan yang diperlukan untuk kegiatan
pemeliharaan adalah : PMm = ACT × PM dev
Jika EAF (effort adjutment facto) diketahui maka formula di atas menjadi :
PMm = ACT × EAF × PM dev

Rekayasa Perangkat Lunak Teknik Informatika UKDW
1
Konsep Desain Software
Disiapkan oleh Umi Proboyekti, S.Kom, MLIS
Analisis dan desain model
Setelah kebutuhan dikumpulkan, analisis terhadap kebutuhan dilakukan dengan
menggunakan beberapa alat (tools) seperti DFD (Data Flow Diagram), ERD
(Entity Relationship Diagram) dan STD (State Transition Diagram). Data
Dictionary menjadi bekal dasar untuk menganalisis kebutuhan. Data Dictionary
berisi gambaran dari semua objek data yang diperlukan dan dihasilkan oleh
software nantinya. Diagram-diagram tadi mempunyai karakteristik masingmasing.
DFD memberi gambaran bagaimana data berubah sejalan dengan
alirannya dalam sistem dan menggambarkan fungsi-fungsi yang mengubah datadata
tadi. ERD menggambarkan relasi antara objek data. STD menggambarkan
bagaimana kerja sistem melalui kondisi (state) dan kejadian yang menyebabkan
kondisi berubah. STD juga menggambarkan aksi yang dilakukan karena kejadian
tertentu.
Gambar 1: Data Flow Diagram
Gambar 2: Entity Relationship Diagram
user
processing
request
video
source NTSC
video signal
digital
video
processor
requested
video
signal
monitor
car
Manufacturer
builds
Rekayasa Perangkat Lunak Teknik Informatika UKDW
2
Gambar 3: State Transition Diagram
Hasil yang diperoleh dari analisis kebutuhan adalah model analisis yang kemudian
menjadi bekal untuk melakukan desain. Setiap bagian dari analisis model pada
gambar 4 sebelah kanan menjadi bekal pada proses desain pada piramida model
desain pada sebelah kiri gambar 4.
Gambar 4: hubungan antara model analisis dan model desain
Data
dictionary
Data Flow
Diagram
Entity-
Relationship
Diagram
State transition
diagram
Control spec
Process
spec
Data design
Architectural Design
Interface design
Component -
level design
design
Analysis Model Design Model
Data Object
Description
Reading
Operator
command
making copies reloading paper
problem state
full
invoke read-op-input
invoke managecopying
copies done
invoke read-op-input
empty
invoke reload paper
jammed
invoke problem-diagnosis
not jammed
invoke read-op-input
full and start
Rekayasa Perangkat Lunak Teknik Informatika UKDW
3
Model Desain
Data design mengubah informasi menjadi struktur data untuk
mengimplementasikan software. Data design dibuat berdasarkan data dictionary
dan ERD.
Architectural design mendefinisikan relasi antara elemen-elemen struktural
utama, pola desain yang digunakan untuk mencapai kebutuhan yang ditentukan
untuk sistem dan batasan-batasan yang mempengaruhi bagaimana desain
arsitektural ini diterapkan. Desain ini berdasarkan spesifikasi sistem, model
analisis (bagian DFD) dan interaksi antara subsistem.
Interface design menjelaskan bagaimana software berkomunikasi dalam dirinya,
dengan sistem yang bertukar informasi dengannya, dan dengan manusia yang
menggunakannya. DFD diperlukan untuk desain ini.
Component-level design menghasilkan deskripsi prosedur software.
Konsep desain
1. abstraction
Abstraction adalah gambaran dari fungsi suatu program. Gambaran ini bisa
bertingkat-tingkat. Tingkat yang paling atas adalah gambaran suatu fungsi
program dengan menggunakan bahasa alami. Pada tingkat terendah,
menghasilkan abstraksi yang bersifat prosedural/ langkah perlangkah dengan
menggunakan istilah yang teknis dan bisa diimplementasikan menjadi fungsi
program.
Pada saat beralih dari tingkat ke tingkat, kita menggunakan procedural dan data
abstraction. Procedural abstraction adalah urutan instrasi yang mempunyai
tujuan khusus,dan data abstraction adalah koleksi data yang digunakan pada
fungsi tersebut.
Contoh:
Program : Iklan Part-time Job
Fungsi: Pendaftaran calon part-timer
Abstraction 1 (highest level):
Calon part-timer dalam melakukan upload syarat-syarat yang diperlukan
untuk melamar: surat lamaran, CV, foto, transkrip, data diri.
Abstraction 2 (lower level):
Procedural abstraction :
_ tampilkan pilihan part-time job
_ input data
_ verifikasi format
Rekayasa Perangkat Lunak Teknik Informatika UKDW
4
_ kirim data
Data abstraction
_ nama is STRING
_ nim is STRING
_ foto is IMAGE FILE
_ surat_lamaran is PDF FILE
2. refinement—penjelasan detil dari abstraction
Refinement membantu designer untuk memperlihatkan detil dari lowest level dari
abstraction. Abstraction dan refinement merupakan konsep yang saling
melengkapi. Contoh dari refinement tentang fungsi sebuah pintu ada pada
gambar 5.
Gambar 5: hasil refinement fungsi sebuah pintu
3. modularity—membagi software menjadi modul
Software dibagi-bagi menjadi beberapa component yang disebut modul-modul.
Modul-modul ini nantinya disatukan/diintegrasikan untuk memenuhi kebutuhan
sistem. Dalam pembentukan modul-modul berlaku pernyataan-pernyataan
berikut:
Jika C(p1) > C(p2) dimana C adalah complexity dari suatu modul, maka E(p1) >
E(p2) dimana E adalah waktu yang diperlukan. Artinya semakin rumit sebuah
modul, maka waktu yang digunakan untuk menyelesaikan modul tersebut makin
banyak.
C(p1+p2) > C(p1) + C(p2)
Dan
open
walk to door;
reach for knob;
open door;
walk through;
close door.
repeat until door opens
turn knob clockwise;
if knob doesn’t turn, then
take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat
Rekayasa Perangkat Lunak Teknik Informatika UKDW
5
E(p1+p2) > E (p1) + E(p2)
Untuk itu, modul yang rumit dipecah lagi menjadi beberapa modul untuk
memudahkan penyelesaian masalah. Namun semakin banyak modul, maka
waktu/biaya untuk integrasikan modul-modul tersebut juga makin tinggi. Seperti
pada grafik pada gambar 6.
Gambar 6: Hubungan jumlah modul dan harga/biaya integrasi
4. software architecture—struktur software secara keseluruhan
struktur hirarki/berjenjang dari modul-modul program. Untuk menggambarkan
struktur modul-modul tersebut beberapa model yang ada adalah :
– framework model : identifikasi pola yang berulang-ulang
– dynamic model : identifikasi bagaimana konfigurasi sistem berubah karena
kejadian-kejadian tertentu
– process model: fokus pada proses teknis yang harus dikerjakan sistem
– functional model : menggambarkan hirarki sistem berdasarkan fungsinya
5. Software procedure
Fokus pada detil proses pada tiap modul. Prosedur menjelaskan proses, urutan
kejadian, proses perulangan, penentuan keputusan/arah. Ini bisa digambarkan
dengan menggunakan Flow Chart yang bertingkat.
6. Information hiding
Ide dari information hiding (menyembunyikan informasi) adalah modul dirancang
sedemikian rupa sehinga inforamsi (prosedur dan data) yang di dalamnya tidak
dapat di akses oleh modul lain yang tidak memerlukannya.
module development cost
cost of
software
number of modules
module
integration
cost
optimal number
of modules
Rekayasa Perangkat Lunak Teknik Informatika UKDW
6
Modul yang efektif adalah modul yang berdiri sendiri dan berkomunikasi dengan
modul lain yang memang diperlukan.
Desain Arsitektur Software
Suatu sistem, entah itu besar atau tidak, dibangun dari sub-sub sistem yang lebih
kecil. Sub-sub sistem ini memiliki fungsi sendiri-sendiri. Proses merancang untuk
menentukan sub-sub sistem dan membangun kerangka kerja untuk kendali dan
komunikasi antar sub sistem disebut design arsitektural. Proses merancang ini
menghasilkan arsitektur software atau arsitektur sistem. Desain arsitektur adalah
aktifitas desain yang pertama dalam pembangunan software seperti yang
digambarkan pada Gambar 1.
Gambar 1: Aktifitas Desain dan hasil rancangan
Desain arsitektur memberikan 3 keuntungan yaitu:
1. arsitektur software menjadi media komunikasi dan diskusi karena mudah
dipahami
2. memberi kemudahan dalam melakukan analisis terhadap software yang
akan dibangun
3. arsitektur-nya bisa digunakan lagi untuk sistem selanjutnya (reusable)
Tiap perancang sistem memiliki kemampuan dan pengetahuan yang berbeda
dalam merancang arsitektural. Aktifitas-aktifitas berikut adalah aktifitas dalam
merancang dan aktifitas ini tidak dikerjakan satu persatu berurutan, tapi bisa
dilakukan bersamaan.
Rekayasa Perangkat Lunak Teknik Informatika UKDW
7
1. Menyusun sistem (system structuring) : sistem disusun menjadi beberapa
subsistem utama, dimana subsistem adalah unit bagian software yang
berdiri sendiri.
2. Membuat model kendali (Control modelling) : berkaitan dengan hubungan
antara bagian dalam sistem.
3. Membuat pembagian sistem menjadi modul-modul (modular
decomposition) : membagi sub-sub sistem menjadi modul-modul
Untuk menghindari kesalahan dalam pemahaman terhadap istilah modul dan sub
sistem, perlu diketahui bahwa sub sistem adalah bagian dari sistem yang bisa
berdiri sendiri dan tidak bergantung pada layanan sub sistem lain. Sub sistem
terdiri dari beberapa modul dan dilengkapi interface untuk berkomunikasi/
bertukar data dengan sub sistem lain.
System Structuring (struktur sistem)
Struktur sistem menggambarkan sub-sub sistem dan interaksi antara sub-sub
sistem. Desain dengan menggunakan diagram-diagram untuk menggambarkan
sub sistem dan interaksinya agar mudah dipahami.
Beberapa model dari struktur sistem yang menjelaskan bagaimana sub sistem
berbagi data, bagaimana sub sistem terdistribusi dan bagaimana sub-sub sistem
saling berinteraksi adalah:
1.Repository Model
Pada model ini data disimpan secara terpusat. Ada dua cara terpusat pada model
ini:
1. Database terpusat dan dapat diakses oleh semua sub sistem dalam sistem
tersebut. Contoh : sistem informasi perpustakaan UKDW.
2. setiap sub sistem menyimpan database sendiri dan bisa bertukar data
dengan sub sistem lain melalui pengiriman pesan (message).
Diagram menggambarkan model ini seperti pada Gambar 2. Sub-sub sistem pada
Gambar 2 mendapatkan data dari repository (kumpulan data). Data tersimpan
secara terpusat pada satu tempat.
Rekayasa Perangkat Lunak Teknik Informatika UKDW
8
Gambar 2: Repository model
• Keuntungan
– Efisien untuk share jumlah data yang besar. Tidak perlu kirim data
secara langsung dari satu sub sistem ke sub sistem yang lain
– Sub-sistem tidak perlu memikirkan bagaimana data digunakan oleh
sub sistem lain.
– manajeman data seperti backup, keamanan, re-index, dan kontrol
akses dilakukan secara terpusat. Itu merupakan tanggung jawab
manager repository
• Kerugian
– Sub-system harus mengikuti model yang sudah ditetapkan.Jadi jika
ada sub sistem baru, maka yang baru harus menyesuaikan dengan
model yang ada.
– Evolusi data sulit dan mahal karena volume informasi yang besar
dihasilkan dengan model tertentu. Mengubahnya ke model yang
lain pun tidak mudah
– Sulit untuk distribusi layanan secara efisien, karena yang melayani
hanya satu.
Contoh untuk model repository dengan database terpusat adalah : sistem
informasi perpustakaan UKDW, sistem registrasi akademik UKDW
2. Client-Server Model
Model ini terdiri dari server yang berdiri sendiri dan menyediakan layanan untuk
client-client. Ada client-client (sub-sistem) yang menggunakan layanan server
dan tersedia network yang mengijinkan client untuk akses layanan dari server.
Komponen utama pada model ini :
1. Ada stand-alone server yang menyediakan layanan ke sub-sub sistem
Project
repository
Design
translator
Program
editor
Design
editor
Code
generator
Design
analyser
Report
generator
Rekayasa Perangkat Lunak Teknik Informatika UKDW
9
2. Ada sub sistem yang disebut juga client yang memanggil/mengakses
layanan di server-server
3. Ada jaringan memungkinkan sub-sub sistem mengakses layanan-layanan
pada server.
Untuk mengakses suatu server maka sub sistem atau client harus mengetahui
alamat atau nama server yang diakses dan juga layanan yang diberikan.
Sebaliknya, server tidak perlu tahu berapa client/sub sistem yang mengaksesnya
dan sub sistem mana yang menggunakan layanannya.
Arsitektur client server memiliki struktur yang terdiri dari 3 lapisan yang harus
ada yaitu:
1. business logic/ application
2. data management
3. presentation layer
Gambar 3 dan 4 adalah contoh-contoh dari model client-server, dimana ada
beberapa server dan client. Masing-masing server menyimpan datanya sendiri
dan setiap client bisa mengakses/menggunakan layanan pada tiap server.
Gambar 3 : Client-Server arsitektur
• Keuntungan
– Distribusi data secara langsung melalui jaringan
– Penggunaan sistem jaringan secara efektif –hardware jadi murah
– Mudah untuk tambahkan server baru atau up-grade server yang
sudah ada
• Kekurangan
– Tidak ada data model, jadi organisasi data macam-macam,
sehingga integrasi data sulit
– Redundant management
Catalog ue
s erver
Catalog ue
Video
s erv er
Fi lm cl ip
files
Pictu re
s erv er
Dig it iz ed
p hotog rap hs
Hy pertex t
s erv er
Hy pertex t
web
Client 1 Client 2 Client 3 Client 4
Wide-ban dwidth netwo rk
Rekayasa Perangkat Lunak Teknik Informatika UKDW
10
– Tidak ada pusat register nama dan service, sehingga kalau tidak
tahu nama server dan service-nya sulit ditemukan
– Manajemen data dilakukan pada tiap server, tidak terpusat karena
masing-masing server memiliki karakteristiknya sendiri.
Client server merupakan arsitektur terdistribusi. Bisa digunakan secara efektif
pada jaringan dengan prosesor yang terdistribusi.
Network
SC2 SC1
CC1 CC2 CC3
CC4 CC5 CC6
Server
computer
Client
computer
s1, s2 s3, s4
c5, c6, c7
c1 c2 c3, c4
c8, c9 c10, c11, c12
Gambar 4: Client-server arsitektur
Tiga lapisan pada client-server arsitektur menentukan model dari client-server.
Perbedaan model-model tersebut adalah pada distribusi 3 lapisan tersebut. Model
distribusi 3 lapisan client-server adalah : two-tier, three-tier dan n-tier (multitier).
Thin-client
model
Fat-client
model Client
Client
Server
Data management
Applicat ion
processing
Presentation
Server
Data
management
Presentation
Appl ication processing
2.1 Two-tier architecture:
_ Thin-Client model
Menempatkan business logic/application process dan data management pada
server dan presentation pada client. Server mengerjakan pekerjaan berat
Rekayasa Perangkat Lunak Teknik Informatika UKDW
11
yaitu menjalankan application process dan data management Contoh :
website
_ Fat Client model
Menempatkan business logic/application process dan presentation pada client
dan server hanya mengurusi data management. Contoh : suatu aplikasi
dibangun dengan VFP dan mengakses database Oracle. Semua application
process dan presentation di client yang menggunakan VFP.
2.2 Three-tier
Memisahkan secara logic, presentation yang ada di client dengan application
process yang berada terpisah secara logic dengan data management. Contoh:
Internet Banking system
Gambar 4
2.3 Distributed object arsitektur
Pada model ini komponen yang terpenting adalah objek yang menyediakan
antarmuka untuk layanan-layanannya guna dipanggil oleh objek lain. Masingmasing
objek dapat dipanggil oleh objek lain dalam sistem tersebut. Tidak ada
lagi pembagian client-server, karena tiap objek dapat berperan menjadi client
dan server bergantung pada operasi yang dilakukan. Jika objek tersebut
memberikan layanan pada objek lain, berarti objek yang memberi layanan
berperan sebagai server, dan objek yang menggunakan layanan berperan
sebagai client
Rekayasa Perangkat Lunak Teknik Informatika UKDW
12
3. Abstract Machine Model
Model ini juga disebut dengan layered model. Pada model ini sistem terdiri dari
serangkaian lapisan (layer) yang masing-masing menyediakan layanan-layanan
khusus. Setiap lapisan (layer) merupakan satu abstract machine yang layanannya
digunakan pada abstract machine pada tingkat berikutnya.
Gambar 5: Abstract Machine Model
_ Keuntungan
– mudah diubah
– perubahan yang terjadi pada satu lapisan hanya berpengaruh pada
lapisan yang terdekat
_ Kerugian
– akses terhadap satu layanan pada lapisan yang dalam tidak bisa
langsung karena harus melewati lapisan-lapisan sebelumnya
– kinerja sistem bisa jadi lambat karena harus melwati lapisan-lapisan
sebelumnya
Control Models (Model kendali)
Sub-sub sistem perlu kendali agar bisa bekerja sebagai suatu sistem. Model
struktur di atas tidak menggambarkan kendali, tapi model kendali yang
menjelaskan aliran kendali antar sub-sub sistem.
Dua pendekatan model kendali dan variannya yang umum adalah :
1. Centralised control
Satu sub-system bertanggung jawab untuk mengatur eksekusi sub-system
lain
Rekayasa Perangkat Lunak Teknik Informatika UKDW
13
_ The call-return model : Top-down subroutine model.Control mulai dari
paling atas dari hirarki subroutine dan mengalir ke bawah
Gambar 6 : Call Return Model
_ The manager model : Satu komponen sistem jadi manager dan
mengendalikan start-stop dan koordinasi proses sistem. Satu proses
adalah satu sub-sistem yang bisa dieksekusi secara paralel dengan
sub-sistem lain
Gambar 7 : Manager Model
2. Event-based control
3.2.1 broadcast model :
•Event di broadcast ke semua sub-system
•Sub-system register ke specific event, saat ini terjadi control
ditransfer ke sub-system yang handle event tersebut
•Sub-system tentukan event yang dibutuhkan
Sensor proses
Error handler
Computation
process
User interface
System
controler
Rekayasa Perangkat Lunak Teknik Informatika UKDW
14
Gambar 8: Contoh arsitektur broadcase model
3.2.2. interrupt-driven models
•Digunakan secara khusus pada real-time system yang
mendeteksi interupsi luar
•Memberikan respon yang cepat pada suatu kejadian
•Membutuhkan pemrograman yang rumit dan testing yang sulit.
•Contoh: Real-time system pada air safety bag di mobil
Gambar 9: Contoh arsitektur event-driven model
Modular Decomposition
Membagi sub-sistem menjadi beberapa modul. Ada 2 model dalam desain
arsitektur jenis ini:
1. Object-oriented Models
•Sistem dibagi-bagi menjadi objek-objek yang saling berkomunikasi
Rekayasa Perangkat Lunak Teknik Informatika UKDW
15
•Berkaitan dengan class yang terdiri dari atribut-atribut dan operasioperasinya.
•Perubahan pada object tidak mempengaruhi object lain
•Cenderung mudah dipahami karena mewakili keadaan objek yang
sebenarnya di dunia nyata
•Penggunaan layanan/service objek lain harus mengacu pada nama atau
antarmuka dari objek tersebut
2. Data Flow models
•Sistem dibagi-bagi menjadi fungsi-fungsi yang menerima input dan
mengubahnya menjadi output. Model ini juga disebut pendekatan pipeline
•Aliran data mengalir dari satu proses ke proses lain secara sekuensial dan
setiap proses merupakan transformasi data.
•Proses ada yang dilakukan secara sekuensial, tadi ada juga yang paralel
Diadaptasi dari:
1. Pressman, Roger.S. “Software Engineering : A Practioner’s Approach.” 5th .
McGrawHill. 2001.
2. Sommerville, Ian. “Software Engineering” .6th . Addison Wesley. 2001

Berikan Balasan

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Logout / Ubah )

Twitter picture

You are commenting using your Twitter account. Logout / Ubah )

Facebook photo

You are commenting using your Facebook account. Logout / Ubah )

Google+ photo

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s