MODEL PENGEMBANGAN PERANGKAT LUNAK

MODEL PENGEMBANGAN PERANGKAT LUNAK

MODEL PENGEMBANGAN PERANGKAT LUNAK

Perangkat  Lunak  Merupakan  program-program  komputer  dan  dokumentasi yang berkaitan. Produk perangkat lunak dibuat untuk pelanggan tertentu ataupun untuk pasar  umum terdiri dari  Generik – dibuat untuk dijual ke suatu kumpulan pengguna yang berbeda dan Bespoke  (custom)  –  dibuat  untuk  suatu pengguna  tunggal  sesuai  dengan spesifikasinya.  Rekayasa  perangkat  lunak  berasal  dari  2  kata  yaitu Software(  Perangkat Lunak) dan Engineering (Rekayasa). Perangkat  Lunak  (Software)  adalah  source code  pada  suatu  program  atau sistem.  Perangkat  lunak  tidak  hanya  dokumentasi  terhadap  source code  tapi juga  dokumentasi  terhadap  sesuatu  yang  dibutuhkan  selama  pengembangan, instalasi, penggunaan dan pemeliharaan sebuah sistem. Engineering atau Rekayasa adalah aplikasi terhadap pendekatan sistematis yang berdasar atas ilmu pengetahuan dan matematis serta aplikasi tentang produksi terhadap struktur,mesin, produk, proses atau sistem. Rekayasa Perangkat Lunak adalah suatu disiplin rekayasa yang berkonsentrasi terhadap seluruh aspek.

            Model – model dalam pengembangan perangkat lunak

a.            Protorype

Pendekatan Prototyping adalah proses literative yang melibatkan hubunan kerja yang dekat antara perancang dan pengguna.Pressman (2001) menyatakan bahwa seringkali seorang pelanggan mendefinisikan serangkaian sasaran umum bagi perangkat lunak, tetapi tidak mengidentifikasi kebutuhan input, pemrosesan, ataupun output detail. Pada kasus yang lain, pengembang mungkin tidak memiliki kepastian terhadap efisiensi algoritme, kemapuan penyesuaian dari sistem operasi, atau bentuk-bentuk yang harus dilakukan oleh interaksi manusia dan mesin. Dalam situasi seperti ini salah satu model yang cocok digunakan adalah model prototype (Prototyping paradigm). Model Prototype dapat dilihat pada gambar dibawah ini.

	Gambar 1 Prototype Paradigm

Pendekatan Prototyping melewati tiga proses, yaitu pengumpulan kebutuhan, perancangan, dan evaluasiPrototype.  Proses-proses tersebut dapat dijelaskan sebagai berikut:

1. Pengumpulan kebutuhan: developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya;
2. Perancangan: perancangan dilakukan cepat dan rancangan mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype;
3. Evaluasi Prototype: klien mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan software.

Perulangan ketiga proses ini terus berlangsung hingga semua kebutuhan terpenuhi. prototype-prototypedibuat untuk memuaskan kebutuhan klien dan untuk memahami kebutuhan klien lebih baik. Prototype yang dibuat dapat dimanfaatkan kembali untuk membangun software lebih cepat, namun tidak semua prototypebisa dimanfaatkan. Sekalipun prototype memudahkan komunikasi antar developer dan klien, membuat klien mendapat gambaran awal dari Prototype. Pendekatan ini memiliki beberapa keuntungan :

1. Pemodelan membutuhkan  partisipasi aktif dari end-user. Hal ini akan meningkatkan sikap dan dukungan pengguna untuk pengerjaan proyek. Sikap moral pengguna akan meningkat karena system berhubungan nyata dengan mereka.
2. Perubahan dan iterasi merupakan konsekuensi alami dari pengembangan system-sehingga end usermemiliki keinginan untuk merubah pola pikirnya. Prototyping lebih baik menempatkan situasi alamiah ini karena mengasumsikan perubahan model melalui iterasi kedalam system yang dibutuhkan.
3. Prototyping mematahkan folosofi “end user tidak mengetahui secara detail apa yang dibutuhkan sampai mereka melihat implementasinya”
4. Prototyping adalah model aktif, tidak pasif, sehingga end user dapat melihat, merasakan, dan mengalaminya.
5. Kesalahan yang terjadi dalam prototyping dapat dideteksi lebih dini
6. Prototyping dapat meningkatkan kreatifitas karena membolehkan adanya feedback dari end user.  Hal ini akan memberikan solusi yang lebih baik.
7. Prototyping mempercepat beberapa fase hidup dari programmer.

