FLOW CONTROL DAN ERROR CONTROL PADA DATA LINK CONTROL
oleh
ahmad ferly f
0704411005
Abstrak
Dikarenakan kemungkinan bias terjadi kesalahan pada transmisi, serta karena receiver
data perlu mengatur rate terhadap data yang diterimanya, teknik sinkronisasi dan interfacing
saja tidak cukup. Oleh karena itu perlu untuk membuat lapisan control pada setiap perankat
komunikasi yang menyediakan fungsi seperti flow control, pendektesian kesalahan, dan control
kesalahan. Lapisan control ini disebut data link control protocol.
Flow control memungkinkan receiver mengatur arus data dari pengirim sehingga buffer
pada receiver tidak sepenuhnya terpakai.
Pendeteksian kesalahan ditunjukkan melalui penghitungan kode pendeteksian kesalahan
yang merupakan fungsi bit-bit yang sedang ditransmisikan. Kode ini disertakan pada bit-bit
data yang ditransmisikan . Receiver menghitung kode berdasarkan atas bit-bit yang masuk dan
membandingkan dengan kode yang dating untuk mengecek adanya kesalahan.
Pada protocol data link control, error control diperoleh melalui pentransmisian ulang
(retransmisi) frame-frame yang rusak yang tidak dibalas atau bila ada yang mengajukan
permintaan transmisi ulang semacam itu.
BAB 1. PENDAHULUAN
1.1 LATAR BELAKANG
Lapisan data-link (data link layer)
adalah lapisan kedua dari bawah
dalam model OSI, yang dapat melakukan
konversi frame-frame jaringan yang berisi
data yang dikirimkan menjadi bit bit
mentah agar dapat diproses oleh lapisan
fisik. Lapisan ini merupakan lapisan yang
akan melakukan transmisi data antara
perangkat-perangkat jaringan yang saling
berdekatan di dalam sebuah wide area
network (WAN), atau antara node di dalam
sebuah segmen local area network (LAN)
yang sama. Lapisan ini bertanggungjawab
dalam membuat frame, flow control,
koreksi kesalahan dan pentransmisian ulang
terhadap frame yang dianggap gagal. MAC
address juga diimplementasikan di dalam
lapisan ini. Selain itu, beberapa perangkat
sepertiNetwork Interface Card (NIC),
switch layer 2 serta bridge jaringan juga
beroperasi di sini.
1.2 BATASAN MASALAH
Adapun batasan masalah yang diperoleh
adalah sebagai berikut :
1. Apakah yang dimaksud dengan flow
control ?
2. Apakah yang dimaksud dengan error
control ?
1.3 TUJUAN
Adapun tujuan dari pembuatan artikel ini
antara lain :
1. Untuk mengetahui lebih dalam mengenai
flow control.
2. Untuk mengetahui lebih dalam mengenai
error control.
1.4 MANFAAT
Manfaat dari pembuatan artikel ini
adalah untuk menambah pengetahuan
mengenai flow control dan error control.
BAB 2. TEORI PENUNJANG
Pengiriman data melalui link
komunikasi data yang terlaksana dengan
penambahan kontrol layer dalam tiap
device komunikasi, dinyatakan sebagai data
link control atau data link protocol.
Data link adalah medium transmisi
antara stasiun-stasiun ketika suatu prosedur
data link control dipakai.
Keperluan-keperluan dan tujuan-tujuan
untuk komunikasi data secara efektif antara
dua koneksi stasiun transmisi-penerima
secara langsung, untuk melihat kebutuhan
bagi data link control:
• Frame synchronization : data dikirim
dalam blok-blok yang disebut frame.
Awal dan akhir tiap frame harus dapat
diidentifikasikan. Memakai variasi dari
konfigurasi line.
• Flow control : stasiun pengirim harus
tidak mengirim frame-frame pada
rate/kecepatan yang lebih cepat daripada
stasiun penerima yang dapat
menyerapnya.
• Error control : bit-bit error yang
dihasilkan oleh sistem transmisi harus
diperbaiki.
• Addressing (peng-alamat-an) : pada line
multipoint, identitas dari dua stasiun
yang berada dalam suatu transmisi harus
diketahui.
• Kontrol dan data pada link yang sama :
biasanya tidak diinginkan mempunyai
path komunikasi yang terpisah untuk
sinyal-sinyal kontrol. Karena itu, receiver
harus mampu membedakan kontrol
informasi dari data yang sedang
ditransmisi.
• Link management : permulaan,
pemeliharaan dan penghentian dari
pertukaran data memerlukan koordinasi
dan kerjasama diantara stasiun-stasiun.
Diperlukan prosedur untuk manajemen
pertukaran ini.
BAB 3. METODE PENELITIAN
Melakukan kajian pustaka mengenai topik
yang berkaitan dengan penelitian ini, yaitu
mengenai flow control dan error control.
BAB 4. PEMBAHASAN
4.1 FLOW CONTROL
Adalah suatu teknik untuk memastikan
/meyakinkan bahwa suatu stasiun transmisi
tidak menumpuk data pada suatu stasiun
penerima.
Tanpa flow control, buffer dari
receiver akan penuh sementara sedang
memproses data lama. Karena ketika data
diterima, harus dilaksanakan sejumlah
proses sebelum buffer dapat dikosongkan
dan siap menerima banyak data.
Pada gambar 1 tiap tanda panah
menyatakan suatu perjalanan frame
tunggal. Suatu data link antara dua stasiun
dan transmisinya bebas error. Tetapi
bagaimanapun, setiap frame yang
ditransmisi semaunya dan sejumlah delay
sebelum diterima. Gambar b suatu
transmisi dengan losses dan error.
Gambar 1 Model dari transmisi frame
Diasumsikan bahwa semua frame yang
dikirimkan berhasil diterima dengan sukses,
tidak ada frame yang hilang dan tidak ada
frame yang datang mengalami error.
Selanjutnya frame-frame tersebut tiba
bersamaan dengan dikirimkannya frame,
bagaimanapun juga masing-masing frame
yang dikirimkan sebelum diterima akan
mendapat delay pasa saluran yang besarnya
berubah-ubah.
4.1.1 Stop And Wait Flow Control
Protokol ini memiliki karakteristik
dimana sebuah pengirim mengirimkan
sebuah frame dan kemudian menunggu
acknowledgment sebelum memprosesnya
lebih lanjut. Mekanisme stop and wait
dapat dijelaskan dengan menggunakan
gambar di bawah, dimana DLC
mengizinkan sebuah message untuk
ditransmisikan (event 1), pengujian
terhadap terjadinya error dilakukan dengan
teknik seperti VCR (Vertical Redundancy
Check) atau LRC (Longitudinal
Redundancy Check) terjadi pada even 2 dan
pada saat yang tepat sebuah ACK atau
NAK dikirimkan kembali untuk ke stasiun
pengirim (event 3). Tidak ada messages
lain yang dapat ditransmisikan selama
stasiun penerima mengirimkan kembali
sebuah jawaban. Jadi istilah stop and wait
diperoleh dari proses pengiriman message
oleh stasiun pengirim, menghentikan
transmisi berikutnya, dan menunggu
jawaban.
Pendekatan stop and wait adalah sesuai
untuk susunan transmisi half duplex, karena
dia menyediakan untuk transmisi data
dalam dua arah, tetapi hanya dalam satu
arah setiap saat. Kekurangan yang terbesar
adalah disaat jalur tidak jalan sebagai
akibat dari stasiun yang dalam keadaan
menunggu, sehingga kebanyakan DLC stop
and wait sekarang menyediakan lebih dari
satu terminal yang on line. Terminalterminal
tetap beroperasi dalam susunan
yang sederhana. Stasiun pertama atau host
sebagai penaggung jawab untuk peletakkan
message diantara terminal-terminal
(biasanya melalui sebuah terminal
pengontrol yang berada di depannya) dan
akses pengontrolan untuk hubungan di
bawah dan menjadi masalah yang serius
ketika ACK atau NAK hilang dalam
jaringan atau dalam jalur. Jika ACK pada
event 3 hilang, setelah habis batas
waktunya stasiun master mengirim ulang
message yang sama untuk kedua kalinya.
Transmisi yang berkelebihan mungkin
terjadi dan menciptakan sebuah duplikasi
record pada tempat kedua dari file data
pengguna. Akibatnya, DLC harus
mengadakan suatu cara untuk
mengidentifikasi dan mengurutkan message
yang dikirimkan dengan berdasarkan pada
ACK atau NAK sehingga harus dimiliki
suatu metoda untuk mengecek duplikat
message.
Other Messages aw aiting transmission
Station
A
Station
B
Message 1
Event 1
n
3
4
2
n
3
4
2
Station
A
Station
B
Line is idle
Event 2
Message 1 checked
for Errors
n
3
4
2
Station
A
Station
B
ACK or NAK
Event 3
Gambar 2 Stop and wait data link control
Pada gambar di bawah ditunjukkan
bagaimana urutan pendeteksian duplikasi
message bekerja, pada event 1 stasiun
pengirim mengirikan sebuah message
dengan urutan 0 pada headernya. Stasiun
penerima menjawab dengan sebuah ACK
dan sebuah nomor urutan 0 (event 2).
Pengirim menerima ACK, memeriksa
nomor urutan 0 di headernya, mengubah
nomor urutan menjadi 1 dan mengirimkan
message berikutnya (event 3).
ACK; SEQ. NUMBER 1
6 B Retransmit ACK of 1
5
A Perf orms a Timeout;
Resends Data with a sequence of 1
DATA; SEQ. NUMBER 1
B Expects a Sequence Number of 0;
Discards This Message
4
ACK; SEQ. NUMBER 1
Message Lost or Damaged
3
A Receiv es ACK;
Sends Data with Sequences of 1
DATA; SEQ. NUMBER 1
2
B Checks f or Error;
Responds with ACK of 0
ACK; SEQ. NUMBER 0
STATION A STATION B
DATA; SEQ. NUMBER 0
Ev ent Ev ent
A Send Data with Sequence of 0 1
Gambar 3 Stop-and-wait alternating sequence
Stasiun penerima mendapatkan
message dengan ACK 1 di event 4. Akan
tetapi message ini diterima dalam keadaan
rusak atau hilang pada jalan. Stasiun
pengirim mengenali bahwa message di
event 3 tidak dikenali. Setelah batas waktu
terlampau (timeout) stasiun pengirim
mengirim ulang message ini (event 5).
Stasiun penerima mencari sebuah message
dengan nomor urutan 0. Dia membuang
message, sejak itu dia adalah sebuah
duplikat dari message yang dikirim pada
event 3. Untuk melengkapi pertang-gungjawaban,
stasiun penerima mengirim ulang
ACK 1 (event 6).
Efek delay propagasi dan kecepatan
transmisi
Kita akan menentukan efisiensi
maksimum dari sebuah jalur point-to-point
menggunakan skema stop and wait. Total
waktu yang diperlukan untuk mengirim
data adalah :
Td = TI + nTF
dimana TI = waktu untuk menginisiasi
urutan = tprop + tpoll + tproc
TF = waktu untuk mengirim satu
frame
TF = tprop + tframe + tproc + tprop +
tack + tproc
tprop = waktu propagasi
tframe = waktu pengiriman
tack = waktu balasan
Untuk menyederhanakan persamaan di
atas, kita dapat mengabaikan term.
Misalnya, untuk sepanjang urutan frame, TI
relatif kecil sehingga dapat diabaikan. Kita
asumsikan bahwa waktu proses antara
pengiriman dan penerimaan diabaikan dan
waktu balasan frame adalah sangat kecil,
sehingga kita dapat mengekspresikan TD
sebagai berikut:
TD = n(2tprop + t frame)
Dari keseluruhan waktu yang diperlukan
hanya n x t frame yang dihabiskan selama
pengiriman data sehingga utilization (U)
atau efisiensi jalur diperoleh :
4.1.2 Sliding-Window Flow Control
Masalah utama yang selama ini adalah
bahwa hanya satu frame yang dapat
dikirimkan pada saat yang sama. Dalam
keadaan antrian bit yang akan dikirimkan
lebih besar dari panjang frame (a>1) maka
diperlukan suatu efisiensi. Untuk
memperbesar efisiensi yang dapat
dilakukan dengan memperbolehkan
transmisi lebih dari satu frame pada saat
yang sama. Bila suatu station A dan B
dihubungkan dengan jalur full-duplex,
station B mengalokasikan buffers dengan
selebar n frame, yang berarti stasiun B
dapat menerima n frame, dan station A
diperbolehkan untuk mengirim frame
sebanyak n tanpa menunggu adanya
jawaban. Untuk menjaga jejak dimana
frame yang dikirimkan sedang dijawab
maka masing-masing jawaban diberi label
dengan nomor yang urut. Station B
menjawab frame dengan mengirimkan
jawaban yang dilengkapi nomor urut dari
frame berikutnya yang diinginkan. Jawaban
ini juga memiliki maksud untuk
memberitahukan bahwa station B siap
untuk menerima n frame berikutnya,
dimulai dengan nomer urut yang telah
tercantum. Skema ini juga dapat
dipergunakan untuk menjawab lebih dari
satu frame. Misalnya station B dapat
jawaban sampai samapai frame ke 4 tiba,
dengan kembali jawaban dengan nomer
urut 5, station B menjawab frame 2, 3, dan
4 pada satu saat. Station A memeliharan
daftar nomer urutan yang boleh dikirim,
sedangkan station B memelihara daftar
nomer urutan yang siap akan diterima.
Masing-masing daftar tersebut dapat
dianggap sebagai window dari frame,
sehingga prinsip kerjanya disebut dengan
pengontrol aliran sliding-window.
Diperlukan untuk dibuat komentar
tambahan untuk masing-masing, karena
nomer urut yang dipakai menempati daerah
didalam frame, komentar tambahan ini
dibatasai oleh terbatasnya tempat yang
tersedia. Misalnya untuk daerah dengan
panjang 3 bit, maka nomer urut
jangkauannya antara 0 s/d 7 saja, sehingga
frame diberi nomer dengan modulo 7, jadi
sesudah nomer urut 7 berikutnya adalah
nomer 0. Pada umumnya untuk daerah
dengan apnjang k-bit, maka jangkauan
nomer urut dari 0 samapai dengan 2k-1,
dan frame diberi nomer dengan modulo 2k.
Pada gambar dibawah menggambarkan
proses sliding-windows, dengan
diasumsikan nomer urut menggunakan 3-
bit sehingga frame diberi nomer urut 0 s/d
7, selanjutnya nomer yang sama dipakai
kembali sebagai bagian urutan frame.
Gambar segiempat yang diberi bayangan
(disebut window) menunjukkan transmitter
dapat mengirimkan 7 frame, dimulai
dengan frame nomer 7. Setiap waktu frame
dikirimkan maka window yang
digambarkan sebagai kotak dibayangi akan
menyusut, setiap waktu jawaban diterima,
window akan membesar. Ukuran panjang
window sebenarnya tidak diperlukan
sebanyak ukuran maksimumnya untuk diisi
sepanjang nomer urut. Sebagai contoh,
nomer urut menggunakan 3-bit, stasiun
dapat membentuk window dengan ukuran
4, menggunakan protokol pengatur aliran
sliding-window. Sebagai contoh
diasumsikan memiliki daerah nomer urut 3-
bit dan maksimum ukuran window adalah 7
frame. Dimulai dari station A dan B telah
menandai window dan station A
mengirimkan 7 frame yang dimulai dengan
frame 0 (F0), sesudah mengirimkan 3 frame
(F0, F1, dan F2) tanpa jawaban maka
station A telah menyusutkan window nya
menjadi 4 frame. Window menandati bahwa
station A dapat mengirimkan 4 frame,
dimulai dari frame nomer 3 selanjutnya
stasiun B mengirim receive-ready (RR)
yang berarti semua frame telah diterima
sampai frame nomer 2 dan selanjutnya siap
menerima frame nomer 3, tetapi pada
kenyataannya disiapkan menerima 7 frame,
dimulai frame nomer 3. Station A terus
mengirimkan frame nomer 3, 4, 5, dan 7,
kemudian station B menjawab RR7 sebagai
jawaban dari semua frame yang diterima
dan pengusulkan station A mengirim 7
frame, dimulai frame nomer 7.
Gambar 4 Skema Aliran Sliding-Window
Receiver harus dapat menampung 7
frame belebihi satu jawaban yang telah
dikirim, sebagian besar protokol juga
memperbolehkan suatu station untuk
memutuskan aliran frame dari sisi (arah)
lain dengan cara mengirimkan pesar
receive-not-ready (RNR), yang dijawab
frame terlebih dulu, tetapi melarang
transfer frame berikutnya. Bila dua stasiun
saling bertukar data (dua arah) maka
masing-masing perlu mengatur dua
window, jadi satu untuk transmit dan satu
untuk receive dan masingmasing sisi (arah)
saling mengirim jawaban. Untuk
memberikan dukungan agar efiisien seperti
yang diinginkan, dipersiapkan
piggybacking (celengan), masing-masing
frame data dilengkapi dengan daerah yang
menangkap urutan nomer dari frame,
ditambah daerah yang menangkap urutan
nomer yang dipakai sebagai jawaban.
Selanjutnya bila suatu station memiliki data
yang akan dikirim dan jawaban yang akan
dikirimkan, maka dikirimkan bersamasama
dalam satu frame, cara yang demikian
dapat meningkatkan kapasitas komunikasi.
Jika suatu station memiliki jawaban tetapi
tidak memiliki data yang akan dikirim,
maka station tersebut mengirimkan frame
jawaban yang terpisah. Jika suatu station
memiliki data yang akan dikirimkan tetapi
tidak memiliki jawaban baru yang akan
dikirim maka station tersebut mengulangi
dengan mengirimkan jawaban terakhir yang
dikirim, hal ini disebabkan frame data
dilengkapi daerah untuk nomer jawaban,
dengan suatu nilai (angka) yang harus
diletakkan kedalam daerah tersebut. Jika
suatu station menerima jawaban yang sama
(duplikat) maka tinggal mengabaikan
jawaban tersebut. Sliding-window
dikatakan lebih efisien karena jalur
komunikasi disiapkan seperti pipa saluran
yang setiap saat dapat diisi beberapa frame
yang sedang berjalan, tetapi pada stop-andwait
hanya satu frame saja yang boleh
mengalir dalam pipa saluran tersebut.
4.2 ERROR CONTROL
Berfungsi untuk mendeteksi dan
memperbaiki error-error yang terjadi dalam
transmisi frame-frame. Ada 2 tipe error
yang mungkin :
• Frame hilang : suatu frame gagal
mencapai sisi yang lain
• Frame rusak : suatu frame tiba tetapi
beberapa bit-bit-nya error.
Teknik-teknik umum untuk error control,
sebagai berikut :
• Deteksi error : Error detection, biasanya
menggunakan teknik CRC (Cyclic
Redundancy Check)
• Positive acknowledgment : tujuan
mengembalikan suatu positif
acknowledgment untuk penerimaan yang
sukses, frame bebas error.
• Transmisi ulang setelah waktu habis :
sumber mentransmisi ulang suatu frame
yang belum diakui setelah suatu waktu
yang tidak ditentukan.
• Negative acknowledgment dan transmisi
ulang : tujuan mengembalikan negative
acknowledgment dari frame-frame
dimana suatu error dideteksi.
Sumber mentransmisi ulang beberapa
frame.
Mekanisme ini dinyatakan sebagai
Automatic repeat Request (ARQ) yang
terdiri dari 3 versi :
• Stop and wait ARQ.
• Go-back-N ARQ.
• Selective-reject ARQ.
4.2.2 Stop and Wait ARQ
Berdasarkan pada teknik flow control
stop and wait dan digambarkan dalam
gambar dibawah. Stasiun sumber
mentransmisi suatu frame tunggal dan
kemudian harus menunggu suatu
acknowledgment (ACK) dalam periode
tertentu. Tidak ada data lain dapat dikirim
sampai balasan dari stasiun tujuan tiba pada
stasiun sumber. Bila tidak ada balasan
maka frame ditransmisi ulang. Bila error
dideteksi oleh tujuan, maka frame tersebut
dibuang dan mengirim suatu Negative
Acknowledgment (NAK), yang
menyebabkan sumber mentransmisi ulang
frame yang rusak tersebut.
Gambar 5 Stop-and-wait ARQ
Bila sinyal acknowledgment rusak
pada waktu transmisi, kemudian sumber
akan habis waktu dan mentransmisi ulang
frame tersebut. Untuk mencegah hal ini,
maka frame diberi label 0 atau 1 dan
positive acknowledgment dengan bentuk
ACK0 atau ACK1 : ACK0 mengakui
menerima frame 1 dan mengindikasi bahwa
receiver siap untuk frame 0. Sedangkan
ACK1 mengakui menerima frame 0 dan
mengindikasi bahwa receiver siap untuk
frame 1.
4.2.3 Go Back N ARQ
Termasuk continuous ARQ, suatu
stasiun boleh mengirim frame seri yang
ditentukan oleh ukuran window, memakai
teknik flow control sliding window.
Sementara tidak terjadi error, tujuan akan
meng-acknowledge (ACK) frame yang
masuk seperti biasanya.
Teknik Go-back-N ARQ yang terjadi
dalam beberapa kejadian :
• Frame yang rusak. Ada 3 kasus :
A mentransmisi frame i. B mendeteksi
suatu error dan telah menerima frame
(i-1) secara sukses. B mengirim A
NAKi, mengindikasi bahwa frame i
ditolak. Ketika A menerima NAK ini,
maka harus mentransmisi ulang frame i
dan semua frame berikutnya yang
sudah ditransmisi.
Frame i hilang dalam transmisi. A
kemudian mengirim frame (i+1). B
menerima frame (i+1) diluar
permintaan, dan mengirim suatu
NAKi.
Frame i hilang dalam transmisi dan A
tidak segera mengirim frame -frame
tambahan. B tidak menerima apapun
dan mengembalikan baik ACK atau
NAK. A akan kehabisan waktu dan
mentransmisi ulang frame i.
• ACK rusak. Ada 2 kasus :
B menerima frame i dan mengirim
ACK (i+1), yang hilang dalam
transmisi. Karena ACK dikomulatif
(contoh, ACK6 berarti semua frame
sampai 5 diakui), hal ini mungkin
karena A akan menerima sebuah ACK
yang berikutnya untuk sebuah frame
berikutnya yang akan melaksanakan
tugas dari ACK yang hilang sebelum
waktunya habis.
Jika waktu A habis, A mentransmisi
ulang frame I dan semua frame -frame
berikutnya.
• NAK rusak. Jika sebuah NAK hilang, A
akan kehabisan waktu (time out) pada
serangkaian frame dan mentransmisi
ulang frame tersebut berikut frame frame
selanjutnya.
4
6
7
5
A
3
3 B
2
1
4 2
1
ACK 1
5
6
7
A
4
4 B
3
2
5 3
1
NAK 2
Frame 2 is in error,
NAK 2 is sent
5
6
7
A
3
4 B
3
2
4 2
1 Frame 3,4, and 5
are discarded
Gambar 6 Go-back-N ARQ
4.2.4 Selective Reject ARQ
Hanya mentransmisi ulang frameframe
bila menerima NAK atau waktu
habis. Ukuran window yang perlu lebih
sempit daripada go-back-N. Untuk goback-
N, ukuran window 2n-1 sedangkan
selective -reject 2n.
Skenario dari teknik ini untuk 3 bit
penomoran yang mengizinkan ukuran
window sebesar 7 :
1. Stasiun A mengirim frame 0 sampai 6 ke
stasiun B.
2. Stasiun B menerima dan mengakui
ketujuh frame-frame.
3. Karena noise, ketujuh acknowledgment
hilang.
4. Stasiun A kehabisan waktu dan
mentransmisi ulang frame 0.
5. Stasiun B sudah memajukan window
penerimanya untuk menerima frame
7,0,1,2,3,4 dan 5. Dengan demikian
dianggap bahwa frame 7 telah hilang dan
bahwa frame nol yang baru, diterima.
Problem dari skenario ini yaitu antara
window pengiriman dan penerimaan. Yang
diatasi dengan memakai ukuran window
max tidak lebih dari setengah range
penomoran.
4.2.5 Performa
Go-back-N dan selective -reject lebih
efisien daripada stop and wait. Pemakaian
maksimum (U) untuk masing-masing
teknik :
Stop and wait :
U =1 u/ N >
2a+1
U = N / (2a+1) u/ N <
2a+1
Selective reject :
U = 1-p
u/ N > 2a+1
U = N(1-p) / (2a+1)
u/ N < 2a+1
Go-back-N :
U = (1-p) / (1+2a)
u/ N > 2a+1
U = N(1-p) / (2a+1)(1-p+Np)
u/ N < 2a+1
dimana :
a = waktu penyebaran
N = ukuran window
p = probabilitas transmisi
REFERENSI
http://missa.staff.gunadarma.ac.id/
www.rijalfadilah.wordpress.com
www.wikipedia.com
http://www.csi.ucd.ie/Staff/jmurphy/net
works/csd8_4-datalink_2.pdf
http://ocw.mit.edu/NR/rdonlyres/Aerona
utics-and-Astronautics/16-
36Communication-Systems-
EngineeringSpring2003/7D64F769-4B55-
4184-B8B0-
3800DFB7DC31/0/lec15_16.pdf
Rabu, 23 Desember 2009
Minggu, 05 April 2009
Jenis-jenis Lisensi Pada Software
sabtu, 2009 April 04
Jenis-jenis Lisensi Pada Software
Menurut Microsoft dalam “The Hallowen Document”, terdapat beberapa jenis lisensi yang dapat digunakan untuk program komputer. Beberapa jenis lisensi tersebut antara lain adalah:
Lisensi Commercial
adalah jenis lisensi yang biasa ditemui pada perangkat lunak seperti Microsoft dengan Windows dan Officenya, Lotus, Oracle dan lain sebagainya. Software yang diciptakan dengan lisensi ini memang dibuat untuk kepentingan komersial sehingga user yang ingin menggunakannya harus membeli atau mendapatkan izin penggunaan dari pemegang hak cipta.
Lisensi Trial Software
adalah jenis lisensi yang biasa ditemui pada software untuk keperluan demo dari sebuah software sebelum diluncurkan ke masyarakat atau biasanya sudah diluncurkan tetapi memiliki batas masa aktif. Lisensi ini mengizinkan pengguna untuk menggunakan, menyalin atau menggandakan software tersebut secara bebas. Namun karena bersifat demo, seringkali software dengan lisensi ini tidak memiliki fungsi dan fasilitas selengkap versi komersialnya. Dan biasanya dibatasi oleh masa aktif tertentu.
Lisensi Non Commercial Use
biasanya diperuntukkan untuk kalangan pendidikan atau yayasan tertentu dibidang sosial. Sifatnya yang tidak komersial, biasanya gratis tetapi dengan batasan penggunaan tertentu. Lisensi Sharewaremengizinkan pemakainya untuk menggunakan, menyalin atau menggandakan tanpa harus meminta izin pemegang hak cipta. Berbeda dengan Trial Software, lisensi ini tidak dibatasi oleh batas waktu masa aktif dan memiliki fitur yang lengkap. Lisensi jenis ini biasanya ditemui pada software perusahaan kecil.
Lisensi Freeware
biasanya ditemui pada software yang bersifat mendukung, memberikan fasilitas tambahan atau memang free/gratis. Contoh yang bersifat mendukung antara lain adalah plug in tambahan yang biasanya menempel pada software induk seperti Eye Candy yang menempel pada Adobe Photoshop.
Lisensi Royalty-Free Binaries
serupa dengan lisensi freeware, hanya saja produk yang ditawarkan adalah library yang berfungsi melengkapi software yang sudah ada dan bukan merupakan suatu software yang berdiri sendiri.
Lisensi Open Source
membebaskan usernya untuk menjalankan, menggandakan, menyebarluaskan, mempelajari, mengubah, dan meningkatkan kinerja software. Berbagai jenis lisensi open source berkembang sesuai dengan kebutuhan, misalnya GNU/GPL, The FreeBSD, The MPL. Jenis-jenis software yang memakai lisensi ini misalnya Linux, sendmail, apache dan FreeBSD
http://keyboardsound.wordpress.com/2008/01/25/jenis-jenis-lisensi-software-komputer/
Diposkan oleh BLog ferly. . di 04:32 0 komentar
Jenis-jenis Lisensi Pada Software
Menurut Microsoft dalam “The Hallowen Document”, terdapat beberapa jenis lisensi yang dapat digunakan untuk program komputer. Beberapa jenis lisensi tersebut antara lain adalah:
Lisensi Commercial
adalah jenis lisensi yang biasa ditemui pada perangkat lunak seperti Microsoft dengan Windows dan Officenya, Lotus, Oracle dan lain sebagainya. Software yang diciptakan dengan lisensi ini memang dibuat untuk kepentingan komersial sehingga user yang ingin menggunakannya harus membeli atau mendapatkan izin penggunaan dari pemegang hak cipta.
Lisensi Trial Software
adalah jenis lisensi yang biasa ditemui pada software untuk keperluan demo dari sebuah software sebelum diluncurkan ke masyarakat atau biasanya sudah diluncurkan tetapi memiliki batas masa aktif. Lisensi ini mengizinkan pengguna untuk menggunakan, menyalin atau menggandakan software tersebut secara bebas. Namun karena bersifat demo, seringkali software dengan lisensi ini tidak memiliki fungsi dan fasilitas selengkap versi komersialnya. Dan biasanya dibatasi oleh masa aktif tertentu.
Lisensi Non Commercial Use
biasanya diperuntukkan untuk kalangan pendidikan atau yayasan tertentu dibidang sosial. Sifatnya yang tidak komersial, biasanya gratis tetapi dengan batasan penggunaan tertentu. Lisensi Sharewaremengizinkan pemakainya untuk menggunakan, menyalin atau menggandakan tanpa harus meminta izin pemegang hak cipta. Berbeda dengan Trial Software, lisensi ini tidak dibatasi oleh batas waktu masa aktif dan memiliki fitur yang lengkap. Lisensi jenis ini biasanya ditemui pada software perusahaan kecil.
Lisensi Freeware
biasanya ditemui pada software yang bersifat mendukung, memberikan fasilitas tambahan atau memang free/gratis. Contoh yang bersifat mendukung antara lain adalah plug in tambahan yang biasanya menempel pada software induk seperti Eye Candy yang menempel pada Adobe Photoshop.
Lisensi Royalty-Free Binaries
serupa dengan lisensi freeware, hanya saja produk yang ditawarkan adalah library yang berfungsi melengkapi software yang sudah ada dan bukan merupakan suatu software yang berdiri sendiri.
Lisensi Open Source
membebaskan usernya untuk menjalankan, menggandakan, menyebarluaskan, mempelajari, mengubah, dan meningkatkan kinerja software. Berbagai jenis lisensi open source berkembang sesuai dengan kebutuhan, misalnya GNU/GPL, The FreeBSD, The MPL. Jenis-jenis software yang memakai lisensi ini misalnya Linux, sendmail, apache dan FreeBSD
http://keyboardsound.wordpress.com/2008/01/25/jenis-jenis-lisensi-software-komputer/
Diposkan oleh BLog ferly. . di 04:32 0 komentar
Minggu, 22 Maret 2009
tugas,,, 2
Sabtu, 2009 Maret 21
Agile Programming
Kata Agile berarti bersifat cepat, ringan, bebas bergerak, waspada. Kata ini digunakan sebagai kata yang mengambarkan konsep model proses yang berbeda dari konsep model-model proses yang sudah ada. Konsep Agile Software Development dicetuskan oleh Kent Beck dan 16 rekannya dengan menyatakan bahwa Agile Software Development adalah cara membangun software dengan melakukannya dan membantu orang lain membangunnya sekaligus.
Dalam Agile Software Development interaksi dan personel lebih penting dari pada proses dan alat, software yang berfungsi lebih penting daripada dokumentasi yang lengkap, kolaborasi dengan klien lebih penting dari pada negosiasi kontrak, dan sikap tanggap terhadap perubahan lebih penting daripada mengikuti rencana. Namun demikian, sama seperti model proses yang lain, Agile Software Development memiliki kelebihan dan tidak cocok untuk semua jenis proyek, produk, orang dan situasi.
Agile Software Development memungkinkan model proses yang toleransi terhadap perubahan kebutuhan sehingga perubahan dapat cepat ditanggapi. Namun di sisi lain menyebabkan produktifitas menurun.
Prinsip Agile Software Development
Salah satu ciri dari Agile Software Development adalah tim yang tanggap terhadap perubahan. Mengapa? Karena perubahan adalah hal yang utama dalam pembangunan software: perubahan kebutuhan software, perubahan anggota tim, perubahan teknologi dll. Selain itu Agile Software
Development juga melihat pentingnya komunikasi antara anggota tim, antara orang-orang teknis dan businessmen, antara developer dan managernya. Ciri lain adalah klien menjadi bagian dari tim pembangun software. Ciri-ciri ini didukung oleh 12 prinsip yang ditetapkan oleh Agile Alliance.
Menurut Agile Alliance, 12 prinsip ini adalah bagi mereka yang ingin berhasil dalam penerapan Agile Software Development:
1. kepuasan klien adalah prioritas utama dengan menghasilkan produk lebih awal dan terus menerus
2. menerima perubahan kebutuhan, sekalipun diakhir pengembangan.
3. Penyerahan hasil/software dalam hitungan waktu dua minggu sampai dua bulan.
4. Bagian bisnis dan pembangun kerja sama tiap hari selama proyek berlangsung
5. Membangun proyek dilingkungan orang-orang yang bermotivasi tinggi yang bekerja dalam lingkungan yang mendukun dan yang dipercaya untuk dapat menyelesaikan proyek.
6. Komunikasi dengan berhadapan langsung adalah komunikasi yang efektif dan efisien
7. Software yang berfungsi adalah ukuran utama dari kemajuan proyek
8. dukungan yang stabil dari sponsor, pembangun, dan pengguna diperlukan untuk menjaga perkembangan yang berkesinambungan
9. perhatian kepada kehebatan teknis dan desain yang bagus meningkatkan sifat agile
10. kesederhanaan penting
11. arsitektur, kebutuhan dan desain yang bagus muncuk dari tim yang mengatur dirinya sendiri
12. secara periodik tim evaluasi diri dan mencari cara untuk lebih efektif dan segera melakukannya.
Kedua belas prinsip tersebut menjadi suatu dasar bagi model-model proses yang punya sifat agile. Dengan prinsip-prinsip tersebur Agile Process Model berusaha untuk menyiasati 3 asumsi penting tentang proyek software pada umumnya:
1. kebutuhan software sulit diprediksi dari awal dan selalu akan berubah. Selain itu, prioritas klien juga sering berubah seiring berjalannya proyek.
2. Desain dan pembangunan sering tumpang tindih. Sulit diperkirakan seberapa jauh desain yang diperlukan sebelum pembangunan.
3. Analisis, desain, pembangunan dan testing tidak dapat diperkirakan seperti yang diinginkan.
Agile Process Model
Berikut ini adalah model-model proses yang termasuk agile process model :
1. XP(Extreme Programming)
2. ADAPTIVE SOFTWARE DEVELOPMENT (ASD)
3. DYNAMIC SYSTEMS DEVELOPMENT METHOD
4. SCRUM
5. Agile Modelling
Diakses di http://www.agilemodeling.com/essays/introductionToAM.htm 07/09/08.
Pressman, Roger S. Software Engineering : A Practitioner's Approach. 6th Ed. McGraw-Hall. NY. 2005.
Diposkan oleh BLog ferly. . di 05:16 0 komentar
Extreme Programming
Extreme Programming – Melakukan Pengembangan Perangkat Lunak dengan Lebih Sederhana
Extreme Programming (berikutnya akan disingkat sebagai XP) adalah sebuah pendekatan atau model pengembangan perangkat lunak yang mencoba menyederhanakan berbagai tahapan dalam proses pengembangan tersebut sehingga menjadi lebih adaptif dan fleksibel. Walaupun menggunakan kata programming, XP bukan hanya berfokus pada coding tetapi meliputi seluruh area pengembangan perangkat lunak.
Sejarah XP
Proyek pengembangan perangkat lunak yang dianggap sebagai yang pertama kali menerapkan XP adalah C3 (Chrysler Comprehensive Compensation) Project dari Chrysler. Proyek ini adalah proyek penggajian 10.000 karyawan Chrysler, terdiri dari kira-kira 2000 class dan 30.000 method. Proyek yang dimulai pertengahan dekade 90-an ini terancam gagal karena rumitnya sistem yang dibangun dan kegagalan pada saat testing. Chrysler kemudian menyewa Kent Beck, seorang pakar software engineering yang di kemudian hari dikenal sebagai pencetus awal dari XP, untuk menyelamatkan proyek tersebut. Beck bersama rekannya Ron Jeffries dengan kewenangan yang diberikan oleh Chrysler melakukan berbagai perubahan di C3 Project untuk membuatnya lebih efisien, adaptif, dan fleksibel. Hal yang paling penting bagi mereka adalah harus mampu memenuhi permintaan utama dari Chrysler, untuk melakukan launching perangkat lunak tersebut dalam waktu tidak lebih dari dua tahun sejak saat Beck dikontrak.
Beck dan Jeffries pada akhirnya berhasil menyelesaikan target Chrysler dengan menerapkan berbagai metode dalam proses pengembangan perangkat lunak tersebut. Kumpulan metode inilah yang kemudian dikenal sebagai model atau pendekatan XP dalam pengembangan perangkat lunak. Begitu sederhananya metode-metode tersebut sehingga bagi orang yang belum menerapkan, XP terlihat sebagai kumpulan ide lama yang terlalu sederhana dan tidak akan memberikan efek apapun pada sebuah proyek pengembangan perangkat lunak.
Kent Beck sendiri mengakui dan menegaskan bahwa XP tidak selalu cocok untuk setiap proyek pengembangan perangkat lunak. Kelebihan XP adalah sesuai untuk digunakan pada proyek yang memiliki dynamic requirements. Proyek semacam ini memerlukan adaptasi cepat dalam mengatasi perubahan-perubahan yang terjadi selama proses pengembangan perangkat lunak. XP juga cocok untuk proyek dengan jumlah anggota tim tidak terlalu banyak (sekitar 10-20 orang) dan berada pada lokasi yang sama.
Nilai-nilai Dasar XP
Berikut adalah nilai-nilai mendasar yang menjadi roh dari XP pada setiap tahapan proses pengembangan perangkat lunak:
1. Communication
XP mengfokuskan pada hubungan komunikasi yang baik antar anggota tim. Para anggota tim harus membangun saling pengertian, mereka juga wajib saling berbagi pengetahuan dan keterampilan dalam mengembangkan perangkat lunak. Ego dari para programer yang biasaanya cukup tinggi harus ditekan dan mereka harus membuka diri untuk bekerjasama dengan programer lain dalam menuliskan kode program.
2. Courage
Para anggota tim dan penanggungjawab pengembangan perangkat lunak harus selalu memiliki keyakinan dan integritas dalam melakukan tugasnya. Integritas ini harus selalu dijaga bahkan dalam kondisi adanya tekanan dari situasi sekitar (misalnya oleh klien atau pemilik perusahaan). Untuk dapat melakukan sesuatu dengan penuh integritas terlebih dahulu para anggota tim harus terlebih dahulu memiliki rasa saling percaya. Rasa saling percaya inilah yang coba dibangun dan ditanamkan oleh XP pada berbagai aspeknya.
3. Simplicity
Lakukan semua dengan sederhana. Hal tersebut adalah salah satu nilai dasar dari XP. Gunakan method yang pendek dan simpel, jangan terlalu rumit dalam membuat desain, hilangkan fitur yang tidak ada gunanya, dan berbagai proses penyederhanaan lain akan selalu menjadi nilai utama dari setiap aspek XP.
4. Feedback
Berikan selalu feedback kepada sesama anggota tim maupun pihak-pihak lain yang terlibat dalam pengembangan perangkat lunak. Utarakan selalu pikiran anda dan diskusikan kesalahan-kesalahan yang muncul selama proses pengembangan. Dengarkan selalu pendapat rekan yang lain, dengan adanya feedback inilah seringkali kita menyadari bagian mana yang salah atau bisa ditingkatkan lagi dari perangkat lunak yang dikembangkan.
5. Quality Work
Semua nilai di atas berujung pada sebuah kondisi di mana kita melakukan pekerjaan dengan berkualitas. Dengan proses yang berkualitas maka implikasinya akan muncul pula perangkat lunak yang berkualitas sebagai hasil akhirnya.
Aspek Dasar XP
Aspek dasar XP terdiri dari berbagai teknik atau metode yang diterapkan Beck dan Jeffries pada C3 Project. Teknik-teknik tersebut dapat diamati pada gambar berikut ini:
1. The Planning Game
Pendekatan XP dalam perencanaan sangat mirip dengan metode yang diterapkan pada RAD (Rapid Application Development). Proses pendek dan cepat, mengutamakan aspek teknik, memisahkan unsur bisnis dengan unsur teknis dan pertemuan intensif antara klien dengan developer. Pada XP proses ini menggunakan terminologi “game” karena Beck menyarankan untuk menggunakan teknik score card dalam menentukan requirements. Semakin sulit aspek teknis yang dibutuhkan semakin tinggi pula skor pada kartu rencana tersebut.
2. Small Releases
Setiap release dilakukan dalam lingkup sekecil mungkin pada XP. Setiap developer menyelesaikan sebuah unit atau bagian dari perangkat lunak maka hasil tersebut harus segera dipresentasikan dan didiskusikan dengan klien. Jika memungkinkan untuk menerapkan unit tersebut pada perusahaan, hal itu juga dapat dilakukan sekaligus sebagai tes awal dari penerapan keseluruhan sistem. Kendati demikian hal ini tidak selalu perlu dilakukan karena harus dihitung terlebih dahulu sumberdaya yang dibutuhkan. Apakah lebih menguntungkan langsung melakukan tes terhadap unit tersebut atau melakukan tes setelah unit tersebut terintegrasi secara sempurna pada sistem.
3. Metaphor
Metaphor pada dasarnya sama dengan arsitektur perangkat lunak. Keduanya menggambarkan visi yang luas terhadap tujuan dari pengembangan perangkat lunak. Beck sendiri seperti para penandatangan Agile Manifesto lainnya bercita-cita menyederhanakan proses pengembangan perangkat lunak yang saat ini sudah dianggap terlalu rumit. Arsitektur yang saat ini banyak berisi diagram dan kode semacam UML dianggap terlalu rumit untuk dimengerti, terutama oleh klien. Metaphor, walaupun mirip dengan arsitektur lebih bersifat naratif dan deskriptif. Dengan demikian diharapkan komunikasi antara klien dengan developer akan berlangsung lebih baik dan lancar dengan penggunaan metaphor.
4. Simple Design
Sebagai salah seorang penandatangan Agile Manifesto, Beck adalah seorang yang tidak menyukai desain yang rumit dalam sebuah pengembangan perangkat lunak. Tidak heran jika dia memasukkan Simple Design sebagai salah satu unsur XP. Pada XP desain dibuat dalam lingkup kecil dan sederhana. Tidak perlu melakukan antisipasi terhadap berbagai perubahan di kemudian hari. Dengan desain yang simpel apabila terjadi perubahan maka membuat desain baru untuk mengatasi perubahan tersebut dapat dengan mudah dilakukan dan resiko kegagalan desain dapat diperkecil.
5. Refactoring
Refactoring adalah salah satu aspek paling khas dari XP. Refactoring seperti didefinisikan oleh Martin Fowler adalah ”Melakukan perubahan pada kode program dari perangkat lunak dengan tujuan meningkatkan kualitas dari struktur program tersebut tanpa mengubah cara program tersebut bekerja”. Refactoring sendiri sangat sesuai untuk menjadi bagian XP karena Refactoring mengusung konsep penyederhanaan dari proses desain maupun struktur baris kode program. Dengan Refactoring tim pengembang dapat melakukan berbagai usaha untuk meningkatkan kualitas program tanpa kembali mengulang-ulang proses desain. Fowler adalah salah satu kolega dekat dari Kent Beck karena itu tidak mengherankan bahwa cara berpikir mereka terhadap proses pengembangan perangkat lunak sangat mirip satu dengan lainnya.
6. Testing
XP menganut paradigma berbeda dalam hal tes dengan model pengembangan perangkat lunak lainnya. Jika pada pengembangan perangkat lunak lainnya tes baru dikembangkan setelah perangkat lunak selesai menjalani proses coding maka pada XP tim pengembang harus membuat terlebih dahulu tes yang hendak dijalani oleh perangkat lunak. Berbagai model tes yang mengantisipasi penerapan perangkat lunak pada sistem dikembangkan terlebih dahulu. Saat proses coding selesai dilakukan maka perangkat lunak diuji dengan model tes yang telah dibuat tersebut. Pengetesan akan jauh lebih baik apabila dilakukan pada setiap unit perangkat lunak dalam lingkup sekecil mungkin daripada menunggu sampai seluruh perangkat lunak selesai dibuat. Dengan memahami tahap ini kita dapat melihat bahwa siklus pada XP adalah requirement analysis à test à code à design. Sekilas terlihat hal ini tidak mungkin dilakukan tetapi pada kenyataannya memang gambaran inilah yang paling dapat menjelaskan tentang XP.
7. Pair Programming
Pair programming adalah melakukan proses menulis program dengan berpasangan. Dua orang programer saling bekerjasama di komputer yang sama untuk menyelesaikan sebuah unit. Dengan melakukan ini maka keduanya selalu dapat berdiskusi dan saling melakukan koreksi apabila ada kesalahan dalam penulisan program. Aspek ini mungkin akan sulit dijalankan oleh para programer yang memiliki ego tinggi dan sering tidak nyaman untuk berbagi komputer bersama rekannnya.
8. Collective Ownership
Tidak ada satupun baris kode program yang hanya dipahami oleh satu orang programer. XP menuntut para programer untuk berbagi pengetahuan untuk tiap baris program bahkan beserta hak untuk mengubahnya. Dengan pemahaman yang sama terhadap keseluruhan program, ketergantungan pada programer tertentu ataupun berbagai hambatan akibat perbedaan gaya menulis program dapat diperkecil. Pada level yang lebih tinggi bahkan dimungkinkan para programer dapat bertukar unit yang dibangunnya.
9. Coding Standards
Pair programming dan collective ownership hanya akan dapat berjalan dengan baik apabila para programer memiliki pemahaman yang sama terhadap penulisan kode program. Dengan adanya coding standards yang telah disepakati terlebih dahulu maka pemahaman terhadap program akan menjadi mudah untuk semua programer dalam tim. Hal ini dapat diterapkan sebagai contoh pada penamaan variabel dan penggunaan tipe data yang sama untuk tiap elemen semua record atau array pada program.
10. Continous Integration
Melakukan build setiap hari kerja menjadi sebuah model yang disukai oleh berbagai tim pengembang perangkat lunak. Hal ini terutama didorong oleh keberhasilan penerapan sistem ini oleh Microsoft dan telah sering dipublikasikan. Dengan melakukan build sesering mungkin berbagai kesalahan pada program dapat dideteksi dan diperbaiki secepat mungkin. Apabila banyak tim pengembang perangkat lunak meyakini bahwa build sekali sehari adalah minimum maka pada XP hal tersebut adalah maksimum. Pada XP tim disarankan untuk melakukan build sesering mungkin misalnya setiap 4 jam atau bahkan lebih cepat lagi.
11. 40-hours Week
Beck berpendapat bekerja 8 jam sehari dan 5 hari seminggu adalah maksimal untuk tiap programer. Lebih dari itu programer akan cenderung membuat berbagai error pada baris-baris kode programnya karena kelelahan.
12. On-Site Customer
Sebuah pendekatan klasik, di mana XP menganjurkan bahwa ada anggota dari klien yang terlibat pada proses pengembangan perangkat lunak. Yang lebih penting lagi ia harus ada di tempat pemrogaman dan turut serta dalam proses build dan test yang dilakukan. Apabila ada kesalahan dalam pengembangan diharapkan klien dapat segera memberikan masukan untuk koreksinya.
(Kutipan dari : http://ilmukomputer.org/2008/05/28/extreme-programming-%E2%80%93-melakukan-pengembangan-perangkat-lunak-dengan-lebih-sederhana/
Diposkan oleh BLog ferly. . di 05:23 0 komentar
Agile Programming
Kata Agile berarti bersifat cepat, ringan, bebas bergerak, waspada. Kata ini digunakan sebagai kata yang mengambarkan konsep model proses yang berbeda dari konsep model-model proses yang sudah ada. Konsep Agile Software Development dicetuskan oleh Kent Beck dan 16 rekannya dengan menyatakan bahwa Agile Software Development adalah cara membangun software dengan melakukannya dan membantu orang lain membangunnya sekaligus.
Dalam Agile Software Development interaksi dan personel lebih penting dari pada proses dan alat, software yang berfungsi lebih penting daripada dokumentasi yang lengkap, kolaborasi dengan klien lebih penting dari pada negosiasi kontrak, dan sikap tanggap terhadap perubahan lebih penting daripada mengikuti rencana. Namun demikian, sama seperti model proses yang lain, Agile Software Development memiliki kelebihan dan tidak cocok untuk semua jenis proyek, produk, orang dan situasi.
Agile Software Development memungkinkan model proses yang toleransi terhadap perubahan kebutuhan sehingga perubahan dapat cepat ditanggapi. Namun di sisi lain menyebabkan produktifitas menurun.
Prinsip Agile Software Development
Salah satu ciri dari Agile Software Development adalah tim yang tanggap terhadap perubahan. Mengapa? Karena perubahan adalah hal yang utama dalam pembangunan software: perubahan kebutuhan software, perubahan anggota tim, perubahan teknologi dll. Selain itu Agile Software
Development juga melihat pentingnya komunikasi antara anggota tim, antara orang-orang teknis dan businessmen, antara developer dan managernya. Ciri lain adalah klien menjadi bagian dari tim pembangun software. Ciri-ciri ini didukung oleh 12 prinsip yang ditetapkan oleh Agile Alliance.
Menurut Agile Alliance, 12 prinsip ini adalah bagi mereka yang ingin berhasil dalam penerapan Agile Software Development:
1. kepuasan klien adalah prioritas utama dengan menghasilkan produk lebih awal dan terus menerus
2. menerima perubahan kebutuhan, sekalipun diakhir pengembangan.
3. Penyerahan hasil/software dalam hitungan waktu dua minggu sampai dua bulan.
4. Bagian bisnis dan pembangun kerja sama tiap hari selama proyek berlangsung
5. Membangun proyek dilingkungan orang-orang yang bermotivasi tinggi yang bekerja dalam lingkungan yang mendukun dan yang dipercaya untuk dapat menyelesaikan proyek.
6. Komunikasi dengan berhadapan langsung adalah komunikasi yang efektif dan efisien
7. Software yang berfungsi adalah ukuran utama dari kemajuan proyek
8. dukungan yang stabil dari sponsor, pembangun, dan pengguna diperlukan untuk menjaga perkembangan yang berkesinambungan
9. perhatian kepada kehebatan teknis dan desain yang bagus meningkatkan sifat agile
10. kesederhanaan penting
11. arsitektur, kebutuhan dan desain yang bagus muncuk dari tim yang mengatur dirinya sendiri
12. secara periodik tim evaluasi diri dan mencari cara untuk lebih efektif dan segera melakukannya.
Kedua belas prinsip tersebut menjadi suatu dasar bagi model-model proses yang punya sifat agile. Dengan prinsip-prinsip tersebur Agile Process Model berusaha untuk menyiasati 3 asumsi penting tentang proyek software pada umumnya:
1. kebutuhan software sulit diprediksi dari awal dan selalu akan berubah. Selain itu, prioritas klien juga sering berubah seiring berjalannya proyek.
2. Desain dan pembangunan sering tumpang tindih. Sulit diperkirakan seberapa jauh desain yang diperlukan sebelum pembangunan.
3. Analisis, desain, pembangunan dan testing tidak dapat diperkirakan seperti yang diinginkan.
Agile Process Model
Berikut ini adalah model-model proses yang termasuk agile process model :
1. XP(Extreme Programming)
2. ADAPTIVE SOFTWARE DEVELOPMENT (ASD)
3. DYNAMIC SYSTEMS DEVELOPMENT METHOD
4. SCRUM
5. Agile Modelling
Diakses di http://www.agilemodeling.com/essays/introductionToAM.htm 07/09/08.
Pressman, Roger S. Software Engineering : A Practitioner's Approach. 6th Ed. McGraw-Hall. NY. 2005.
Diposkan oleh BLog ferly. . di 05:16 0 komentar
Extreme Programming
Extreme Programming – Melakukan Pengembangan Perangkat Lunak dengan Lebih Sederhana
Extreme Programming (berikutnya akan disingkat sebagai XP) adalah sebuah pendekatan atau model pengembangan perangkat lunak yang mencoba menyederhanakan berbagai tahapan dalam proses pengembangan tersebut sehingga menjadi lebih adaptif dan fleksibel. Walaupun menggunakan kata programming, XP bukan hanya berfokus pada coding tetapi meliputi seluruh area pengembangan perangkat lunak.
Sejarah XP
Proyek pengembangan perangkat lunak yang dianggap sebagai yang pertama kali menerapkan XP adalah C3 (Chrysler Comprehensive Compensation) Project dari Chrysler. Proyek ini adalah proyek penggajian 10.000 karyawan Chrysler, terdiri dari kira-kira 2000 class dan 30.000 method. Proyek yang dimulai pertengahan dekade 90-an ini terancam gagal karena rumitnya sistem yang dibangun dan kegagalan pada saat testing. Chrysler kemudian menyewa Kent Beck, seorang pakar software engineering yang di kemudian hari dikenal sebagai pencetus awal dari XP, untuk menyelamatkan proyek tersebut. Beck bersama rekannya Ron Jeffries dengan kewenangan yang diberikan oleh Chrysler melakukan berbagai perubahan di C3 Project untuk membuatnya lebih efisien, adaptif, dan fleksibel. Hal yang paling penting bagi mereka adalah harus mampu memenuhi permintaan utama dari Chrysler, untuk melakukan launching perangkat lunak tersebut dalam waktu tidak lebih dari dua tahun sejak saat Beck dikontrak.
Beck dan Jeffries pada akhirnya berhasil menyelesaikan target Chrysler dengan menerapkan berbagai metode dalam proses pengembangan perangkat lunak tersebut. Kumpulan metode inilah yang kemudian dikenal sebagai model atau pendekatan XP dalam pengembangan perangkat lunak. Begitu sederhananya metode-metode tersebut sehingga bagi orang yang belum menerapkan, XP terlihat sebagai kumpulan ide lama yang terlalu sederhana dan tidak akan memberikan efek apapun pada sebuah proyek pengembangan perangkat lunak.
Kent Beck sendiri mengakui dan menegaskan bahwa XP tidak selalu cocok untuk setiap proyek pengembangan perangkat lunak. Kelebihan XP adalah sesuai untuk digunakan pada proyek yang memiliki dynamic requirements. Proyek semacam ini memerlukan adaptasi cepat dalam mengatasi perubahan-perubahan yang terjadi selama proses pengembangan perangkat lunak. XP juga cocok untuk proyek dengan jumlah anggota tim tidak terlalu banyak (sekitar 10-20 orang) dan berada pada lokasi yang sama.
Nilai-nilai Dasar XP
Berikut adalah nilai-nilai mendasar yang menjadi roh dari XP pada setiap tahapan proses pengembangan perangkat lunak:
1. Communication
XP mengfokuskan pada hubungan komunikasi yang baik antar anggota tim. Para anggota tim harus membangun saling pengertian, mereka juga wajib saling berbagi pengetahuan dan keterampilan dalam mengembangkan perangkat lunak. Ego dari para programer yang biasaanya cukup tinggi harus ditekan dan mereka harus membuka diri untuk bekerjasama dengan programer lain dalam menuliskan kode program.
2. Courage
Para anggota tim dan penanggungjawab pengembangan perangkat lunak harus selalu memiliki keyakinan dan integritas dalam melakukan tugasnya. Integritas ini harus selalu dijaga bahkan dalam kondisi adanya tekanan dari situasi sekitar (misalnya oleh klien atau pemilik perusahaan). Untuk dapat melakukan sesuatu dengan penuh integritas terlebih dahulu para anggota tim harus terlebih dahulu memiliki rasa saling percaya. Rasa saling percaya inilah yang coba dibangun dan ditanamkan oleh XP pada berbagai aspeknya.
3. Simplicity
Lakukan semua dengan sederhana. Hal tersebut adalah salah satu nilai dasar dari XP. Gunakan method yang pendek dan simpel, jangan terlalu rumit dalam membuat desain, hilangkan fitur yang tidak ada gunanya, dan berbagai proses penyederhanaan lain akan selalu menjadi nilai utama dari setiap aspek XP.
4. Feedback
Berikan selalu feedback kepada sesama anggota tim maupun pihak-pihak lain yang terlibat dalam pengembangan perangkat lunak. Utarakan selalu pikiran anda dan diskusikan kesalahan-kesalahan yang muncul selama proses pengembangan. Dengarkan selalu pendapat rekan yang lain, dengan adanya feedback inilah seringkali kita menyadari bagian mana yang salah atau bisa ditingkatkan lagi dari perangkat lunak yang dikembangkan.
5. Quality Work
Semua nilai di atas berujung pada sebuah kondisi di mana kita melakukan pekerjaan dengan berkualitas. Dengan proses yang berkualitas maka implikasinya akan muncul pula perangkat lunak yang berkualitas sebagai hasil akhirnya.
Aspek Dasar XP
Aspek dasar XP terdiri dari berbagai teknik atau metode yang diterapkan Beck dan Jeffries pada C3 Project. Teknik-teknik tersebut dapat diamati pada gambar berikut ini:
1. The Planning Game
Pendekatan XP dalam perencanaan sangat mirip dengan metode yang diterapkan pada RAD (Rapid Application Development). Proses pendek dan cepat, mengutamakan aspek teknik, memisahkan unsur bisnis dengan unsur teknis dan pertemuan intensif antara klien dengan developer. Pada XP proses ini menggunakan terminologi “game” karena Beck menyarankan untuk menggunakan teknik score card dalam menentukan requirements. Semakin sulit aspek teknis yang dibutuhkan semakin tinggi pula skor pada kartu rencana tersebut.
2. Small Releases
Setiap release dilakukan dalam lingkup sekecil mungkin pada XP. Setiap developer menyelesaikan sebuah unit atau bagian dari perangkat lunak maka hasil tersebut harus segera dipresentasikan dan didiskusikan dengan klien. Jika memungkinkan untuk menerapkan unit tersebut pada perusahaan, hal itu juga dapat dilakukan sekaligus sebagai tes awal dari penerapan keseluruhan sistem. Kendati demikian hal ini tidak selalu perlu dilakukan karena harus dihitung terlebih dahulu sumberdaya yang dibutuhkan. Apakah lebih menguntungkan langsung melakukan tes terhadap unit tersebut atau melakukan tes setelah unit tersebut terintegrasi secara sempurna pada sistem.
3. Metaphor
Metaphor pada dasarnya sama dengan arsitektur perangkat lunak. Keduanya menggambarkan visi yang luas terhadap tujuan dari pengembangan perangkat lunak. Beck sendiri seperti para penandatangan Agile Manifesto lainnya bercita-cita menyederhanakan proses pengembangan perangkat lunak yang saat ini sudah dianggap terlalu rumit. Arsitektur yang saat ini banyak berisi diagram dan kode semacam UML dianggap terlalu rumit untuk dimengerti, terutama oleh klien. Metaphor, walaupun mirip dengan arsitektur lebih bersifat naratif dan deskriptif. Dengan demikian diharapkan komunikasi antara klien dengan developer akan berlangsung lebih baik dan lancar dengan penggunaan metaphor.
4. Simple Design
Sebagai salah seorang penandatangan Agile Manifesto, Beck adalah seorang yang tidak menyukai desain yang rumit dalam sebuah pengembangan perangkat lunak. Tidak heran jika dia memasukkan Simple Design sebagai salah satu unsur XP. Pada XP desain dibuat dalam lingkup kecil dan sederhana. Tidak perlu melakukan antisipasi terhadap berbagai perubahan di kemudian hari. Dengan desain yang simpel apabila terjadi perubahan maka membuat desain baru untuk mengatasi perubahan tersebut dapat dengan mudah dilakukan dan resiko kegagalan desain dapat diperkecil.
5. Refactoring
Refactoring adalah salah satu aspek paling khas dari XP. Refactoring seperti didefinisikan oleh Martin Fowler adalah ”Melakukan perubahan pada kode program dari perangkat lunak dengan tujuan meningkatkan kualitas dari struktur program tersebut tanpa mengubah cara program tersebut bekerja”. Refactoring sendiri sangat sesuai untuk menjadi bagian XP karena Refactoring mengusung konsep penyederhanaan dari proses desain maupun struktur baris kode program. Dengan Refactoring tim pengembang dapat melakukan berbagai usaha untuk meningkatkan kualitas program tanpa kembali mengulang-ulang proses desain. Fowler adalah salah satu kolega dekat dari Kent Beck karena itu tidak mengherankan bahwa cara berpikir mereka terhadap proses pengembangan perangkat lunak sangat mirip satu dengan lainnya.
6. Testing
XP menganut paradigma berbeda dalam hal tes dengan model pengembangan perangkat lunak lainnya. Jika pada pengembangan perangkat lunak lainnya tes baru dikembangkan setelah perangkat lunak selesai menjalani proses coding maka pada XP tim pengembang harus membuat terlebih dahulu tes yang hendak dijalani oleh perangkat lunak. Berbagai model tes yang mengantisipasi penerapan perangkat lunak pada sistem dikembangkan terlebih dahulu. Saat proses coding selesai dilakukan maka perangkat lunak diuji dengan model tes yang telah dibuat tersebut. Pengetesan akan jauh lebih baik apabila dilakukan pada setiap unit perangkat lunak dalam lingkup sekecil mungkin daripada menunggu sampai seluruh perangkat lunak selesai dibuat. Dengan memahami tahap ini kita dapat melihat bahwa siklus pada XP adalah requirement analysis à test à code à design. Sekilas terlihat hal ini tidak mungkin dilakukan tetapi pada kenyataannya memang gambaran inilah yang paling dapat menjelaskan tentang XP.
7. Pair Programming
Pair programming adalah melakukan proses menulis program dengan berpasangan. Dua orang programer saling bekerjasama di komputer yang sama untuk menyelesaikan sebuah unit. Dengan melakukan ini maka keduanya selalu dapat berdiskusi dan saling melakukan koreksi apabila ada kesalahan dalam penulisan program. Aspek ini mungkin akan sulit dijalankan oleh para programer yang memiliki ego tinggi dan sering tidak nyaman untuk berbagi komputer bersama rekannnya.
8. Collective Ownership
Tidak ada satupun baris kode program yang hanya dipahami oleh satu orang programer. XP menuntut para programer untuk berbagi pengetahuan untuk tiap baris program bahkan beserta hak untuk mengubahnya. Dengan pemahaman yang sama terhadap keseluruhan program, ketergantungan pada programer tertentu ataupun berbagai hambatan akibat perbedaan gaya menulis program dapat diperkecil. Pada level yang lebih tinggi bahkan dimungkinkan para programer dapat bertukar unit yang dibangunnya.
9. Coding Standards
Pair programming dan collective ownership hanya akan dapat berjalan dengan baik apabila para programer memiliki pemahaman yang sama terhadap penulisan kode program. Dengan adanya coding standards yang telah disepakati terlebih dahulu maka pemahaman terhadap program akan menjadi mudah untuk semua programer dalam tim. Hal ini dapat diterapkan sebagai contoh pada penamaan variabel dan penggunaan tipe data yang sama untuk tiap elemen semua record atau array pada program.
10. Continous Integration
Melakukan build setiap hari kerja menjadi sebuah model yang disukai oleh berbagai tim pengembang perangkat lunak. Hal ini terutama didorong oleh keberhasilan penerapan sistem ini oleh Microsoft dan telah sering dipublikasikan. Dengan melakukan build sesering mungkin berbagai kesalahan pada program dapat dideteksi dan diperbaiki secepat mungkin. Apabila banyak tim pengembang perangkat lunak meyakini bahwa build sekali sehari adalah minimum maka pada XP hal tersebut adalah maksimum. Pada XP tim disarankan untuk melakukan build sesering mungkin misalnya setiap 4 jam atau bahkan lebih cepat lagi.
11. 40-hours Week
Beck berpendapat bekerja 8 jam sehari dan 5 hari seminggu adalah maksimal untuk tiap programer. Lebih dari itu programer akan cenderung membuat berbagai error pada baris-baris kode programnya karena kelelahan.
12. On-Site Customer
Sebuah pendekatan klasik, di mana XP menganjurkan bahwa ada anggota dari klien yang terlibat pada proses pengembangan perangkat lunak. Yang lebih penting lagi ia harus ada di tempat pemrogaman dan turut serta dalam proses build dan test yang dilakukan. Apabila ada kesalahan dalam pengembangan diharapkan klien dapat segera memberikan masukan untuk koreksinya.
(Kutipan dari : http://ilmukomputer.org/2008/05/28/extreme-programming-%E2%80%93-melakukan-pengembangan-perangkat-lunak-dengan-lebih-sederhana/
Diposkan oleh BLog ferly. . di 05:23 0 komentar
tugas,,, 2
Sabtu, 2009 Maret 21
Agile Programming
Kata Agile berarti bersifat cepat, ringan, bebas bergerak, waspada. Kata ini digunakan sebagai kata yang mengambarkan konsep model proses yang berbeda dari konsep model-model proses yang sudah ada. Konsep Agile Software Development dicetuskan oleh Kent Beck dan 16 rekannya dengan menyatakan bahwa Agile Software Development adalah cara membangun software dengan melakukannya dan membantu orang lain membangunnya sekaligus.
Dalam Agile Software Development interaksi dan personel lebih penting dari pada proses dan alat, software yang berfungsi lebih penting daripada dokumentasi yang lengkap, kolaborasi dengan klien lebih penting dari pada negosiasi kontrak, dan sikap tanggap terhadap perubahan lebih penting daripada mengikuti rencana. Namun demikian, sama seperti model proses yang lain, Agile Software Development memiliki kelebihan dan tidak cocok untuk semua jenis proyek, produk, orang dan situasi.
Agile Software Development memungkinkan model proses yang toleransi terhadap perubahan kebutuhan sehingga perubahan dapat cepat ditanggapi. Namun di sisi lain menyebabkan produktifitas menurun.
Prinsip Agile Software Development
Salah satu ciri dari Agile Software Development adalah tim yang tanggap terhadap perubahan. Mengapa? Karena perubahan adalah hal yang utama dalam pembangunan software: perubahan kebutuhan software, perubahan anggota tim, perubahan teknologi dll. Selain itu Agile Software
Development juga melihat pentingnya komunikasi antara anggota tim, antara orang-orang teknis dan businessmen, antara developer dan managernya. Ciri lain adalah klien menjadi bagian dari tim pembangun software. Ciri-ciri ini didukung oleh 12 prinsip yang ditetapkan oleh Agile Alliance.
Menurut Agile Alliance, 12 prinsip ini adalah bagi mereka yang ingin berhasil dalam penerapan Agile Software Development:
1. kepuasan klien adalah prioritas utama dengan menghasilkan produk lebih awal dan terus menerus
2. menerima perubahan kebutuhan, sekalipun diakhir pengembangan.
3. Penyerahan hasil/software dalam hitungan waktu dua minggu sampai dua bulan.
4. Bagian bisnis dan pembangun kerja sama tiap hari selama proyek berlangsung
5. Membangun proyek dilingkungan orang-orang yang bermotivasi tinggi yang bekerja dalam lingkungan yang mendukun dan yang dipercaya untuk dapat menyelesaikan proyek.
6. Komunikasi dengan berhadapan langsung adalah komunikasi yang efektif dan efisien
7. Software yang berfungsi adalah ukuran utama dari kemajuan proyek
8. dukungan yang stabil dari sponsor, pembangun, dan pengguna diperlukan untuk menjaga perkembangan yang berkesinambungan
9. perhatian kepada kehebatan teknis dan desain yang bagus meningkatkan sifat agile
10. kesederhanaan penting
11. arsitektur, kebutuhan dan desain yang bagus muncuk dari tim yang mengatur dirinya sendiri
12. secara periodik tim evaluasi diri dan mencari cara untuk lebih efektif dan segera melakukannya.
Kedua belas prinsip tersebut menjadi suatu dasar bagi model-model proses yang punya sifat agile. Dengan prinsip-prinsip tersebur Agile Process Model berusaha untuk menyiasati 3 asumsi penting tentang proyek software pada umumnya:
1. kebutuhan software sulit diprediksi dari awal dan selalu akan berubah. Selain itu, prioritas klien juga sering berubah seiring berjalannya proyek.
2. Desain dan pembangunan sering tumpang tindih. Sulit diperkirakan seberapa jauh desain yang diperlukan sebelum pembangunan.
3. Analisis, desain, pembangunan dan testing tidak dapat diperkirakan seperti yang diinginkan.
Agile Process Model
Berikut ini adalah model-model proses yang termasuk agile process model :
1. XP(Extreme Programming)
2. ADAPTIVE SOFTWARE DEVELOPMENT (ASD)
3. DYNAMIC SYSTEMS DEVELOPMENT METHOD
4. SCRUM
5. Agile Modelling
Diakses di http://www.agilemodeling.com/essays/introductionToAM.htm 07/09/08.
Pressman, Roger S. Software Engineering : A Practitioner's Approach. 6th Ed. McGraw-Hall. NY. 2005.
Diposkan oleh BLog ferly. . di 05:16 0 komentar
Extreme Programming
Extreme Programming – Melakukan Pengembangan Perangkat Lunak dengan Lebih Sederhana
Extreme Programming (berikutnya akan disingkat sebagai XP) adalah sebuah pendekatan atau model pengembangan perangkat lunak yang mencoba menyederhanakan berbagai tahapan dalam proses pengembangan tersebut sehingga menjadi lebih adaptif dan fleksibel. Walaupun menggunakan kata programming, XP bukan hanya berfokus pada coding tetapi meliputi seluruh area pengembangan perangkat lunak.
Sejarah XP
Proyek pengembangan perangkat lunak yang dianggap sebagai yang pertama kali menerapkan XP adalah C3 (Chrysler Comprehensive Compensation) Project dari Chrysler. Proyek ini adalah proyek penggajian 10.000 karyawan Chrysler, terdiri dari kira-kira 2000 class dan 30.000 method. Proyek yang dimulai pertengahan dekade 90-an ini terancam gagal karena rumitnya sistem yang dibangun dan kegagalan pada saat testing. Chrysler kemudian menyewa Kent Beck, seorang pakar software engineering yang di kemudian hari dikenal sebagai pencetus awal dari XP, untuk menyelamatkan proyek tersebut. Beck bersama rekannya Ron Jeffries dengan kewenangan yang diberikan oleh Chrysler melakukan berbagai perubahan di C3 Project untuk membuatnya lebih efisien, adaptif, dan fleksibel. Hal yang paling penting bagi mereka adalah harus mampu memenuhi permintaan utama dari Chrysler, untuk melakukan launching perangkat lunak tersebut dalam waktu tidak lebih dari dua tahun sejak saat Beck dikontrak.
Beck dan Jeffries pada akhirnya berhasil menyelesaikan target Chrysler dengan menerapkan berbagai metode dalam proses pengembangan perangkat lunak tersebut. Kumpulan metode inilah yang kemudian dikenal sebagai model atau pendekatan XP dalam pengembangan perangkat lunak. Begitu sederhananya metode-metode tersebut sehingga bagi orang yang belum menerapkan, XP terlihat sebagai kumpulan ide lama yang terlalu sederhana dan tidak akan memberikan efek apapun pada sebuah proyek pengembangan perangkat lunak.
Kent Beck sendiri mengakui dan menegaskan bahwa XP tidak selalu cocok untuk setiap proyek pengembangan perangkat lunak. Kelebihan XP adalah sesuai untuk digunakan pada proyek yang memiliki dynamic requirements. Proyek semacam ini memerlukan adaptasi cepat dalam mengatasi perubahan-perubahan yang terjadi selama proses pengembangan perangkat lunak. XP juga cocok untuk proyek dengan jumlah anggota tim tidak terlalu banyak (sekitar 10-20 orang) dan berada pada lokasi yang sama.
Nilai-nilai Dasar XP
Berikut adalah nilai-nilai mendasar yang menjadi roh dari XP pada setiap tahapan proses pengembangan perangkat lunak:
1. Communication
XP mengfokuskan pada hubungan komunikasi yang baik antar anggota tim. Para anggota tim harus membangun saling pengertian, mereka juga wajib saling berbagi pengetahuan dan keterampilan dalam mengembangkan perangkat lunak. Ego dari para programer yang biasaanya cukup tinggi harus ditekan dan mereka harus membuka diri untuk bekerjasama dengan programer lain dalam menuliskan kode program.
2. Courage
Para anggota tim dan penanggungjawab pengembangan perangkat lunak harus selalu memiliki keyakinan dan integritas dalam melakukan tugasnya. Integritas ini harus selalu dijaga bahkan dalam kondisi adanya tekanan dari situasi sekitar (misalnya oleh klien atau pemilik perusahaan). Untuk dapat melakukan sesuatu dengan penuh integritas terlebih dahulu para anggota tim harus terlebih dahulu memiliki rasa saling percaya. Rasa saling percaya inilah yang coba dibangun dan ditanamkan oleh XP pada berbagai aspeknya.
3. Simplicity
Lakukan semua dengan sederhana. Hal tersebut adalah salah satu nilai dasar dari XP. Gunakan method yang pendek dan simpel, jangan terlalu rumit dalam membuat desain, hilangkan fitur yang tidak ada gunanya, dan berbagai proses penyederhanaan lain akan selalu menjadi nilai utama dari setiap aspek XP.
4. Feedback
Berikan selalu feedback kepada sesama anggota tim maupun pihak-pihak lain yang terlibat dalam pengembangan perangkat lunak. Utarakan selalu pikiran anda dan diskusikan kesalahan-kesalahan yang muncul selama proses pengembangan. Dengarkan selalu pendapat rekan yang lain, dengan adanya feedback inilah seringkali kita menyadari bagian mana yang salah atau bisa ditingkatkan lagi dari perangkat lunak yang dikembangkan.
5. Quality Work
Semua nilai di atas berujung pada sebuah kondisi di mana kita melakukan pekerjaan dengan berkualitas. Dengan proses yang berkualitas maka implikasinya akan muncul pula perangkat lunak yang berkualitas sebagai hasil akhirnya.
Aspek Dasar XP
Aspek dasar XP terdiri dari berbagai teknik atau metode yang diterapkan Beck dan Jeffries pada C3 Project. Teknik-teknik tersebut dapat diamati pada gambar berikut ini:
1. The Planning Game
Pendekatan XP dalam perencanaan sangat mirip dengan metode yang diterapkan pada RAD (Rapid Application Development). Proses pendek dan cepat, mengutamakan aspek teknik, memisahkan unsur bisnis dengan unsur teknis dan pertemuan intensif antara klien dengan developer. Pada XP proses ini menggunakan terminologi “game” karena Beck menyarankan untuk menggunakan teknik score card dalam menentukan requirements. Semakin sulit aspek teknis yang dibutuhkan semakin tinggi pula skor pada kartu rencana tersebut.
2. Small Releases
Setiap release dilakukan dalam lingkup sekecil mungkin pada XP. Setiap developer menyelesaikan sebuah unit atau bagian dari perangkat lunak maka hasil tersebut harus segera dipresentasikan dan didiskusikan dengan klien. Jika memungkinkan untuk menerapkan unit tersebut pada perusahaan, hal itu juga dapat dilakukan sekaligus sebagai tes awal dari penerapan keseluruhan sistem. Kendati demikian hal ini tidak selalu perlu dilakukan karena harus dihitung terlebih dahulu sumberdaya yang dibutuhkan. Apakah lebih menguntungkan langsung melakukan tes terhadap unit tersebut atau melakukan tes setelah unit tersebut terintegrasi secara sempurna pada sistem.
3. Metaphor
Metaphor pada dasarnya sama dengan arsitektur perangkat lunak. Keduanya menggambarkan visi yang luas terhadap tujuan dari pengembangan perangkat lunak. Beck sendiri seperti para penandatangan Agile Manifesto lainnya bercita-cita menyederhanakan proses pengembangan perangkat lunak yang saat ini sudah dianggap terlalu rumit. Arsitektur yang saat ini banyak berisi diagram dan kode semacam UML dianggap terlalu rumit untuk dimengerti, terutama oleh klien. Metaphor, walaupun mirip dengan arsitektur lebih bersifat naratif dan deskriptif. Dengan demikian diharapkan komunikasi antara klien dengan developer akan berlangsung lebih baik dan lancar dengan penggunaan metaphor.
4. Simple Design
Sebagai salah seorang penandatangan Agile Manifesto, Beck adalah seorang yang tidak menyukai desain yang rumit dalam sebuah pengembangan perangkat lunak. Tidak heran jika dia memasukkan Simple Design sebagai salah satu unsur XP. Pada XP desain dibuat dalam lingkup kecil dan sederhana. Tidak perlu melakukan antisipasi terhadap berbagai perubahan di kemudian hari. Dengan desain yang simpel apabila terjadi perubahan maka membuat desain baru untuk mengatasi perubahan tersebut dapat dengan mudah dilakukan dan resiko kegagalan desain dapat diperkecil.
5. Refactoring
Refactoring adalah salah satu aspek paling khas dari XP. Refactoring seperti didefinisikan oleh Martin Fowler adalah ”Melakukan perubahan pada kode program dari perangkat lunak dengan tujuan meningkatkan kualitas dari struktur program tersebut tanpa mengubah cara program tersebut bekerja”. Refactoring sendiri sangat sesuai untuk menjadi bagian XP karena Refactoring mengusung konsep penyederhanaan dari proses desain maupun struktur baris kode program. Dengan Refactoring tim pengembang dapat melakukan berbagai usaha untuk meningkatkan kualitas program tanpa kembali mengulang-ulang proses desain. Fowler adalah salah satu kolega dekat dari Kent Beck karena itu tidak mengherankan bahwa cara berpikir mereka terhadap proses pengembangan perangkat lunak sangat mirip satu dengan lainnya.
6. Testing
XP menganut paradigma berbeda dalam hal tes dengan model pengembangan perangkat lunak lainnya. Jika pada pengembangan perangkat lunak lainnya tes baru dikembangkan setelah perangkat lunak selesai menjalani proses coding maka pada XP tim pengembang harus membuat terlebih dahulu tes yang hendak dijalani oleh perangkat lunak. Berbagai model tes yang mengantisipasi penerapan perangkat lunak pada sistem dikembangkan terlebih dahulu. Saat proses coding selesai dilakukan maka perangkat lunak diuji dengan model tes yang telah dibuat tersebut. Pengetesan akan jauh lebih baik apabila dilakukan pada setiap unit perangkat lunak dalam lingkup sekecil mungkin daripada menunggu sampai seluruh perangkat lunak selesai dibuat. Dengan memahami tahap ini kita dapat melihat bahwa siklus pada XP adalah requirement analysis à test à code à design. Sekilas terlihat hal ini tidak mungkin dilakukan tetapi pada kenyataannya memang gambaran inilah yang paling dapat menjelaskan tentang XP.
7. Pair Programming
Pair programming adalah melakukan proses menulis program dengan berpasangan. Dua orang programer saling bekerjasama di komputer yang sama untuk menyelesaikan sebuah unit. Dengan melakukan ini maka keduanya selalu dapat berdiskusi dan saling melakukan koreksi apabila ada kesalahan dalam penulisan program. Aspek ini mungkin akan sulit dijalankan oleh para programer yang memiliki ego tinggi dan sering tidak nyaman untuk berbagi komputer bersama rekannnya.
8. Collective Ownership
Tidak ada satupun baris kode program yang hanya dipahami oleh satu orang programer. XP menuntut para programer untuk berbagi pengetahuan untuk tiap baris program bahkan beserta hak untuk mengubahnya. Dengan pemahaman yang sama terhadap keseluruhan program, ketergantungan pada programer tertentu ataupun berbagai hambatan akibat perbedaan gaya menulis program dapat diperkecil. Pada level yang lebih tinggi bahkan dimungkinkan para programer dapat bertukar unit yang dibangunnya.
9. Coding Standards
Pair programming dan collective ownership hanya akan dapat berjalan dengan baik apabila para programer memiliki pemahaman yang sama terhadap penulisan kode program. Dengan adanya coding standards yang telah disepakati terlebih dahulu maka pemahaman terhadap program akan menjadi mudah untuk semua programer dalam tim. Hal ini dapat diterapkan sebagai contoh pada penamaan variabel dan penggunaan tipe data yang sama untuk tiap elemen semua record atau array pada program.
10. Continous Integration
Melakukan build setiap hari kerja menjadi sebuah model yang disukai oleh berbagai tim pengembang perangkat lunak. Hal ini terutama didorong oleh keberhasilan penerapan sistem ini oleh Microsoft dan telah sering dipublikasikan. Dengan melakukan build sesering mungkin berbagai kesalahan pada program dapat dideteksi dan diperbaiki secepat mungkin. Apabila banyak tim pengembang perangkat lunak meyakini bahwa build sekali sehari adalah minimum maka pada XP hal tersebut adalah maksimum. Pada XP tim disarankan untuk melakukan build sesering mungkin misalnya setiap 4 jam atau bahkan lebih cepat lagi.
11. 40-hours Week
Beck berpendapat bekerja 8 jam sehari dan 5 hari seminggu adalah maksimal untuk tiap programer. Lebih dari itu programer akan cenderung membuat berbagai error pada baris-baris kode programnya karena kelelahan.
12. On-Site Customer
Sebuah pendekatan klasik, di mana XP menganjurkan bahwa ada anggota dari klien yang terlibat pada proses pengembangan perangkat lunak. Yang lebih penting lagi ia harus ada di tempat pemrogaman dan turut serta dalam proses build dan test yang dilakukan. Apabila ada kesalahan dalam pengembangan diharapkan klien dapat segera memberikan masukan untuk koreksinya.
(Kutipan dari : http://ilmukomputer.org/2008/05/28/extreme-programming-%E2%80%93-melakukan-pengembangan-perangkat-lunak-dengan-lebih-sederhana/
Diposkan oleh BLog ferly. . di 05:23 0 komentar
Agile Programming
Kata Agile berarti bersifat cepat, ringan, bebas bergerak, waspada. Kata ini digunakan sebagai kata yang mengambarkan konsep model proses yang berbeda dari konsep model-model proses yang sudah ada. Konsep Agile Software Development dicetuskan oleh Kent Beck dan 16 rekannya dengan menyatakan bahwa Agile Software Development adalah cara membangun software dengan melakukannya dan membantu orang lain membangunnya sekaligus.
Dalam Agile Software Development interaksi dan personel lebih penting dari pada proses dan alat, software yang berfungsi lebih penting daripada dokumentasi yang lengkap, kolaborasi dengan klien lebih penting dari pada negosiasi kontrak, dan sikap tanggap terhadap perubahan lebih penting daripada mengikuti rencana. Namun demikian, sama seperti model proses yang lain, Agile Software Development memiliki kelebihan dan tidak cocok untuk semua jenis proyek, produk, orang dan situasi.
Agile Software Development memungkinkan model proses yang toleransi terhadap perubahan kebutuhan sehingga perubahan dapat cepat ditanggapi. Namun di sisi lain menyebabkan produktifitas menurun.
Prinsip Agile Software Development
Salah satu ciri dari Agile Software Development adalah tim yang tanggap terhadap perubahan. Mengapa? Karena perubahan adalah hal yang utama dalam pembangunan software: perubahan kebutuhan software, perubahan anggota tim, perubahan teknologi dll. Selain itu Agile Software
Development juga melihat pentingnya komunikasi antara anggota tim, antara orang-orang teknis dan businessmen, antara developer dan managernya. Ciri lain adalah klien menjadi bagian dari tim pembangun software. Ciri-ciri ini didukung oleh 12 prinsip yang ditetapkan oleh Agile Alliance.
Menurut Agile Alliance, 12 prinsip ini adalah bagi mereka yang ingin berhasil dalam penerapan Agile Software Development:
1. kepuasan klien adalah prioritas utama dengan menghasilkan produk lebih awal dan terus menerus
2. menerima perubahan kebutuhan, sekalipun diakhir pengembangan.
3. Penyerahan hasil/software dalam hitungan waktu dua minggu sampai dua bulan.
4. Bagian bisnis dan pembangun kerja sama tiap hari selama proyek berlangsung
5. Membangun proyek dilingkungan orang-orang yang bermotivasi tinggi yang bekerja dalam lingkungan yang mendukun dan yang dipercaya untuk dapat menyelesaikan proyek.
6. Komunikasi dengan berhadapan langsung adalah komunikasi yang efektif dan efisien
7. Software yang berfungsi adalah ukuran utama dari kemajuan proyek
8. dukungan yang stabil dari sponsor, pembangun, dan pengguna diperlukan untuk menjaga perkembangan yang berkesinambungan
9. perhatian kepada kehebatan teknis dan desain yang bagus meningkatkan sifat agile
10. kesederhanaan penting
11. arsitektur, kebutuhan dan desain yang bagus muncuk dari tim yang mengatur dirinya sendiri
12. secara periodik tim evaluasi diri dan mencari cara untuk lebih efektif dan segera melakukannya.
Kedua belas prinsip tersebut menjadi suatu dasar bagi model-model proses yang punya sifat agile. Dengan prinsip-prinsip tersebur Agile Process Model berusaha untuk menyiasati 3 asumsi penting tentang proyek software pada umumnya:
1. kebutuhan software sulit diprediksi dari awal dan selalu akan berubah. Selain itu, prioritas klien juga sering berubah seiring berjalannya proyek.
2. Desain dan pembangunan sering tumpang tindih. Sulit diperkirakan seberapa jauh desain yang diperlukan sebelum pembangunan.
3. Analisis, desain, pembangunan dan testing tidak dapat diperkirakan seperti yang diinginkan.
Agile Process Model
Berikut ini adalah model-model proses yang termasuk agile process model :
1. XP(Extreme Programming)
2. ADAPTIVE SOFTWARE DEVELOPMENT (ASD)
3. DYNAMIC SYSTEMS DEVELOPMENT METHOD
4. SCRUM
5. Agile Modelling
Diakses di http://www.agilemodeling.com/essays/introductionToAM.htm 07/09/08.
Pressman, Roger S. Software Engineering : A Practitioner's Approach. 6th Ed. McGraw-Hall. NY. 2005.
Diposkan oleh BLog ferly. . di 05:16 0 komentar
Extreme Programming
Extreme Programming – Melakukan Pengembangan Perangkat Lunak dengan Lebih Sederhana
Extreme Programming (berikutnya akan disingkat sebagai XP) adalah sebuah pendekatan atau model pengembangan perangkat lunak yang mencoba menyederhanakan berbagai tahapan dalam proses pengembangan tersebut sehingga menjadi lebih adaptif dan fleksibel. Walaupun menggunakan kata programming, XP bukan hanya berfokus pada coding tetapi meliputi seluruh area pengembangan perangkat lunak.
Sejarah XP
Proyek pengembangan perangkat lunak yang dianggap sebagai yang pertama kali menerapkan XP adalah C3 (Chrysler Comprehensive Compensation) Project dari Chrysler. Proyek ini adalah proyek penggajian 10.000 karyawan Chrysler, terdiri dari kira-kira 2000 class dan 30.000 method. Proyek yang dimulai pertengahan dekade 90-an ini terancam gagal karena rumitnya sistem yang dibangun dan kegagalan pada saat testing. Chrysler kemudian menyewa Kent Beck, seorang pakar software engineering yang di kemudian hari dikenal sebagai pencetus awal dari XP, untuk menyelamatkan proyek tersebut. Beck bersama rekannya Ron Jeffries dengan kewenangan yang diberikan oleh Chrysler melakukan berbagai perubahan di C3 Project untuk membuatnya lebih efisien, adaptif, dan fleksibel. Hal yang paling penting bagi mereka adalah harus mampu memenuhi permintaan utama dari Chrysler, untuk melakukan launching perangkat lunak tersebut dalam waktu tidak lebih dari dua tahun sejak saat Beck dikontrak.
Beck dan Jeffries pada akhirnya berhasil menyelesaikan target Chrysler dengan menerapkan berbagai metode dalam proses pengembangan perangkat lunak tersebut. Kumpulan metode inilah yang kemudian dikenal sebagai model atau pendekatan XP dalam pengembangan perangkat lunak. Begitu sederhananya metode-metode tersebut sehingga bagi orang yang belum menerapkan, XP terlihat sebagai kumpulan ide lama yang terlalu sederhana dan tidak akan memberikan efek apapun pada sebuah proyek pengembangan perangkat lunak.
Kent Beck sendiri mengakui dan menegaskan bahwa XP tidak selalu cocok untuk setiap proyek pengembangan perangkat lunak. Kelebihan XP adalah sesuai untuk digunakan pada proyek yang memiliki dynamic requirements. Proyek semacam ini memerlukan adaptasi cepat dalam mengatasi perubahan-perubahan yang terjadi selama proses pengembangan perangkat lunak. XP juga cocok untuk proyek dengan jumlah anggota tim tidak terlalu banyak (sekitar 10-20 orang) dan berada pada lokasi yang sama.
Nilai-nilai Dasar XP
Berikut adalah nilai-nilai mendasar yang menjadi roh dari XP pada setiap tahapan proses pengembangan perangkat lunak:
1. Communication
XP mengfokuskan pada hubungan komunikasi yang baik antar anggota tim. Para anggota tim harus membangun saling pengertian, mereka juga wajib saling berbagi pengetahuan dan keterampilan dalam mengembangkan perangkat lunak. Ego dari para programer yang biasaanya cukup tinggi harus ditekan dan mereka harus membuka diri untuk bekerjasama dengan programer lain dalam menuliskan kode program.
2. Courage
Para anggota tim dan penanggungjawab pengembangan perangkat lunak harus selalu memiliki keyakinan dan integritas dalam melakukan tugasnya. Integritas ini harus selalu dijaga bahkan dalam kondisi adanya tekanan dari situasi sekitar (misalnya oleh klien atau pemilik perusahaan). Untuk dapat melakukan sesuatu dengan penuh integritas terlebih dahulu para anggota tim harus terlebih dahulu memiliki rasa saling percaya. Rasa saling percaya inilah yang coba dibangun dan ditanamkan oleh XP pada berbagai aspeknya.
3. Simplicity
Lakukan semua dengan sederhana. Hal tersebut adalah salah satu nilai dasar dari XP. Gunakan method yang pendek dan simpel, jangan terlalu rumit dalam membuat desain, hilangkan fitur yang tidak ada gunanya, dan berbagai proses penyederhanaan lain akan selalu menjadi nilai utama dari setiap aspek XP.
4. Feedback
Berikan selalu feedback kepada sesama anggota tim maupun pihak-pihak lain yang terlibat dalam pengembangan perangkat lunak. Utarakan selalu pikiran anda dan diskusikan kesalahan-kesalahan yang muncul selama proses pengembangan. Dengarkan selalu pendapat rekan yang lain, dengan adanya feedback inilah seringkali kita menyadari bagian mana yang salah atau bisa ditingkatkan lagi dari perangkat lunak yang dikembangkan.
5. Quality Work
Semua nilai di atas berujung pada sebuah kondisi di mana kita melakukan pekerjaan dengan berkualitas. Dengan proses yang berkualitas maka implikasinya akan muncul pula perangkat lunak yang berkualitas sebagai hasil akhirnya.
Aspek Dasar XP
Aspek dasar XP terdiri dari berbagai teknik atau metode yang diterapkan Beck dan Jeffries pada C3 Project. Teknik-teknik tersebut dapat diamati pada gambar berikut ini:
1. The Planning Game
Pendekatan XP dalam perencanaan sangat mirip dengan metode yang diterapkan pada RAD (Rapid Application Development). Proses pendek dan cepat, mengutamakan aspek teknik, memisahkan unsur bisnis dengan unsur teknis dan pertemuan intensif antara klien dengan developer. Pada XP proses ini menggunakan terminologi “game” karena Beck menyarankan untuk menggunakan teknik score card dalam menentukan requirements. Semakin sulit aspek teknis yang dibutuhkan semakin tinggi pula skor pada kartu rencana tersebut.
2. Small Releases
Setiap release dilakukan dalam lingkup sekecil mungkin pada XP. Setiap developer menyelesaikan sebuah unit atau bagian dari perangkat lunak maka hasil tersebut harus segera dipresentasikan dan didiskusikan dengan klien. Jika memungkinkan untuk menerapkan unit tersebut pada perusahaan, hal itu juga dapat dilakukan sekaligus sebagai tes awal dari penerapan keseluruhan sistem. Kendati demikian hal ini tidak selalu perlu dilakukan karena harus dihitung terlebih dahulu sumberdaya yang dibutuhkan. Apakah lebih menguntungkan langsung melakukan tes terhadap unit tersebut atau melakukan tes setelah unit tersebut terintegrasi secara sempurna pada sistem.
3. Metaphor
Metaphor pada dasarnya sama dengan arsitektur perangkat lunak. Keduanya menggambarkan visi yang luas terhadap tujuan dari pengembangan perangkat lunak. Beck sendiri seperti para penandatangan Agile Manifesto lainnya bercita-cita menyederhanakan proses pengembangan perangkat lunak yang saat ini sudah dianggap terlalu rumit. Arsitektur yang saat ini banyak berisi diagram dan kode semacam UML dianggap terlalu rumit untuk dimengerti, terutama oleh klien. Metaphor, walaupun mirip dengan arsitektur lebih bersifat naratif dan deskriptif. Dengan demikian diharapkan komunikasi antara klien dengan developer akan berlangsung lebih baik dan lancar dengan penggunaan metaphor.
4. Simple Design
Sebagai salah seorang penandatangan Agile Manifesto, Beck adalah seorang yang tidak menyukai desain yang rumit dalam sebuah pengembangan perangkat lunak. Tidak heran jika dia memasukkan Simple Design sebagai salah satu unsur XP. Pada XP desain dibuat dalam lingkup kecil dan sederhana. Tidak perlu melakukan antisipasi terhadap berbagai perubahan di kemudian hari. Dengan desain yang simpel apabila terjadi perubahan maka membuat desain baru untuk mengatasi perubahan tersebut dapat dengan mudah dilakukan dan resiko kegagalan desain dapat diperkecil.
5. Refactoring
Refactoring adalah salah satu aspek paling khas dari XP. Refactoring seperti didefinisikan oleh Martin Fowler adalah ”Melakukan perubahan pada kode program dari perangkat lunak dengan tujuan meningkatkan kualitas dari struktur program tersebut tanpa mengubah cara program tersebut bekerja”. Refactoring sendiri sangat sesuai untuk menjadi bagian XP karena Refactoring mengusung konsep penyederhanaan dari proses desain maupun struktur baris kode program. Dengan Refactoring tim pengembang dapat melakukan berbagai usaha untuk meningkatkan kualitas program tanpa kembali mengulang-ulang proses desain. Fowler adalah salah satu kolega dekat dari Kent Beck karena itu tidak mengherankan bahwa cara berpikir mereka terhadap proses pengembangan perangkat lunak sangat mirip satu dengan lainnya.
6. Testing
XP menganut paradigma berbeda dalam hal tes dengan model pengembangan perangkat lunak lainnya. Jika pada pengembangan perangkat lunak lainnya tes baru dikembangkan setelah perangkat lunak selesai menjalani proses coding maka pada XP tim pengembang harus membuat terlebih dahulu tes yang hendak dijalani oleh perangkat lunak. Berbagai model tes yang mengantisipasi penerapan perangkat lunak pada sistem dikembangkan terlebih dahulu. Saat proses coding selesai dilakukan maka perangkat lunak diuji dengan model tes yang telah dibuat tersebut. Pengetesan akan jauh lebih baik apabila dilakukan pada setiap unit perangkat lunak dalam lingkup sekecil mungkin daripada menunggu sampai seluruh perangkat lunak selesai dibuat. Dengan memahami tahap ini kita dapat melihat bahwa siklus pada XP adalah requirement analysis à test à code à design. Sekilas terlihat hal ini tidak mungkin dilakukan tetapi pada kenyataannya memang gambaran inilah yang paling dapat menjelaskan tentang XP.
7. Pair Programming
Pair programming adalah melakukan proses menulis program dengan berpasangan. Dua orang programer saling bekerjasama di komputer yang sama untuk menyelesaikan sebuah unit. Dengan melakukan ini maka keduanya selalu dapat berdiskusi dan saling melakukan koreksi apabila ada kesalahan dalam penulisan program. Aspek ini mungkin akan sulit dijalankan oleh para programer yang memiliki ego tinggi dan sering tidak nyaman untuk berbagi komputer bersama rekannnya.
8. Collective Ownership
Tidak ada satupun baris kode program yang hanya dipahami oleh satu orang programer. XP menuntut para programer untuk berbagi pengetahuan untuk tiap baris program bahkan beserta hak untuk mengubahnya. Dengan pemahaman yang sama terhadap keseluruhan program, ketergantungan pada programer tertentu ataupun berbagai hambatan akibat perbedaan gaya menulis program dapat diperkecil. Pada level yang lebih tinggi bahkan dimungkinkan para programer dapat bertukar unit yang dibangunnya.
9. Coding Standards
Pair programming dan collective ownership hanya akan dapat berjalan dengan baik apabila para programer memiliki pemahaman yang sama terhadap penulisan kode program. Dengan adanya coding standards yang telah disepakati terlebih dahulu maka pemahaman terhadap program akan menjadi mudah untuk semua programer dalam tim. Hal ini dapat diterapkan sebagai contoh pada penamaan variabel dan penggunaan tipe data yang sama untuk tiap elemen semua record atau array pada program.
10. Continous Integration
Melakukan build setiap hari kerja menjadi sebuah model yang disukai oleh berbagai tim pengembang perangkat lunak. Hal ini terutama didorong oleh keberhasilan penerapan sistem ini oleh Microsoft dan telah sering dipublikasikan. Dengan melakukan build sesering mungkin berbagai kesalahan pada program dapat dideteksi dan diperbaiki secepat mungkin. Apabila banyak tim pengembang perangkat lunak meyakini bahwa build sekali sehari adalah minimum maka pada XP hal tersebut adalah maksimum. Pada XP tim disarankan untuk melakukan build sesering mungkin misalnya setiap 4 jam atau bahkan lebih cepat lagi.
11. 40-hours Week
Beck berpendapat bekerja 8 jam sehari dan 5 hari seminggu adalah maksimal untuk tiap programer. Lebih dari itu programer akan cenderung membuat berbagai error pada baris-baris kode programnya karena kelelahan.
12. On-Site Customer
Sebuah pendekatan klasik, di mana XP menganjurkan bahwa ada anggota dari klien yang terlibat pada proses pengembangan perangkat lunak. Yang lebih penting lagi ia harus ada di tempat pemrogaman dan turut serta dalam proses build dan test yang dilakukan. Apabila ada kesalahan dalam pengembangan diharapkan klien dapat segera memberikan masukan untuk koreksinya.
(Kutipan dari : http://ilmukomputer.org/2008/05/28/extreme-programming-%E2%80%93-melakukan-pengembangan-perangkat-lunak-dengan-lebih-sederhana/
Diposkan oleh BLog ferly. . di 05:23 0 komentar
Minggu, 15 Maret 2009
Sabtu, 07 Maret 2009
tugas....
SOFTWARE YANG MENGGUNAKAN ALGORITMA SEMUT
TUGAS RPL 4..
KECERDASAN KOLEKTIF
Komunitas hewan mampu melakukan hal-hal yang tidak akan pernah dapat dilakukan secara sendiri-sendiri. Schwarm-computing memanfaatkan fenomena alam tersebut.Para peneliti di Siemens senang mencari inspirasi dari semut-semut. Visi terberani mereka ber-setting tahun 2020. Mesin-mesin bergerak berukuran kecil yang tampak seperti semut besar, bekerja di gedung-gedung pencakar langit New York. Mesin-mesin ini mengambil informasi dari lingkungan, berkomunikasi unikasi satu sama lain, dan secara bersama-sama melaksanakan tugas yang diberikan kepada mereka. Sistem jaringan yang terbentuk sendiri (ANTS, Autonomous Networked System) menurut para pakar suatu hari nanti akan dapat melaksanakan pekerjaan pemeriksaan dan perawatan pada lokasi-lokasi yang sulit dijangkau atau berbahaya serta tugas-tugas pengawasan bergerak.Karena mereka saling bertukar informasi, masing-masing hewan ini tidak perlu terlalu pintar. Inti kecerdasannya ada dalam sistem. Untuk orientasi, mereka dilengkapi dengan GPS, kamera, dan sistem pengenalan gambar. Setiap anggota sistem melihat sebuah objek dari berbagai sudut pandang dan saling membantu dalam menginterpretasi gambar kamera. Untuk menemukan solusi efisien bagi masalah sehari-hari, para pengembang semakin sering berorientasi pada model sukses dari komunitas alam yang memiliki kecerdasan kolektif seperti ikan, burung, atau serangga. Sebagai sebuah sistem, hewan-hewan itu mampu bersama-sama menyelesaikan sebuah tugas yang rumit. Perilaku ini juga merupakan tema best seller fiksi ilmiah di Jerman karangan Frank Schaetzing yang berjudul ‘Der Schwarm’.Beberapa aturan telah cukup bagi sebuah komunitas. Sebagai contoh, terbangnya segerombolan burung dapat dirumuskan dengan 3 aturan. Menyingkir sebelum terjadi tabrakan, terbang secepat burung-burung di sekitar kita, dan terbang ke arah pusat gerombolan. Dalam simulasi komputer, aturan-aturan sederhana tersebut sudah cukup untuk meniru perilaku kelompok secara realistik. Studio-studio animasi Hollywood menggunakannya untuk menampilkan gerak laju gerombolan hewan yang tampak seperti asli. Rumus meniru perilaku hewan.Rute semut sebagai contoh semut menemukan rute terpendek berkat penandaan feromon oleh rekannya. Bila jaraknya sama panjang, dipilih rute yang pertama ditemukan. Ahli IT telah memanfaatkan taktik ini untuk berbagai aplikasi.Percobaan yang dipandang sangat berhasil adalah dalam pembuatan algoritma semut. Cara semut melacak jarak terpendek antara sarang dan sumber makanan melalui bebauan tertentu (feromon) digunakan sebagai contoh solusi masalah logistik dan optimalisasi, misalnya routing dalam jaringan telekomunikasi. Semut software meniru perilaku semut asli, yaitu dengan menetapkan variabel solusi yang dicari secara bertahap seperti dalam mencari rute. Kriteria pemilihannya adalah kualitas nila inilai potensial untuk variabel dalam pemilihan sebelumnya—sama seperti nilai feromon pada semut.Tugas utama software adalah merumuskan ‘kesadaran konteks’. Dari data yang tersedia, software harus menemukan dalam msituasi apa seorang manusia atau objek berada dan bagaimana sebuah lingkungan cerdas dapat bereaksi.Siemens sudah menerapkan teknik semacam itu pada bagian home-networking dan teknik konstruksi. Suatu arsitektur software bersama merupakan bingkai untuk solusi berbagai tugas.Mengatasi tumpahan minyak dengan robot.Bila penggunaan semut-semut mekanik pada gedung-gedungn tinggi masih jauh di masa depan, sebuah proyek untuk komunitas robot dilaut sudah terwujud. Para ilmuwan Institut Fraunhofer untuk Teknik Produksi dan Otomatisasi (IPA) ingin mengatasi tumpahan minyak di laut dengan robot. Di sini, robot-robotnya adalah perahu-perahu kecil dengan perangkat penyedot.Suatu komunitas dengan kecerdasan terbagi sangat tepat untuk penanganan minyak yang tidak dapat diatur secara sentral karena perilaku ‘karpet minyak’ tidak dapat diprediksi dengan tepat. Sekitar 100 robot ditugaskan untuk saling berkomunikasi, menemukan, dan menyedot minyak. Untuk melaksanakan tugas tersebut mereka tidak perlu terlalu pintar. Kecerdasan kolektif paling baik berfungsi bila semua bagian sama bodohnya. Spesialisasi dalam komunitas hanya berefek negatif pada hasil keseluruhan. Selain itu, tidak berfungsinya beberapa robot lebih mudah dikompensasi bila semuanya sama. Karena itu pula, pola gerakan setiap robot juga sederhana. Selama sebuah sensor memberitahu robot bahwa ia berada dalam karpet minyak, ia akan melaju lurus. Di air tanpa minyak ia akan membuat gerakan spiral hingga menemukan minyak. “Banyak membantu banyak” menjadi motto di sini. Semakin banyak robot yang ditugaskan, semakin baik minyak disingkirkan.Saat ini, penggunaan robot tersebut baru berfungsi dalam sebuah simulasi dengan robot-robot kecil. Karpet minyak yang bergerak diproyeksikan pada lantai oleh sebuah beamer. Dalam rangka proyek Uni-Eropa akan diputuskan apakah rencana inidapat direalisasikan atau tidak. Bila diterima, sekitar 5 tahun mendatang armada robot pertama akan mulai beroperasi.Dunia masa depan terbentuk di lab.Agar sebuah sistem teknis bergerak sebagai sebuah komunitas, setiap komponennya tidak perlu bergerak (mobile). Institut Fraunhofer untuk Pengolahan Data Grafis (IGD) di Darmstadt telah memfungsikan sebuah laboratorium kecerdasan lingkungan (Ambient Intelligence Lab). Di lab ini—yang juga terbuka bagi industri—skenario masa depan dapat diujicoba dalam ruang- ruang yang dirancang secara khusus. Visinya adalah membentuk sebuah dunia di mana kita dikelilingi oleh perangkat-perangkat cerdas yang terkoneksi dalam jaringan dan dapat dioperasikan secara intuitif seperti sebuah komunitas. Perangkat-perangkat itu saling berkomunikasi melalui sensor dan mengenali kebutuhan kita. Gambaran bentuk nyatanya ditunjukkan oleh sebuah ‘karpet cerdas’ di lab IGD. Dalam sebuah ruang yang terkoneksi jaringan, melalui sensor di lantai karpet dapat mengenali berapa orang yang ikut dalam meeting dan di bagian ruang mana mereka berada.Bila seorang peserta bergerak menuju podium, PDA-nya mengirimkan kondisi presentasi seperti kecerahan cahaya, setting perangkat suara atau beamer ke perangkat di ruang tersebut. Ponsel secara otomatis dimatikan begitu ceramah dimulai. Jaringan dan kecerdasan kolektif semacam ini tidak hanya dibutuhkan dalam ruang meeting.Tanggul dan kincir ikut berpikir.Di pantai ’Laut Timur’ (Ostsee) Jerman, para ilmuwan ingin menggunakan Schwarm-computing untuk melakukan proteksi bencana. Dalam proyek Swarms, Institut Telematika Universitas Luebeck bersama AG Communication System Universitas Kiel mengembangkan sistem sensor yang terkoneksi melalui jaringan nirkabel untuk melindungi tanggul dan pantai. Setiap beberapa meter, salah satu karung pasir dari jajaran karung pasir yang ada dilengkapi dengan modul-modul yang memiliki komputer kecil, GPS, berbagai sensor, dan interface nirkabel. Bila sensor menangkap kebocoran, info ini langsung diteruskan. Bila sensor di tanggul pasir membunyikan alarm dan memanggil bantuan ketika ada bahaya, jaringan lainnya langsung terkoneksi ke sebuah kendali.Offshore Windpark (kincir angin lepas pantai) bisa memberikan lebih banyak energi dan tidak begitu rentan gangguan ketika saling berkomunikasi. Pada instalasi besar seperti di pantai Denmark, lusinan rotor tersusun dalam beberapa baris. Siemens telah mengembangkan sebuah konsep untuk menghubungkan kincir ini satu sama lain sehingga dapat saling mengawasi. Kincir pada barisan depan meneruskan data angin aktual ke kincir di barisan belakang. Dengan demikian, mereka dapat bersiapn secara optimal menyambut angin yang datang atau mengubah arah bilah rotor bila ada angin kencang yang berbahaya.Jaringan pengawas terkoneksi sendiri.ChannelviewSemua info mengenai pengawasan lalu-lintas dikirim ke pusat kendali. Bila ada bahaya, kamera kamera cerdas bersama sistem lainnya mengaktifkan langkah-langkah pengamanan yang tepat di terowongan Giswil.Untuk suplai energi masa depan, jaringan seperti komunitas tersebut bahkan dapat memainkan peran yang lebih penting. Jaringan listrik Uni-Eropa direncanakan akan disuplai lebih banyak dari sumber energi seperti air, angin, dan matahari. Jaringan raksasa ini menurut para pakar tidak bisa diatur dari satu tempat. Harus dipikirkan bagaimana listrik dapat mengontrol dirinya sendiri. Visinya adalah membagi kecerdasan dalam jaringan listrik untuk menangkap fluktuasi langsung pada titik simpul, bukan pada sebuah sentral yang kelebihan beban. Dengan cara ini, blackout besar-besaran dapat dihindari. Masih dibutuhkan beberapa penelitian lanjutan hingga keinginan ini dapat diwujudkan.Kecerdasan terbagi sudah digunakan dalam pengawasan lalu lintas. Proyek perintis di area padat menggunakan sistem manajemen sentral dengan perangkat akhir seperti sistem navigasi plus ponsel. Untuk itu, ribuan sensor digunakan untuk mengumpulkan data. Tersembunyi dalam pelapis jalan, jembatan atau tiang, sensor-sensor ini mencatat data kepadatan lalu-lintas, arah, dan kecepatan kendaraan. Pada area kritis seperti terowongan, analisis dilakukan secara otomatis langsung di lokasi. Terowongan Giswil diSwiss misalnya, telah dilengkapi dengan pengawasan video cerdas. Instalasi ini dapat mendeteksi adanya kebakaran berdasarkan timbulnya asap, juga dapat mengenali adanya kemacetan.Dalam sebuah gedung, sensor seperti dalam terowongan tadi dapat digunakan untuk memberitahu pemadam kebakaran rute terbaik ke sumber kebakaran. Dalam jaringan pengawas yang terbentuk sendiri secara adhoc, komponen yang tidak berfungsi dapat langsung digantikan oleh unit lain di sekitarnya. Perawatan sehari-hari idealnya juga dilakukan dengan Schwarm-computing. Sensor-sensor mengatur diri sendiri untuk mengambil alih tugas yang boros energi secara bergiliran.Container mencari jalan sendiri.Benda-benda yang ‘berpikir’ seperti container juga dapat mengatur diri sendiri dan bertindak secara mandiri. Dengan sedikit kecerdasan (chip kecil onboard), secara kolektif mereka akan menemukan rute transportasi yang optimal. Pembagian kerja juga berfungsi seperti dalam dunia semut. Container X kepada robot transportasi Y: “Tuntun saya ke jalur administrasi pelabuhan!”
KECERDASAN KOLEKTIF
Komunitas hewan mampu melakukan hal-hal yang tidak akan pernah dapat dilakukan secara sendiri-sendiri. Schwarm-computing memanfaatkan fenomena alam tersebut.Para peneliti di Siemens senang mencari inspirasi dari semut-semut. Visi terberani mereka ber-setting tahun 2020. Mesin-mesin bergerak berukuran kecil yang tampak seperti semut besar, bekerja di gedung-gedung pencakar langit New York. Mesin-mesin ini mengambil informasi dari lingkungan, berkomunikasi unikasi satu sama lain, dan secara bersama-sama melaksanakan tugas yang diberikan kepada mereka. Sistem jaringan yang terbentuk sendiri (ANTS, Autonomous Networked System) menurut para pakar suatu hari nanti akan dapat melaksanakan pekerjaan pemeriksaan dan perawatan pada lokasi-lokasi yang sulit dijangkau atau berbahaya serta tugas-tugas pengawasan bergerak.Karena mereka saling bertukar informasi, masing-masing hewan ini tidak perlu terlalu pintar. Inti kecerdasannya ada dalam sistem. Untuk orientasi, mereka dilengkapi dengan GPS, kamera, dan sistem pengenalan gambar. Setiap anggota sistem melihat sebuah objek dari berbagai sudut pandang dan saling membantu dalam menginterpretasi gambar kamera. Untuk menemukan solusi efisien bagi masalah sehari-hari, para pengembang semakin sering berorientasi pada model sukses dari komunitas alam yang memiliki kecerdasan kolektif seperti ikan, burung, atau serangga. Sebagai sebuah sistem, hewan-hewan itu mampu bersama-sama menyelesaikan sebuah tugas yang rumit. Perilaku ini juga merupakan tema best seller fiksi ilmiah di Jerman karangan Frank Schaetzing yang berjudul ‘Der Schwarm’.Beberapa aturan telah cukup bagi sebuah komunitas. Sebagai contoh, terbangnya segerombolan burung dapat dirumuskan dengan 3 aturan. Menyingkir sebelum terjadi tabrakan, terbang secepat burung-burung di sekitar kita, dan terbang ke arah pusat gerombolan. Dalam simulasi komputer, aturan-aturan sederhana tersebut sudah cukup untuk meniru perilaku kelompok secara realistik. Studio-studio animasi Hollywood menggunakannya untuk menampilkan gerak laju gerombolan hewan yang tampak seperti asli. Rumus meniru perilaku hewan.Rute semut sebagai contoh semut menemukan rute terpendek berkat penandaan feromon oleh rekannya. Bila jaraknya sama panjang, dipilih rute yang pertama ditemukan. Ahli IT telah memanfaatkan taktik ini untuk berbagai aplikasi.Percobaan yang dipandang sangat berhasil adalah dalam pembuatan algoritma semut. Cara semut melacak jarak terpendek antara sarang dan sumber makanan melalui bebauan tertentu (feromon) digunakan sebagai contoh solusi masalah logistik dan optimalisasi, misalnya routing dalam jaringan telekomunikasi. Semut software meniru perilaku semut asli, yaitu dengan menetapkan variabel solusi yang dicari secara bertahap seperti dalam mencari rute. Kriteria pemilihannya adalah kualitas nila inilai potensial untuk variabel dalam pemilihan sebelumnya—sama seperti nilai feromon pada semut.Tugas utama software adalah merumuskan ‘kesadaran konteks’. Dari data yang tersedia, software harus menemukan dalam msituasi apa seorang manusia atau objek berada dan bagaimana sebuah lingkungan cerdas dapat bereaksi.Siemens sudah menerapkan teknik semacam itu pada bagian home-networking dan teknik konstruksi. Suatu arsitektur software bersama merupakan bingkai untuk solusi berbagai tugas.Mengatasi tumpahan minyak dengan robot.Bila penggunaan semut-semut mekanik pada gedung-gedungn tinggi masih jauh di masa depan, sebuah proyek untuk komunitas robot dilaut sudah terwujud. Para ilmuwan Institut Fraunhofer untuk Teknik Produksi dan Otomatisasi (IPA) ingin mengatasi tumpahan minyak di laut dengan robot. Di sini, robot-robotnya adalah perahu-perahu kecil dengan perangkat penyedot.Suatu komunitas dengan kecerdasan terbagi sangat tepat untuk penanganan minyak yang tidak dapat diatur secara sentral karena perilaku ‘karpet minyak’ tidak dapat diprediksi dengan tepat. Sekitar 100 robot ditugaskan untuk saling berkomunikasi, menemukan, dan menyedot minyak. Untuk melaksanakan tugas tersebut mereka tidak perlu terlalu pintar. Kecerdasan kolektif paling baik berfungsi bila semua bagian sama bodohnya. Spesialisasi dalam komunitas hanya berefek negatif pada hasil keseluruhan. Selain itu, tidak berfungsinya beberapa robot lebih mudah dikompensasi bila semuanya sama. Karena itu pula, pola gerakan setiap robot juga sederhana. Selama sebuah sensor memberitahu robot bahwa ia berada dalam karpet minyak, ia akan melaju lurus. Di air tanpa minyak ia akan membuat gerakan spiral hingga menemukan minyak. “Banyak membantu banyak” menjadi motto di sini. Semakin banyak robot yang ditugaskan, semakin baik minyak disingkirkan.Saat ini, penggunaan robot tersebut baru berfungsi dalam sebuah simulasi dengan robot-robot kecil. Karpet minyak yang bergerak diproyeksikan pada lantai oleh sebuah beamer. Dalam rangka proyek Uni-Eropa akan diputuskan apakah rencana inidapat direalisasikan atau tidak. Bila diterima, sekitar 5 tahun mendatang armada robot pertama akan mulai beroperasi.Dunia masa depan terbentuk di lab.Agar sebuah sistem teknis bergerak sebagai sebuah komunitas, setiap komponennya tidak perlu bergerak (mobile). Institut Fraunhofer untuk Pengolahan Data Grafis (IGD) di Darmstadt telah memfungsikan sebuah laboratorium kecerdasan lingkungan (Ambient Intelligence Lab). Di lab ini—yang juga terbuka bagi industri—skenario masa depan dapat diujicoba dalam ruang- ruang yang dirancang secara khusus. Visinya adalah membentuk sebuah dunia di mana kita dikelilingi oleh perangkat-perangkat cerdas yang terkoneksi dalam jaringan dan dapat dioperasikan secara intuitif seperti sebuah komunitas. Perangkat-perangkat itu saling berkomunikasi melalui sensor dan mengenali kebutuhan kita. Gambaran bentuk nyatanya ditunjukkan oleh sebuah ‘karpet cerdas’ di lab IGD. Dalam sebuah ruang yang terkoneksi jaringan, melalui sensor di lantai karpet dapat mengenali berapa orang yang ikut dalam meeting dan di bagian ruang mana mereka berada.Bila seorang peserta bergerak menuju podium, PDA-nya mengirimkan kondisi presentasi seperti kecerahan cahaya, setting perangkat suara atau beamer ke perangkat di ruang tersebut. Ponsel secara otomatis dimatikan begitu ceramah dimulai. Jaringan dan kecerdasan kolektif semacam ini tidak hanya dibutuhkan dalam ruang meeting.Tanggul dan kincir ikut berpikir.Di pantai ’Laut Timur’ (Ostsee) Jerman, para ilmuwan ingin menggunakan Schwarm-computing untuk melakukan proteksi bencana. Dalam proyek Swarms, Institut Telematika Universitas Luebeck bersama AG Communication System Universitas Kiel mengembangkan sistem sensor yang terkoneksi melalui jaringan nirkabel untuk melindungi tanggul dan pantai. Setiap beberapa meter, salah satu karung pasir dari jajaran karung pasir yang ada dilengkapi dengan modul-modul yang memiliki komputer kecil, GPS, berbagai sensor, dan interface nirkabel. Bila sensor menangkap kebocoran, info ini langsung diteruskan. Bila sensor di tanggul pasir membunyikan alarm dan memanggil bantuan ketika ada bahaya, jaringan lainnya langsung terkoneksi ke sebuah kendali.Offshore Windpark (kincir angin lepas pantai) bisa memberikan lebih banyak energi dan tidak begitu rentan gangguan ketika saling berkomunikasi. Pada instalasi besar seperti di pantai Denmark, lusinan rotor tersusun dalam beberapa baris. Siemens telah mengembangkan sebuah konsep untuk menghubungkan kincir ini satu sama lain sehingga dapat saling mengawasi. Kincir pada barisan depan meneruskan data angin aktual ke kincir di barisan belakang. Dengan demikian, mereka dapat bersiapn secara optimal menyambut angin yang datang atau mengubah arah bilah rotor bila ada angin kencang yang berbahaya.Jaringan pengawas terkoneksi sendiri.ChannelviewSemua info mengenai pengawasan lalu-lintas dikirim ke pusat kendali. Bila ada bahaya, kamera kamera cerdas bersama sistem lainnya mengaktifkan langkah-langkah pengamanan yang tepat di terowongan Giswil.Untuk suplai energi masa depan, jaringan seperti komunitas tersebut bahkan dapat memainkan peran yang lebih penting. Jaringan listrik Uni-Eropa direncanakan akan disuplai lebih banyak dari sumber energi seperti air, angin, dan matahari. Jaringan raksasa ini menurut para pakar tidak bisa diatur dari satu tempat. Harus dipikirkan bagaimana listrik dapat mengontrol dirinya sendiri. Visinya adalah membagi kecerdasan dalam jaringan listrik untuk menangkap fluktuasi langsung pada titik simpul, bukan pada sebuah sentral yang kelebihan beban. Dengan cara ini, blackout besar-besaran dapat dihindari. Masih dibutuhkan beberapa penelitian lanjutan hingga keinginan ini dapat diwujudkan.Kecerdasan terbagi sudah digunakan dalam pengawasan lalu lintas. Proyek perintis di area padat menggunakan sistem manajemen sentral dengan perangkat akhir seperti sistem navigasi plus ponsel. Untuk itu, ribuan sensor digunakan untuk mengumpulkan data. Tersembunyi dalam pelapis jalan, jembatan atau tiang, sensor-sensor ini mencatat data kepadatan lalu-lintas, arah, dan kecepatan kendaraan. Pada area kritis seperti terowongan, analisis dilakukan secara otomatis langsung di lokasi. Terowongan Giswil diSwiss misalnya, telah dilengkapi dengan pengawasan video cerdas. Instalasi ini dapat mendeteksi adanya kebakaran berdasarkan timbulnya asap, juga dapat mengenali adanya kemacetan.Dalam sebuah gedung, sensor seperti dalam terowongan tadi dapat digunakan untuk memberitahu pemadam kebakaran rute terbaik ke sumber kebakaran. Dalam jaringan pengawas yang terbentuk sendiri secara adhoc, komponen yang tidak berfungsi dapat langsung digantikan oleh unit lain di sekitarnya. Perawatan sehari-hari idealnya juga dilakukan dengan Schwarm-computing. Sensor-sensor mengatur diri sendiri untuk mengambil alih tugas yang boros energi secara bergiliran.Container mencari jalan sendiri.Benda-benda yang ‘berpikir’ seperti container juga dapat mengatur diri sendiri dan bertindak secara mandiri. Dengan sedikit kecerdasan (chip kecil onboard), secara kolektif mereka akan menemukan rute transportasi yang optimal. Pembagian kerja juga berfungsi seperti dalam dunia semut. Container X kepada robot transportasi Y: “Tuntun saya ke jalur administrasi pelabuhan!”
Jumat, 2009 Maret 06
TUGAS RPL 3
TEORI HEXAGONAL
Pemrogram komputer menggunakan lebah madu sebagai rujukan
Pemrogram komputer menggunakan lebah madu sebagai rujukan
Naiknya tingkat kesibukan berbelanja melalui Internet menimbulkan sejumlah permasalahan besar. Perilaku pelanggan ketika berbelanja bisa jadi sama sekali lain dari perkiraan umumnya, dan mungkin saja berbeda di antara sesama pelanggan. Hal ini menyebabkan lalu lintas internet menjadi tidak teratur dan akhirnya berujung pada penumpukan tiba-tiba pada server Internet yang menangani belanja on-line. (Server: sebuah komputer dalam sebuah jaringan yang menyimpan program-program aplikasi dan file-file data yang dapat dikunjungi oleh komputer-komputer lainnya di dalam jaringan tersebut.) Para pakar dari Universitas Oxford dan the Georgia Institute of Technology [Institut Teknologi Georgia] melakukan kerjasama dalam rangka mengembangkan sejumlah teknologi yang dapat mengatasi penumpukan semacam itu. Para peneliti ini mengambil model atau contoh-acuan berupa suatu masyarakat yang lalu lintasnya telah berhasil diatur dengan sangat baik. Contoh-acuan ini adalah perilaku koloni atau masyarakat lebah madu yang tengah ditiru dalam sejumlah teknologi yang ditujukan untuk meringankan beban pada server-server pada saat terjadi kepadatan lalu lintas yang luar biasa.
Lonjakan jumlah pelanggan belanja atau perdagangan saham secara tiba-tiba, naik turunnya kegiatan lelang melalui internet memunculkan kesulitan besar pada perusahaan-perusahaan pengelola server. Untuk meningkatkan keuntungan mereka sebesar-besarnya, perusahaan-perusahaan ini perlu memeriksa komputer-komputer mereka setiap saat untuk menjaga agar komputer tersebut tetap mampu menyesuaikan diri terhadap tingkat kebutuhan yang berubah-ubah melalui campur tangan secara cepat. Namun pada kenyataannya, hanya satu aplikasi web saja yang dapat dimuat ke dalam komputer pada satu waktu, dan hal ini merupakan sebuah kendala. Perpindahan antar-aplikasi menyebabkan penghentian sementara selama 5-7 menit, waktu ini diperlukan untuk konfigurasi ulang pada komputer, dan ini berarti kerugian.
Permasalahan serupa dijumpai dalam tugas-tugas yang dijalankan oleh lebah madu. Sumber-sumber bunga memiliki keragaman dalam hal mutu. Oleh karena itu, seseorang mungkin berpikiran bahwa keputusan tentang berapa banyak lebah yang harus dikirim ke setiap tempat tersebut dan berapa lama mereka sebaiknya berada di sana merupakan sebuah permasalahan dalam sebuah koloni yang ingin mencapai laju pengumpulan madu bunga (nektar) setinggi-tingginya. Akan tetapi, berkat sistem kerja mereka yang sangat baik, lebah mampu memecahkan permasalahan ini tanpa mengalami kesulitan.
Sekitar seperlima dari lebah-lebah di dalam sebuah sarang bertugas sebagai pengumpul-nektar. Tugas mereka adalah berkelana di antara bunga-bunga dan mengumpulkan nektar sebanyak mungkin. Ketika kembali ke sarang, mereka menyerahkan muatan nektar mereka kepada lebah-lebah penyimpan-makanan yang menjaga sarang dan menyimpan bahan makanan. Lebah-lebah ini kemudian menyimpan nektar di dalam petak-petak madu. Seekor lebah pengumpul-nektar juga dibantu oleh rekan-rekannya dalam menentukan seberapa bagus mutu sumber bunganya. Lebah pengumpul-nektar tersebut menunggu dan mengamati seberapa lama waktu yang dibutuhkan untuk bertemu dengan seekor lebah penyimpan-makanan yang siap menerima muatan. Jika waktu tunggu ini berlangsung lama, maka sang lebah pengumpul-nektar memahami hal ini sebagai isyarat bahwa sumber bunganya bukan dari mutu yang terbaik, dan bahwa lebah-lebah yang lain kebanyakan telah melakukan pencarian yang berhasil. Sebaliknya, jika ia disambut oleh sejumlah besar lebah-lebah penyimpan-makanan untuk mengambil muatannya, maka semakin besarlah kemungkinan bahwa muatan nektar tersebut bermutu baik.
Lebah yang mendapatkan informasi ini memutuskan apakah sumber bunganya senilai dengan kerja keras yang akan dilakukan berikutnya. Jika ya, maka ia melakukan tarian-getarnya yang terkenal agar dipahami maksudnya oleh lebah-lebah lain. Lama tarian ini memperlihatkan seberapa besar keuntungan yang mungkin dapat diperoleh dari sumber bunga ini. [penjelasan lebih lanjut tentang tarian lebah, silakan baca: http://www.harunyahya.com/indo/buku/menyingkap003.htm]
Sunil Nakrani dari Universitas Oxford dan Craig Tovey dari the Georgia Institute of Technology menerapkan cara pemecahan masalah oleh lebah madu tersebut pada permasalahan ada pada Internet host. Setiap server mengambil peran sebagai lebah pengumpul-nektar, dan setiap permintaan pelanggan bertindak sebagai sumber bunga. Dengan cara ini, doktor Nakrani dan Tovey mengembangkan sebuah algoritma "lebah madu" untuk server Internet "sarang." (Algoritma: Serangkaian tahapan-tahapan logis untuk memecahkan suatu permasalahan yang dapat diterjemahkan ke dalam sebuah program komputer.)
Sebuah host menjalankan tugas, sebagaimana yang dilakukan lebah dengan tarian-getarnya, dengan membuat sebuah iklan dan mengirimkannya ke sejumlah server lainnya di dalam sarang. Lama masa penayangan iklan ini mencerminkan manfaat dan tingkat keuntungan yang dapat diraup melalui para pelanggan server-server tersebut. Server lain membaca iklan ini dan berperilaku seperti lebah-lebah pekerja yang mengikuti petunjuk yang yang disampaikan melalui tarian-getar tersebut. Setelah mempertimbangkan dan mengkaji iklan ini beserta pengalaman mereka sendiri, mereka memutuskan perlu tidaknya untuk beralih dari para pelanggan yang sedang mereka layani ke para pelanggan yang sedang dilayani oleh server yang mengirim iklan tersebut.
Doktor Nakrani dan Tovey melakukan uji banding antara algoritma lebah madu yang mereka kembangkan dengan apa yang disebut sebagai algoritma "rakus" yang saat ini dipakai oleh kebanyakan penyedia Internet host. Algoritma rakus terlihat ketinggalan zaman. Algoritma rakus membagi waktu menjadi sejumlah penggalan waktu yang tetap dan menempatkan server-server untuk melayani para pelanggan untuk satu penggalan waktu berdasarkan pengaturan yang dianggap paling menguntungkan pada penggalan waktu sebelumnya. Para peneliti mengungkap bahwa di saat-saat ketika lalu lintas sangat berubah-ubah, algoritma lebah madu memperlihatkan kinerja 20% lebih baik daripada algoritma rakus. Sebentar lagi mungkin server-server yang bekerja menggunakan algoritma lebah madu akan semakin banyak di masa mendatang, di mana Internet akan lebih tepat disebut sebagai "Interkoloni."
Dengan pemisalan yang sangat tepat, penelitian yang dilakukan oleh para ilmuwan ini menunjukkan betapa berbagai pemecahan masalah yang masuk akal terdapat di alam. Permasalahan yang dihadapi server-server Internet sangatlah mirip dengan permasalahan yang dipecahkan oleh koloni lebah madu. Sungguh, keberhasilan yang dicapai penelitian tersebut, yang dilakukan dengan menerapkan contoh-rujukan koloni lebah madu, menjadi isyarat akan hal ini. Akan tetapi, dari manakah asal usul rumusan pemecahan masalah yang diberikan lebah madu kepada para pemrogram komputer tersebut? Meskipun para pemrogram komputer dapat mengambil perilaku lebah madu sebagai contoh-rujukan mereka, lebah itu sendiri tidak dapat melakukan hal seperti itu. Ini dikarenakan meskipun tiruan algoritma lebah yang dibuat oleh pemrogram komputer merupakan hasil dari proses berpikir cerdas yang dilakukan secara sadar, lebah madu tidak memiliki kemampuan berpikir semacam itu. Pemecahan atas permasalahan tersebut membutuhkan tindakan sadar, misalnya pertama-tama pemahaman tentang adanya permasalahan tersebut, pengkajian terhadap sejumlah penyebab timbulnya permasalahan itu, pengenalan atas pengaruh sejumlah penyebab itu terhadap permasalahan tersebut secara umum dan pengaruhnya terhadap satu sama lain, dan akhirnya pengambilan keputusan di antara beragam pilihan yang ada.
Sudah pasti pemecahan masalah semacam itu tidak mungkin terjadi di dalam koloni lebah beranggotakan 20 sampai 50 ribu ekor. Hanya ada satu penjelasan masuk akal atas kenyataan ini, di mana sedemikian banyak makhluk hidup menghemat energi dengan menerapkan cara pengumpulan nektar yang paling menguntungkan; meskipun orang biasanya mengira akan melihat suatu kekacauan dan kebingungan di dalamnya. Pemahaman atas permasalahan di dalam koloni lebah dan jalan keluar pemecahannya merupakan hasil karya Pencipta Maha Mengetahui. Tidak ada keraguan, Allahlah, Pencipta langit dan bumi dan segala yang ada di antara keduanya, Yang telah menciptakan koloni lebah. Strategi yang diterapkan di dalam koloni lebah madu merupakan ilham yang berasal dari Allah. Allah menyatakan hal ini di ayat berikut:
Dan Tuhanmu mewahyukan kepada lebah: "Buatlah sarang-sarang di bukit-bukit, di pohon-pohon kayu, dan di tempat-tempat yang dibuat manusia. Kemudian makanlah dari tiap-tiap (macam) buah-buahan dan tempuhlah jalan Tuhanmu yang telah dimudahkan (bagimu)." Dari perut lebah itu keluar minuman (madu) yang bermacam-macam warnanya, di dalamnya terdapat obat yang menyembuhkan bagi manusia. Sesungguhnya pada yang demikian itu benar-benar terdapat tanda (kebesaran Tuhan) bagi orang-orang yang memikirkan. (QS. An Nahl, 16:68-69)TUGAS RPL 2
F - 16 SIMULATOR - SOFTWARE
1 Pendahuluan
Software Simulator F-16 merupakan program komputer yang mensimulasikan gerak pesawat tempur F-16 dan menyajikannya dalam grafik 3 Dimensi (3D) dalam dunia maya (Virtual Reality). Program simulator ini dibuat dengan menggunakan MATLAB/Simulink yang merupakan software matematika dan pemrograman yang sangat handal untuk keperluan keteknikan (engineering) dan sangat banyak digunakan di dunia, baik di lingkungan pendidikan maupun industri. Software MATLAB yang digunakan disini adalah MATLAB 7.0.
Persamaan gerak yang digunakan dalam simulator F-16 ini terdiri atas dua bentuk, yaitu bentuk linear dan nonlinear. Bentuk linear yang digunakan merupakan persamaan gerak lengkap yang disarikan dari Richard Russell [1] berdasarkan model matematika pesawat F-16 yang tersaji dalam buku Stevens dan Lewis [2]. Dalam simulator F-16 ini persamaan gerak yang dipakai adalah model low-fidelity, yaitu model gerak tanpa menggunakan leading-edge flap (LEF). Sedangkan bentuk nonlinear akan digunakan untuk modus pilot (game) yang akan dijelaskan lebih rinci pada bagian selanjutnya.
<--more-->
2 Arsitektur Program
Inti dari Simulator F-16 adalah persamaan gerak lengkap pesawat udara. Persamaan ini merupakan sebuah himpunan persamaan diferensial orde dua yang nonlinear. Untuk mendapatkan parameter terbang dari pesawat, maka persamaan diferensial ini diintegrasikan secara numerik. Selanjutnya hasil dari integrasi ini disajikan dalam grafik tiga dimensi dalam dunia maya (virtual reality). Persamaan gerak lengkap ini dapat disajikan sebagai berikut:
2.1 Persamaan Gerak Lengkap Pesawat Tempur F-16
Persamaan gerak lengkap pesawat udara merupakan gerak dengan enam derajat kebebasan, atau dalam istilah tekniknya disebut six-degree-of-freedom (6DOF) motion [4]. Gerak ini terdiri atas tiga gerak tranlasi, masing-masing pada sumbu x, y dan z, dan tiga gerak rotasi, masing-masing dengan sumbu putar pada sumbu x, y dan z, perhatikan Gambar 2-1.
2.2 Persamaan Nonlinear Tiga Derajat Kebebasan
Persamaan gerak lengkap pesawat udara seperti telah dijelaskan di depan dapat disederhanakan menjadi tiga derajat kebebasan untuk beberapa kasus, misalnya takeoff dan landing. Untuk kasus ini, persamaan gerak dapat disederhanakan sebagai gerak pada bidang longitudinal, yang terdiri atas gerak translasi pada sumbu x dan z, serta satu gerak rotasi pada sumbu y.
2.3 Gaya dan Momen Aerodinamika
2.4 Linearisasi Persamaan Gerak
Persamaan gerak lengkap merupakan persamaan non-linear yang sangat rumit sehingga solusinya hanya dapat dilakukan secara numerik. Untuk menyederhanakan solusi dari persamaan gerak, maka persamaan di atas dilinearisasi pada suatu keadaan tertentu. Berikut ini adalah beberapa keadaan trim yang digunakan untuk menlinearisasi gerak pesawat F-16,
? Terbang jelajah tunak (steady wings-level flight)
? Terbang belok tunak (steady turning flight)
? Terbang tanjak tunak (steady pull-up)
? Terbang roll tunak (steady roll)
2.5 Diagram Blok Program Simulator F-16
Berikut ini adalah gambar diagram blok Simulink dari program F-16 Simulator. Untuk mengetahui secara rinci silahkan baca di Lampiran.
3 Kendali Pesawat F-16
Kendali pesawat tempur F-16 terdiri atas empat input, yaitu gaya dorong (thrust) yang dinyatakan dalam satuan pound, dan tiga input bidang kendali yaitu elevator, aileron dan rudder, masing-masing dinyatakan dalam satuan derajat. Gaya dorong memiliki arah sama dengan sumbu xb. Input gaya dorong didefiniskan positif jika menambah percepatan ke depan. Sedangkan untuk tiga bidang kendali penentuan positif dan negatifnya adalah positif apabila mengurangi laju putaran. Dengan demikian untuk masing-masing bidang kendali, defleksi positif dinyatakan sebagai berikut:
Defleksi elevator positif jika membuka ke bawah sehingga menimbulkan gerak pitch negatif. Defleksi aileron positif jika aileron kanan membuka ke bawah sehingga menimbulkan roll negatif. Defleksi rudder positif jika membuka ke kiri sehingga menimbulkan yaw negatif.
Khusus untuk Leading Edge Flap (LEF), defleksinya didefiniskan positif jika membuka ke bawah. Pada keadaan ini, pengaruh defleksi LEF adalah membuat pesawat dapat terbang pada sudut serang yang lebih tinggi dibanding tanpa LEF untuk kecepatan terbang yang sama. Input kendali untuk F-16 memiliki batasan sebagai berikut:
Kendali Satuan Batasan
Minimum Maximum
Gaya Dorong Lbs 1000 19000
Elevator Deg -25 25
Aileron Deg -21.5 21.5
Rudder Deg -30 30
LEF Deg 0 25
4 Memulai/Menjalankan Program
Untuk memulai menggunakan program simulator F-16 maka hal pertama yang harus dilakukan adalah menjalankan software MATLAB yang merupakan induk dari program ini. Ada dua cara untuk menjalankan MATLAB, yaitu:
1 Melalui dekstop Windows sebagaimana tersaji dalam Gambar 2-3. Caranya yaitu dengan mengklik dua kali (double-click) pada icon MATLAB.
2 Melalui menu start Windows seperti terlihat pada Gambar 2-4, Caranya yaitu menekan tombol start Windows, kemudian mengklik icon MATLAB yang ada terlihat pada menu start.
Jika langkah pertama ini dijalankan, maka akan tampil menu utama software MATLAB sebagaimana terlihat pada Gambar 2-5.
Untuk menjalankan program simulator F-16, ketik f16sim pada program MATLAB sebagaimana terlihat pada Gambar 2-5 di atas, kemudian tekan enter. Tampilan awal dari program f16sim tersaji dalam Gambar 2-6 di bawah. Pada tampilan awal ini terlihat tiga window, yaitu window utama (sebagai kendali untuk simulasi, bagian bawah), window virtual reality (kiri atas) dan window instrument display (kanan atas).
Window utama seperti tampak pada Gambar 2-7 merupakan window pengendali program simulator ini. Disinilah semua perintah untuk menjalankan atau menghentikan simulasi tersedia.
Selanjutnya pilih mode terbang. Pilihan ini akan membuat program membuka model matematika secara otomatis sesuai modus terbang yang dipilih. Penjelasan tentang mode terbang akan diberikan di pasal selanjutnya. Setelah open model dilakukan maka program simulator F-16 akan menyajikan beberapa window yaitu Simulink model (Gambar 2-8), Virtual Reality window (Gambar 2-9), dan Avionic instrument (Gambar 2-10). Simulink model berisi persamaan gerak pesawat F-16 yang digunakan sebagai jantung dari simulasi. Hasil dari simulasi ini selanjutnya akan disajikan dalam Virtual Reality (VR) dan Avionic instrument.
Sebagaimana telah dijelaskan di atas, VR window merupakan visualisasi dari gerak pesawat tempur F-16. Contoh tampilan dari VR ini terlihat dalam Gambar 2-9. Virtual Reality merupakan metode atau alat untuk menyajikan gambaran suatu lingkungan dalam dunia maya yang sangat mirip dengan dunia nyata. Hal ini juga dapat dilihat dalam simulator ini yakni gerak pesawat F-16 dapat dilihat ‘nyata’ seperti aslinya. Pengguna simulator dapat melihat dunia maya yang disajikan seolah-olah berada di dalamnya. Pengguna juga dapat melihat pesawat F-16 dari banyak sisi dan sekaligus melihat dunia maya dimana pesawat ini berada.
Selain VR window, program juga akan menyajikan Aircraft Instrument. Ketika aircraft instrument ini terbuka, maka akan muncul informasi dari pembuat program intrument ini seperti terlihat pada Gambar 2-10. Hal ini terjadi secara otomatis karena merupakan fasilitas dari program MATLAB. Informasi ini tidak penting dan karenanya harus ditutup dengan cara menekan tombol OK.
Saat menjalankan program, instrumen pesawat akan disajikan sebagaimana terlihat pada Gambar 2-11. Dalam instrumen ini akan disajikan
(1) kecepatan (dalam knot), (2) Artifical horizon yang menunjukkan sikap pesawat terhadap horizon, (3) VOR yang menunjukkan arah terbang (heading dalam derajat), (4) roll indicator yang menunjukkan sikap roll pesawat, (5) Tinggi terbang (dalam feet) dan (5) Kecepatan menanjak (dalam feet/min).
5 Penggunaan Program Simulator
Berikut ini akan dijelaskan mengenai cara-cara penggunaan software (program) simulator F-16. Dimulai dari penjelasan tentang modus terbang, selanjutnya penggunaan menu-menu dan terakhir cara mengakhiri atau keluar dari program.
5.1 Modus Terbang
Sebelum menjalankan simulasi, maka perlu diperhatikan jenis-jenis terbang yang ingin ditampilkan. Seperti terlihat dalam Gambar 2-12, terdapat 3 modus utama yaitu:
1 Normal Flight
2 Aerobatic
3 Pilot (Game Mode)
1. Normal Flight
Ini adalah modus terbang normal (biasa) yang meliputi takeoff (tinggal landas), climb (menanjak), cruise (jelajah), turn (belok) dan landing (pendaratan). Dalam simulasi pada modus ini semua gerak akan dilakukan otomatis tanpa input dari luar (pengguna). Semua modus terbang dijalankan secara secara pre-programmed, yaitu telah ditentukan semua input kendali oleh program lebih dahulu mengikuti kaidah-kaidah ilmiah. Modus normal flight ini hanya digunakan sebagai demonstrator manuver-manuver terbang normal.
2. Aerobatic
Ini adalah modus terbang khusus yang membutuhkan keahlian tinggi dalam menjalankannya. Gerak atau manuver terbang ini seringkali disebut akrobatik udara atau lebih dikenal sebagai aerobatic. Seperti terlihat pada program utama, modus aerobatic ini meliputi: Cloverloop Opener, Inverted-Right, Inverted-Left, Diamond roll, dan Vertical bomb burst. Modus terbang erobatic juga hanya digunakan sebagai demonstrator (tanpa ada input dari luar atau pengguna). Manuver-manuver dalam modus ini dilakukan secara automatic menggunakan kaidah kendali terbang dan/atau pre-programmed seperti pada modus terbang normal.
3. Pilot (Game Mode)
Modus ini merupakan modus terbang lengkap yang dikendalikan dari oleh pengguna. Disini pengguna akan bertindak sebagai pilot pengendali pesawat F-16, jadi pada modus ini pengguna seolah-olah menggunkan software game simulator. Itu sebabnya modus ini disebut modus Pilot (Game Mode). Sebelum menjalankan simulasi untuk modus ini, harus dipastikan bahwa joystick telah terpasang dengan benar, jika tidak maka program tidak akan jalan.
Pada modus ini tersedia tiga pilihan, yaitu Takeoff-3DOF, Landing-3DOF, dan Full Envelope. Modus takeoff (tinggal landas) dan landing (pendaratan) dibuat berdasarkan persamaan gerak nonlinear dengan tiga derajat kebebasan, atau dalam istilah teknik disebut three-degree-of-freedom (3DOF) motion. Sesuai namanya, gerak ini hanya terdiri dari tiga derajat kebebasan, yaitu gerak translasi pada sumbu x dan z, serta satu gerak rotasi pada sumbu y. Input yang dapat diberikan pada modus ini adalah defleksi elevator dan setting gaya dorong. Modus ketiga adalah full envelope. Disebut full envelope karena modus terbang ini meliputi semua manuver pesawat terbang, yaitu takeoff, climb, cruise, turn, descend, dan landing. Modus ini dibuat berdasarkan persamaan gerak lengkap nonlinear yang secara fisik benar-benar mewakili gerak nyata dari pesawat. Persamaan gerak lengkap ini merupakan gerak dengan enam derajat kebebasan, atau dalam istilah teknik disebut six-degree-of-freedom (6DOF) motion.
5.2 Menjalankan dan menghentikan program
Setelah modus terbang dipilih, maka untuk menjalankan simulasi cukup dengan menekan tombol Start. Dan untuk menghentikan cukup dengan menekan tombol Stop. Jika ingin menghentikan sejenak simulasi ini, maka tekan tombol Pause dan bila ingin melanjutkan kembali tekan tombol yang sama (Contd). Perhatikan kembali tampilan utama program seperti terlihat dalam Gambar 2-13. Lama simulasi juga dapat ditentukan oleh pengguna yaitu dengan memasukkan angka Tstop yang defaultnya bernilai 10 (detik).
5.3 Fasilitias tambahan
Fasilitas tambahan yang tersedia dalam program ini ada dua, yaitu plot trajectory dan zoom factor. Plot trajectory yang dimaksud disini adalah kemampuan program untuk melukiskan lintasan terbang dari pesawat F-16 setelah simulasi dilakukan. Grafik yang dihasilkan adalah lintasan dalam ruang (3 Dimensi) dalam tata acuan koordinat horizon lokal, yaitu posisi dalam arah utara, timur dan tinggi terbang. Untuk menggunakan fasilitas ini cukup dengan menekan tombol Plot Trajectory.
Zoom factor yang dimaksud disini adalah faktor pengali yang digunakan untuk memperbesar tampilan defleksi bidang kendali, yaitu elevator, aileron dan rudder. Hal ini diperlukan apabila defleksi bidang kendali terlalu kecil sehingga tidak tampak pada tampilan simulasi.
5.4 Mengakhiri (Keluar) Program
Untuk mengakhiri program simulator F-16, dapat dilakukan beberapa cara yaitu dengan menekan tombol Exit, atau masuk kedalam menu File kemudian dipilih submenu Exit (Gambar 2-14), atau dengan menekan tombol silang merah di ujung kanan atas program utama, dan atau menekan tombol Exit yang ada di kanan bawah tampilan utama program.
Setelah menekan menu Exit atau tombol silang warna merah di sisi kanan atas, maka akan muncul kotak dialog seperti tampak pada Gambar 2-15. Jika pengguna benar akan keluar maka tekan tombol Yes, dan apabila membatalkan keinginan untuk keluar maka tekan tombol No.
6 Perawatan
Program software simulator F-16 ini merupakan program yang open, yaitu dapat diubah dengan mudah. Namun pengubahan program ini dilarang agar tidak terjadi kesalahan program yang mengakibatkan program tidak bisa berjalan sebagaimana mestinya. Pengubahan program hanya diijinkan dalam pengawasan pihak pembuat program. Selama masa satu tahun sejak perangkat simulator F-16 ini diserahkan kepada pengguna, pihak pembuat program akan melakukan perawatan program, dalam arti apabila kelak ditemukan kesalahan program, maka pembuat program akan melakukan perbaikan tanpa biaya atau mengganti program ini dengan program yang baru yang lebih baik apabila diperlukan.
Kamis, 2009 Maret 05
TUGAS RPL
TUGAS 1 RPL
MENGAPA GOOGLE BISA MENJADI BISNIS YANG BESAR????
Google berdiri pada tahun 1998. website ini didirikan oleh dua orang bersahabat dari
Google merupakan search engine yang paling banyak digunakan orang di seluruh dunia, yakni sekitar 29,5% pengguna. Google merupakan search engine yang mempunyai kemampuan untuk melakukan pencarian super cepat. Hal ini disebabkan google menggunakan hardware dan dukungan software yang canggih. Google mempunyai algoritma pencarian yang sangat efisien, yang digunakan dalam sebuah jaringan search engine. Jaringan computer dan algoritma search engine tersebut berhasil membangun sebuah search engine yang super cepat. Search engine google mampu mempunyai sebuah system yang berkerja untuk mengurutkan halaman web yang disebut pagerank. System tersebut dikembangkan oleh pendiri google yaitu Larry Page and Sergei Brin di Universitas. Google mempunyai system yang dapat mengatur hasil pencarian dari sekian banyak informasi yang ditemukan di internet.
Google memungkinkan kita mencari lebih dari 1 juta aamat URL di internet. Google menyimpan banyak halaman web di chace (halaman tersimpan) yang dimilikinya. Apabila kita gagal menghubungi server halaman web yang bersangkutan secara temporary kita dapat menampilkan halaman web yang terdapat di chace google. Namun, kelemahannya informasi di halaman web yang disimpan di chace google sering kali tidak up to date. Selain dukungan fasilitas – fasilitas tersebut google juga di lengkapi dengan layanan pencarian dalam berbagai bahasa, termasuk bahasa
Kelebihan google berupa penyajian hasil pencarian brdasarkan pemeringkatan jumlah pengakses sebuah situs. Cara kerja google di ilhami dari cara pengutipan dari suatu karya ilmiah oleh para penulis makalah lain. Semakin sering situs di akses maka semakin penting situ situ di anggap. Kesuksesan goggle di anggap nilai pasarnya kini lebih dari 80 miliyar dollar AS, dengan pengakses lebih dari ratusa juta orang pengakses,
Dengan masuk ke bisnis advertaising, diversifikasikan layanan google juga bertanbah. Tapi jika google dapat menyediakan layanan yang lebih mudah untuk di akses dapat diprediksi mereka akan memimpin bisnis ini. Akusisi jawara search engine google terhadap perusahaan selama ini, double click menyediakan layanan yang memungkikan para web publisher, pemasang iklan on – line, dan agen periklanan untuk mempromosikan bisnis mereka lewat iklan digital. Ada dua divisi utama dalam perusahaan tersebut. Divisi dart menyediakan tool dan berbagai layanan untuk penjualan dan pembelian iklan. Sedangkan divisi performing bertanggung jawab terhadap pemasaran search engine berdasarkan iklan yang dibayar per – klik, hal ini yang selama ini jadi andalan google.
Bisnis baru google tandem dengan double click berpotensi untuk mnggeser posisi Yahoo yang tercatat sebagai pemain bisnis advertising. Setelah melalui beberapa tahap tawar menawar, dan berasing dengan mereka, google berhasil memenangkan hati double click dengan penawaran senilai 3,1 miliyar dollar AS. google merupakan search engine dengan da base terbesar. Dan hal ini lah yang menyebabkan mengapa google bias menjadi bisnis yang besar…
Langgan: Entri (Atom)
Langganan:
Postingan (Atom)