McLeod dan Schell (2001) mengemukakan bahwa alasan-alasan pemakai maupun spesialis informasi menyukai model prototype adalah:

1. Komunikasi antara analis sistem dan pemakai membaik;
2. Analis dapat bekerja dengan lebih baik dalam menemukan kebutuhan pemakai;
3. Pemakai berperan lebih aktif dalam pengembangan sistem;
4. Spesialis informasi dan pemakai menghabiskan lebih sedikit waktu dan usaha dalam mengembangkan sistem;
5. Implementasi menjadi lebih mudah karena pemakai mengetahui sistem yang diharapkan.

Tetapi, terdapat beberapa kelemahan dari prototyping, kelemahan tersebut antara lain :

1. Prototyping memungkinkan terjadinya pengembalian terhadap kode, implementasi, dan perbaikan siklus hidup yang dugunakan untuk mendominasi sistem informasi.
2. Prototyping tidak menolak kebutuhan dari fase analisis sistem. Prototype hanya dapat memecahkan masalah yang salah dan memberi kesempatan sebagai sistem pengembangan konvensional.
3. Perancangan issu numerik tidak dialamaykan oleh prototyping. Isu tersebut dapat dilupakan jika pengguna tidak berhati-hati.
4. Prototyping dapat mengurangi kreatifitas perancangan.

Prototyping terkadang dapat memberikan performansi yang lambat, membantu mendapatkan kebutuhan detil lebih baik namun demikian Prototype juga menimbulkan masalah:

1. Dalam membuat prototype banyak hal yang diabaikan seperti efisiensi, kualitas,  kemudahan dipelihara/dikembangkan, dan kecocokan dengan lingkungan yang sebenarnya. Jika klien merasa cocok dengan prototype yang disajikan dan berkeras terhadap produk tersebut, maka developer harus kerja keras untuk mewujudkan produk tersebut menjadi lebih baik, sesuai kualitas yang seharusnya.
2. Developer biasanya melakukan kompromi dalam beberapa hal karena harus membuat prototype dalam waktu singkat. Mungkin sistem operasi yang tidak sesuai, bahasa pemrograman yang berbeda, atau algoritma yang lebih sederhana.

Agar model ini bisa berjalan dengan baik, perlu disepakati bersama oleh klien dan developer bahwaprototype yang dibangun merupakan alat untuk mendefinisikan kebutuhan software.

b.            Transformasi Formal

Transformasi  formal  digunakan  untuk  mengembangkan  bagian ‐bagian  sistem yang  memiliki  persyaratan  keselamatan  yang  tinggi  dan  pendekatan  reuse digunakan  untuk  pengimplementasian  bagian ‐bagian  lain  dari  sistem  data  manajemen. Pendekatan  ini  berdasarkan  pembuatan  spesifikasi  sistem  formal  secara  matematik  dan  transformasi  spesifikasi  dengan  menggunakan  metode matematik atau dengan suatu program. Transformasi iniadalah correctness preserving, ini berarti bahwa kita dapat yakin program yang dikembangkan sesuai dengan spesifikasi. Pengembangan sistem formal menggunakan suatu model sistem matematika yangditransformasikan ke implementasi,

Pengembangan  sistem  formal  merupakan  pendekatan terhadap  pengembangan  perangkat  lunak  yang memiliki kesamaan  dengan  model  air  terjun,  tetapi  proses pengembangannya  didasarkan  pada transformasi  matematis dari  spesifikasi  sistem  menjadi  program  yang  dapat dijalankan.

Perbedaan  kritis  antara  pendekatan  evolusioner  dengan  air

terjun adalah:

-       Spesifikasi  persyaratan  perangkat  lunak  diperbaiki  menjadi spesifikasi  formal  yang  rinci  yang dinyatakan  dalam  notasi matematis.

-       Proses  pengembangan   perancangan,implementasi  dan pengujian  unit  digantikan  oleh  proses pengembangan transformasional  di  mana  spesifikasi  formal diperbaiki,melalui  serangkaian transformasi  menjadi program.

Masalah pengembangan sistem forma

-       Dibutuhkan  ketrampilan  dan  pelatihan  khusus untuk mengaplikasikan teknik ini

-       Kesulitan dalam menspesifikasikan beberapa aspek ke  dalam  sistem  misalnya  dalam penentuan  user interface

Applicability

-       System  kritis  khususnya  sistem  yang mengutamakan faktor keselamatan dan keamanan sebelum sistem utamanya dioperasikan

c.            RAD ( Rapid Aplication Development)

Rapid Application Development (RAD) adalah sebuah model proses perkembangan software sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Model RAD ini merupakan sebuah adaptasi “kecepatan tinggi” dari model sekuensial linier di mana perkembangan cepat dicapai dengan menggunakan pendekatan kontruksi berbasis komponen. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60 sampai 90 hari). Karena dipakai terutama pada aplikasi sistem konstruksi, pendekatan RAD melingkupi fase – fase sebagai berikut : bussiness modeling, data modeling, process modeling, application generation dan testing and turnover.

Model Pengembangan Sistem Informasi Berbasis Web, berikut adalah beberapa model pengembangan informasi berbasis web, yaitu :

-       Metode RAD (Rapid Application Development) merupakan metode pengembangan sistem 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).

-       Pemakai sistem dapat mendefinisikan kebutuhan perangkat lunak dengan baik.

-       Pemakai sistem bersedia meluangkan waktu yang cukup untuk berkomunikasi intensif dengan pengembang sehubungan dengan pengembangan perangkat lunak

Ø  Keuntungan RAD

Beberapa keuntungan dalam menggunakan metode RAD adalah sebagai berikut:

-      Membeli sistem yang baru memungkinkan untuk lebih menghemat biaya ketimbang mengembangkan sendiri.

-      Proses pengiriman menjadi lebih mudah, hal ini dikarenakan proses pembuatan lebih banyak menggunakan potongan-potongan script.

-      Mudah untuk diamati karena menggunakan model prototype, sehingga user lebih mengerti akan sistem yang dikembangkan.

-      Lebih fleksibel karena pengembang dapat melakukan proses desain ulang pada saat yang bersamaan.

-      Bisa mengurangi penulisan kode yang kompleks karena menggunakan wizard.

-      Keterlibatan user semakin meningkat karena merupakan bagian dari tim secara keseluruhan.

-      Mampu meminimalkan kesalahan-kesalahan dengan menggunakan alat-alat bantuan (CASE tools).

-      Mempercepat waktu pengembangan sistem secara keseluruhan karena cenderung mengabaikan kualitas.

-      Tampilan yang lebih standar dan nyaman dengan bantuan software-software pendukung.

Ø  Kerugian RAD

Beberapa kerugian dalam menggunakan metode RAD adalah sebagai berikut :

-      Dengan melakukan pembelian belum tentu bisa menghemat biaya dibanding-
kan dengan mengembangkan sendiri.

-      Membutuhkan biaya tersendiri untuk membeli peralatan-peralatan penunjang seperti misalnya software dan hardware.

-      Kesulitan melakukan pengukuran mengenai kemajuan proses.

-      Kurang efisien karena apabila melakukan pengkodean dengan menggunakan tangan bisa lebih efisien.

-      Ketelitian menjadi berkurang karena tidak menggunakan metode yang formal
dalam melakukan pengkodean.

-      Lebih banyak terjadi kesalahan apabila hanya mengutamakan kecepatan diban-
dingkan dengan biaya dan kualitas.

-      Fasilitas-fasilitas banyak yang dikurangi karena terbatasnya waktu yang tersedia.

-      Sistem sulit diaplikasikan di tempat yang lain.

-      Fasilitas yang tidak perlu terkadang harus disertakan, karena menggunakan komponen yang sudah jadi, sehingga hal ini membuat biaya semakin meningkat.

d.            Pengembangan Increment

Model incremental merupakanperbaikandari  model waterfall dansebagaistandarpendekatan top-down. Ide dasardari model iniadalahmembangun software secarameningkat (increment) berdasarkankemampuanfungsional. Model incremental inidiaplikasikanpadasistempakardenganpenambahan rules yang mengakibatkanbertambahnyakemampuanfungsionalsistem. Keuntungandari model iniadalahbahwapenambahankemampuanfungsionalakanlebihmudahdiuji, diverifikasi, dandivalidasidandapatmenurunkanbiaya yang dikeluarkanuntukmemperbaikisistem. Model incremental merupakan model continous rapid prototype dengandurasi yang diperpanjanghinggaakhir proses pengembangan. Pada model prototipebiasa, prototipehanyadibuatpadatahapawaluntukmendapatkankebutuhan user.

Mengadopsi model sekuensial linier dan model prototipe.Fungsidasarsama, tapiadatambahanasesoris (contoh :adaM.Word 1997, 2000). Fungsitambahanditambahkanterusuntukmembuatsistemmenjadilebihbaik.Pada increment pertamaperangkatlunak yang jadi, mengakomodasikebutuhaninti. Barupadatahapberikutnyaditambahkankemampuanbaru.Pada model ini, requirement software dipecahmenjadibeberapafungsi-fungsiataubagian-bagian.Sebuahdaftarkegiatan project akandibuatdenganmaksudmengetahuitiap-tiapfungsi yang harusdilakukandalamtiap unit. Masing-masing unit fungsionaldiimplementasikandalamsebuahpenambahandanprodukakhirnyadikembangkansetelahkeseluruhan unit fungsionaldiimplementasikandalam proses pengembangannya.Masing-masingpenambahanpadatiap unit terdiridari 3 fase: design, implementasi, dananalisis. Proses pengembanganiniakanterusdiulangsampaikeseluruhanakitivitasdalamdaftaraktivitasdiimplementasikan.

 Model incremental merupakanpersyaratan- persyaratan software dipecahkedalambeberapa unit fungsi.

Contoh :pengembanganmicrosoft word.

• Increment 1 : hanyamemberifungsiinti –>hanyabisamengetiksaja
• Increment 2 : bisa word art, spelling, dll

Kelebihanmodel :cocokuntukproduksimasal.

Masalahdengan Incremental model:

·         cocokuntukproyekberukurankecil (tidaklebihdari 200.000 baris coding)

·         mungkinterjadikesulitanuntukmemetakankebutuhanpenggunakedalamrencanaspesifikasimasing-masinghasil increment.

Perbandingan Model dalamRekayasaPerangkat Lunak

Setelahkitamembahasbeberapapermodelanrekayasaperangkatlunak, diantaranya model waterfall, model spiral, model incremental dan lain-lain, makadalampembahasan kali inikitaakanmembahasperbandingan model rekayasaperangkatlunaktersebut.Kita akanmembahas 3 model perbandingan, yaitu waterfall, spiral dan incremental.  Sebaiknya model tersebutdigunakanjika :

No	Faktor	Waterfall	Spiral	Incremental
1	Proyekdenganukuranresiko	Kecil	Sedang	Besar
2	Ukuran Software	Kecil	Besar	Besar
3	Jenisaplikasi	Biasa	Agakbiasa	Tidakbiasa
4	Fleksibelterhadapperubahan (waktu)	Rendah	Perubahanawal	Perubahanselamaproyekberlangsung
5	Keterlibatankonsumen	Rendah	Sedang	Tinggi
6	Bahasapemrograman	Prosedural	Prosedural, OOP	OOP

Kelebihan Incremental Model

• Memberikankualitasprodukoperasionalpadasetiaptahaptetapihanyasatu yang memenuhipersyaratandariklien
• Pihakkonsumendapatlangsungmenggunakandahulubagian-bagian yang telahselesaidibangun. Contohnyapemasukan data karyawan
• Mengurangi trauma karenaperubahansistem.  Kliendibiasakanperlahan-lahanmenggunakanproduknyabagian per bagian
• Memaksimalkanpengembalian modal investasikonsumen

Kekurangan Incremental Model                      

• tiapbagiantidakdapatdiintegrasikan
• setiaptambahan yang dibangunharusdimasukkankedalamstruktur yang adatanpamenurunkankualitasdari yang telahdibangun system tersebutsampaisaatini.
• Penambahanstafdilakukanjikahasil incremental akandikembangkanlebihlanjut

e.            Spiral

Model pengembangan software ini cukup baru dikenalkan oleh Barry Boehm di tahun 1988 didalam artikelnya yang berjudul “A Spiral Model of Software Development and Enhancement“[1].

Spiral Model merupakan penggabungan ide pengembangan berulang (prototyping) dengan, aspek sistematis terkendali model air terjun (waterfall). Model spiral juga secara eksplisit meliputi manajemen resiko dalam pengembangan perangkat lunak. Mengidentifikasi risiko utama, baik teknis maupun manajerial, dan menentukan bagaimana untuk mengurangi risiko membantu menjaga proses pengembangan perangkat lunak di bawah kontrol [2].

Spiral model dibagi menjadi beberapa framework aktivitas, yang disebut dengan task regions. Kebanyakan aktivitas-aktivitas tersebut dibagi antara 3 sampai 6 aktivitas. Berikut adalah aktivitas-aktivitas yang dilakukan dalam spiral model[3]:

1. Customer communication. Aktivitas yang dibutuhkan untuk membangun komunikasi yang efektif antara developer dengan user / customer terutama mengenai kebutuhan dari customer.
2. Planning. Aktivitas perencanaan ini dibutuhkan untuk menentukan sumberdaya, perkiraan waktu pengerjaan, dan informasi lainnya yang dibutuhkan untuk pengembangan software.
3. Analysis risk. Aktivitas analisis resiko ini dijalankan untuk menganalisis baik resiko secara teknikal maupun secara manajerial. Tahap inilah yang mungkin tidak ada pada model proses yang juga menggunakan metode iterasi, tetapi hanya dilakukan pada spiral model.
4. Engineering. Aktivitas yang dibutuhkan untuk membangun 1 atau lebih representasi dari aplikasi secara teknikal.
5. Construction & Release. Aktivitas yang dibutuhkan untuk develop software, testing, instalasi dan penyediaan user / costumer support seperti training penggunaan software serta dokumentasi seperti buku manual penggunaan software.
6. Customer evaluation. Aktivitas yang dibutuhkan untuk mendapatkan feedback dari user / customer berdasarkan evaluasi mereka selama representasi software pada tahap engineering maupun pada implementasi selama instalasi software pada tahap construction and release.

Adapun kelebihan dan kekurangan dari model spiral sebagai berikut[4]:

a. Kelebihan model Spiral :

1. Dapat disesuaikan agar perangkat lunak bisa dipakai selama hidup perangkat lunak komputer.
2. Lebih cocok untuk pengembangan sistem dan perangkat lunak skala besar.
3. Pengembang dan pemakai dapat lebih mudah memahami dan bereaksi terhadap resiko setiap tingkat evolusi karena perangkat lunak terus bekerja selama proses .
4. Menggunakan prototipe sebagai mekanisme pengurangan resiko dan pada setiap keadaan di dalam evolusi produk.
5. Tetap mengikuti langkah-langkah dalam siklus kehidupan klasik dan memasukkannya ke dalam kerangka kerja iteratif .
6. Membutuhkan pertimbangan langsung terhadp resiko teknis sehingga mengurangi resiko sebelum menjadi permaslahan yang serius.

b. Kelemahan model Spiral :

1. Sulit untuk menyakinkan pelanggan bahwa pendekatan evolusioner ini bisa dikontrol.
2. Memerlukan penaksiran resiko yang masuk akal dan akan menjadi masalah yang serius jika resiko mayor tidak ditemukan dan diatur.
3. Butuh waktu lama untuk menerapkan paradigma ini menuju kepastian yang absolut

f.             Four - 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

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 digunakanuntuk 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.

Menggunakan  perangkat  bantu  yang  akan  membuat  kode  sumber  secara otomatis berdasarkan  spesifikasi  dari  pengembang  perangkat  lunak.  Hanya digunakan untuk mengembangkan perangkat lunak yang menggunakan bentuk bahasa  khusus  atau  notasi  grafik  yang  diselesaikan  dengan syarat  yang dimengerti pemakai. Cakupan aktivitas 4GT:

·         Pengumpulan kebutuhan.

·         Translasi  kebutuhan  menjadi  prototype  operasional,  atau  langsung melakukan  implementasi secara  langsung  dengan  menggunakan  bahasa generasi keempat (4GL) jika aplikasi relatif kecil.

·         Untuk aplikasi yang cukup besar, dibutuhkan strategi perancangan sistem walaupun 4GL akan digunakan.

·         Pengujian.

·         Membuat dokumentasi.

·         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  dibandingkan  dengan  bahasa pemrograman, dan juga kode sumber yang dihasilkannya tidak efisien.

DAFTAR PUSTAKA

http://b4mz.web.id/spiral-model/ ( Diakses pada tanggal 5 Februari 2013)

http://ali.misri07.alumni.ipb.ac.id/model-pengembangan-perangkat-lunak-prototyping/( Diakses pada tanggal 5 Februari 2013)

http://nurulqomariah16.blogspot.com/2011/03/model-incremental.html( Diakses pada tanggal 5 Februari 2013)

http://rapidapplicationdevelopmentrad.blogspot.com/( Diakses pada tanggal 5 Februari 2013)

http://bukurobek.blogspot.com/2011/04/metodologi-pengembangan-perangkat-lunak.html( Diakses pada tanggal 5 Februari 2013)

http://ocw.gunadarma.ac.id/course/industrial-technology/informatics-engineering-s1/rekayasa-perangkat-lunak-1/pendahuluan( Diakses pada tanggal 5 Februari 2013)

http://muhlisthahir033.files.wordpress.com/2011/12/chapter-3-rpl.pdf( Diakses pada tanggal 5 Februari 2013)