BAB I

PENDAHULUAN PENDAHULUAN

1.1 Perangkat Lunak Komputer 1.1.1 Definisi ressman (2001) mendefinisikan perangkat lunak adalah sebagai berikut: 1) kumpulan perintah apabila dijalankan akan menampilkan capaian dan fungsi yang sesuai dengan yang diinginkan, 2) struktur data yang membolehkan program untuk memanipulasinya dan 3) dokumen yang menerangkan cara menjalankan dan kegunaan program. Pressman (2001) juga menyatakan bahwa ada tiga jenis perangkat lunak, yaitu perangkat lunak sistem, perangkat lunak aplikasi dan Fourth Generation Tools (4GT). Perangkat lunak sistem berguna untuk mengendalikan jalannya perangkat keras komputer, mencakup CPU, peralatan input dan output dan memori. Contoh perangkat lunak sistem itu adalah DOS, OS Windows, Linux, Unix, Novel, IBM VM dll. Perangkat lunak aplikasi adalah program yang mengotomatisasikan satu fungsi bisnis. Sebagai contoh: aplikasi akuntansi (Oracle Application, SAP) yang mengotomatisasikan kegiatan General Ledger, Account Receivable, Account Payable, Cash, Bank, Inventory, dan Payroll. 4GT adalah program bantu untuk meningkatkan produktivitas perancang sistem. Dengan adanya 4GT, orang dengan keahlian teknis pemograman dan database yang terbatas dapat membangun perangkat lunak aplikasi dengan mudah. Contoh dari 4GT itu adalah PowerBuilder, Access dll. 1.1.2 Rekayasa Perangkat Lunak Menurut Pressman (2001), rekayasa perangkat lunak adalah aplikasi yang sistematis, disiplin dan pendekatan yang terukur untuk
1

Bab 1- Pendahuluan

pengembangan, penjalanan dan perawatan perangkat lunak yang dibagi atas tiga fase, yaitu: 1. Fase pendefinisian. Fokus on what: Informasi apa yang harus diproses? Fungsi dan capaian apa yang dikehendaki? Perilaku sistem apa yang diharapkan? Antarmuka apa yang akan dibentuk? Batasan perancangan apa yang ada? Kriteria validasi apa yang diperlukan untuk mendefinisikan kesuksesan satu sistem? 2. Fase pengembangan. Fokus on how: Bagaimana data distrukturkan? Bagaimana mengimplementasikan satu fungsi didalam satu arsitektur perangkat lunak? Bagaimana mengimplementasikan satu prosedur yang lengkap? Bagaimana mengkarakteristikkan antarmuka? Bagaimana mentranslasikan perancangan ke dalam satu bahasa pemograman dan bagaimana satu pengujian dilakukan? 3. Fase dukungan. Fokus on change: koreksi, adaptasi, peningkatan dan pencegahan. Build and Fix, Waterfall, RAD, Prototyping, Incremental, The Spiral, WinWin Spiral dan Syncronize and Stabilize model adalah beberapa model pengembangan perangkat lunak. Silahkan pelajari model-model tersebut ! Tentukan perbedaan dan kapan model-model itu sebaiknya digunakan ? Untuk kepentingan buku ajar ini, pengembangan perangkat lunak itu dibagi atas: 1) Analisis keperluan sistem, 2) Perancangan sistem, 3) Implementasi sistem (pemograman komputer, dokumentasi dan pengujian sistem). Sub-bab berikut akan menjelaskan fase-fase pengembangan perangkat lunak yang perlu dipahami oleh para mahasiswa. 1.1.2.1 Analisis Keperluan Sistem Menurut Pressman (2001), analisis keperluan sistem merupakan satu proses penemuan, perbaikan, pemodelan dan penspesifikasian. Analisis itu fokus pada domain informasi/data, fungsi dan perilaku dari suatu persoalan. Persoalan yang ada harus diidentifikasi. Evaluasi terhadap persoalan dilakukan dan sintesa (satu atau lebih solusi) diberikan. Selama evaluasi dan sintesa, model dari sistem dibuat. Model itu mencakup data dan aliran kontrol, fungsi pemrosesan dan perilaku operasional dan isi informasi. Model digunakan sebagai dasar 2

Bab 1- Pendahuluan

pembuatan spesifikasi perangkat lunak. Selanjutnya spesifikasi dibuat dan dikaji ulang untuk menjamin pengembang dan pelanggan mempunyai persepsi yang sama tentang sistem. Selanjutnya Pressman (2001) menjelaskan bahwa pada fase analisis ini ditentukan a) capaian dan fungsi dari perangkat lunak, b) ditandai penghubung perangkat lunak dengan elemen sistem lainnya dan c) ditetapkan batasan yang harus dipenuhi oleh perangkat lunak. Luaran utama dari fase ini adalah model analisis dan pernyataanpernyataan keperluan yang merupakan ekspresi keperluan dalam pandangan pemakai. Model analisis adalah informasi yang diperlukan dalam membuat model perancangan. Data Dictionary dan EntityRelationship Diagram dijadikan struktur data dalam perancangan data. Data Flow Diagram menjadi dasar pendefinisian hubungan diantara elemen-elemen struktur utama program dalam perancangan arsitektur. Data Flow Diagram juga menyediakan informasi untuk perancangan antarmuka. Perancangan prosedur mengubah elemen-elemen struktur dari arsitektur program ke dalam deskripsi prosedur komponenkomponen perangkat lunak. Untuk mengumpulkan keperluan-keperluan sistem dari pelanggan dapat dilakukan dengan berbagai cara, seperti interview, survey, observation, temporary assignment, business plans, review internal/external documents, dan review software. Untuk perangkat lunak yang dipakai secara umum, banyak digunakan di pasar, pengumpulan keperluan sistem dapat dilakukan dengan menggunakan studi pasar. 1.1.2.2 Perancangan Sistem Menurut Pressman (2010), perancangan adalah langkah pertama dalam fase pengembangan rekayasa produk atau sistem. Perancangan itu adalah proses penerapan berbagai teknik dan prinsip yang bertujuan untuk mendefinisikan sebuah peralatan, satu proses atau satu sistem secara detail yang membolehkan dilakukan realisasi fisik (Taylor,1959 dlm Pressman, 2001). Fase ini adalah inti teknis dari proses rekayasa perangkat lunak. Pada fase ini elemen-elemen dari model analisis dikonversikan. Dengan menggunakan satu dari sejumlah metode perancangan, fase perancangan akan menghasilkan perancangan data, perancangan antarmuka, perancangan arsitektur dan perancangan prosedur. Banyak langkah yang perlu dilakukan dalam perancangan perangkat lunak. Langkah-langkah tersebut menggambarkan struktur 3

Bab 1- Pendahuluan

data, struktur program, karakteristik antarmuka dan detail prosedur yang merupakan sintesa dari keperluan-keperluan informasi (Pressman, 2001). Perancangan data adalah langkah pertama dari empat kegiatan perancangan dalam rekayasa perangkat lunak. Menurut Wasserman (1980 dlm Pressman, 2001), aktivitas utama dalam perancangan data adalah memilih gambaran logik dari struktur data yang dikenali selama fase spesifikasi dan pendefinisian keperluan. Pemilihan ini melibatkan analisis algoritma dari alternatif struktur dalam rangka menentukan perancangan yang paling efisien. Wasserman (1980, dlm Pressman, 2001) mengusulkan beberapa prinsip dalam perancangan data, yaitu: 1. Prinsip-prinsip analisis sistematis yang diterapkan pada fungsi dan perilaku harus juga diterapkan pada data. 2. Seluruh struktur data dan operasi yang harus dilakukan padanya harus dikenali. 3. Kamus data harus diadakan dan digunakan untuk mendefinisikan perancangan data dan program. 4. Keputusan perancangan data level rendah haruslah ditunda sampai akhir proses perancangan. 5. Gambaran dari struktur data mesti hanya dikenali oleh modul yang menggunakan secara langsung isi data di dalam struktur. 6. Pustaka struktur data dan operasinya mesti dikembangkan. 7. Rancangan perangkat lunak dan bahasa pemograman mesti mendukung spesifikasi dan realisasi dari jenis data abstrak. Bagaimana dengan perancangan lainnya ? Menurut Pressman (2001), perancangan arsitektur menyediakan software engineer satu gambaran dari stuktur program atau blueprint dari perangkat lunak yang akan dibuat. Tujuan perancangan ini adalah untuk membangun struktur program secara moduler dan menggambarkan hubungan kendali diantara modul program . Menurut Pressman (2001), perancangan antarmuka fokus pada tiga area, yaitu: 1. Rancangan antarmuka antara modul perangkat lunak, 2. Rancangan antarmuka antara perangkat lunak dengan produser dan pelanggan informasi, dan 3. Rancangan antarmuka antara manusia dan perangkat lunak. Berikut ini adalah beberapa petunjuk dalam perancangan antarmuka untuk pemaparan informasi: 1. Paparkan informasi yang sesuai dengan konteks saat itu. 2. Jangan kuburkan pemakai dengan data, gunakan format presentasi yang membolehkan asimilasi informasi yang cepat . 4

Bab 1- Pendahuluan

3. Gunakan label, singkatan standar yang konsisten dan warna yang dapat diramalkan. 4. Izinkan pemakai untuk menjaga konteks visual. 5. Hasilkan pesan kesalahan yang berarti. 6. Gunakan huruf besar kecil, ident dan grup teks untuk membantu pemahaman. 7. Gunakan window untuk membagi-bagi jenis informasi yang berbeda. 8. Gunakan tampilan analog untuk menyajikan informasi yang mudah diasimilasi dengan bentuk penyajian ini. 9. Pertimbangkan ketersediaan geografi layar monitor dan gunakan dengan efisien (Pressman, 2001). Bagaimana dengan pemasukan/input data? Berikut ini adalah petunjuknya: 1. Kurangi jumlah aksi input yang diperlukan oleh pemakai. 2. Jaga konsistensi antara tampilan informasi dan input data. 3. Bolehkan pemakai melakukan penyesuaian input. 4. Interaksi harus fleksibel tetapi dapat diatur ke mode input yang disukai pemakai. 5. Matikan perintah yang tidak sesuai dengan aksi saat itu dan pemakai mengendalikan aliran interaksi. 6. Sediakan help untuk membantu aksi semua aksi input. 7. Buang input mickey mouse (Pressman, 2001). 1.1.2.3 Implementasi Sistem Fase implementasi sistem terdiri dari tiga kegiatan, yaitu pemograman, dokumentasi, dan pengujian. Pemograman adalah penciptaan perangkat lunak komputer dengan menggunakan bahasa pemograman. Dokumentasi adalah pencatatan hasil-hasil yang didapat dari fase-fase pengembangan perangkat lunak. Pengujian adalah untuk melihat apakah perangkat lunak yang dibuat dengan bahasa pemograman telah sesuai dengan persoalan. 1.1.3 Prinsip Dasar Pengembangan Sistem Berdasarkan pengalaman-pengalaman beberapa puluh tahun, Pressman (2001) memberikan beberapa prinsip operasional dalam menganalisis suatu persoalan. Prinsip-prinsip dalam menganalisis itu adalah: 5

Bab 1- Pendahuluan

1. Domain informasi dari persoalan mesti direpresentasikan dan dan dipahami. 2. Fungsi-fungsi yang harus dikerjakan oleh perangkat lunak mesti didefinisikan. 3. Perilaku perangkat lunak mesti direpresentasikan. 4. Model yang menggambarkan informasi, fungsi dan perilaku mesti dipartisi dalam satu cara yang membongkar secara detail dalam satu lapisan. 5. Proses analisis mesti bergerak dari informasi yang penting menuju implementasi yang rinci. Davis (1995, dlm Pressman, 2001) menyarankan dalam menganalisis hendaknya: 1. Pahami persoalan sebelum memulai menciptakan model analisis. 2. Kembangkan prototipe yang membolehkan pemakai untuk memahami bagaimana interaksi mesin manusia akan terjadi. 3. Catat asal dan alasan bagi setiap keperluan. 4. Gunakan banyak pandang keperluan-keperluan. 5. Buat peringkat terhadap keperluan-keperluan. 6. Buang hal-hal yang membingungkan. Untuk perancangan perangkat lunak, Davis (1995, dlm Prassman, 2001) menyarankan beberapa prinsip perancangan, yaitu: 1. Proses perancangan tidak harus mengalami tunnel vision. 2. Rancangan harus dapat ditelusuri hingga model analisis. 3. Rancangan seharusnya tidak berusaha mengulangi penemuan di masa lampau. 4. Rancangan tidak boleh jauh dari kenyataan. 5. Rancangan harus memperlihatkan keseragaman dan terpadu. 6. Rancangan harus dapat distrukturkan untuk mengakomodir perubahan. 7. Rancangan harus dapat distrukturkan untuk mendegrasikan secara perlahan, bahkan ketika data atau kondisi operasi yang menyimpang ditemui. 8. Perancangan adalah bukan pemograman, pemograman adalah bukan perancangan. 9. Rancangan harus dinilai kualitasnya ketika diciptakan, tidak setelah sesuatu dilakukan. 10. Rancangan harus ditinjau ulang untuk memperkecil kesalahan konseptual (semantik). Michael Cusumano memberikan beberapa tip pengembangan perangkat lunak yang efektif berdasarkan pengalaman risetnya selama 17 tahun (Hogan, 2003). Tip itu dapat dilihat pada tabel 1.1. 6

Bab 1- Pendahuluan

Tabel 1.1 : Tip pengembangan perangkat lunak (Cusumano dlm Hogan, 2003) No Tip : 1. Buat tim yang besar bekerja seperti tim yang kecil Keterangan Pecahkan suatu proyek besar ke dalam beberapa modul dan tempatkan tidak lebih daripada tigadelapan orang pada masingmasing regu Orang ini harus mempunyai visi untuk membawa regu yang lebih kecil bersama-sama sebagai satu unit Sebagai contoh, "builds harus disampaikan kepada pemimpin proyek setiap hari Cusumano merekomendasikan penggunaan kembali komponen tidak lebih daripada 10% - 20% komponen Rencanakan untuk kembangkan aplikasi dua-tiga tahun ke depan melalui suatu strategi banyak rilis Jika kamu cepat-cepat membangun arsitektur perangkat lunakmu, kamu akan mendapatkan spageti Waktu jatuh tempo menjadi realistis Dapatkan jadwalkan pekerjaan mereka dan kemudian awasi ketelitian mereka dalam menemui tujuan. Susun semua hasil data historis untuk membantu ketepatan waktu proyek secara keseluruhan Mutu harus berada pada suatu jalur yang berkesinambungan, tidak hanya pada ujung suatu proyek Tetapi tugaskan seseorang untuk secara teratur memperbaharui matrik pengujian Ini memberi seluruh tim 7

2.

3.

Letakkan pemimpin yang kuat yang bertanggung jawab pada keseluruhan proyek Ambil pendekatan yang kaku untuk aturan regu Sering gunakan kembali komponen perangkat lunak, tapi jangan berlebihan Reaksi terhadap perubahan pasar tanpa mengorbankan rencana masa depan Rencanakan arsitektur perangkat lunak anda secara bertahap Bagi proyek-proyek besar menjadi proyek kecil-kecil Buat Insinyur perangkat lunak dapat dipertanggungjawab kan

4.

5.

6.

7. 8.

9.

Bangun prosedur pengendalian mutu

10. Otomatisasikan proses pengujian kualitas 11. Do a post-mortem

Bab 1- Pendahuluan

pengembangan satu ide yang bagus tentang apa yang benar dan apa yang salah sehingga dimasa depan proyek lebih efektif

1.2

Tumpahan Minyak

Permasalahan tumpahan minyak merupakan hal yang serius bagi negara-negara di sekitar selat Malaka dan Singapura (Indonesia, Malaysia dan Singapura) (Hadi dan Latief, - ; Djalal, 2006; Mauludiyah dan Mukhtasor, 2009; SuaraKarya, 2010; Harsono, 2011). Kedua selat tersebut termasuk salah satu jalur pelayaran internasional yang terpenting dan tersibuk di dunia yang memungkinkan terjadi kecelakaan kapal-kapal niaga dan kapal-kapal tanker. Selat sempit , dangkal dan berbelok-belok ini mempunyai panjang 500 mil dan diperkirakan sekitar 50.000 kapal setiap tahunnya melewati jalur ini. Lebar selat ini sekitar 300 km pada jalur masuk barat laut dan sekitar 12 km pada jalur masuk tenggara antara Singapura dan Kepulauan Riau dengan titik tersempit selebar 1,5 mil laut di Terusan Phillips Selat Singapura (Harsono, 2011). Dengan kondisi seperti itu, resiko tumpahan minyak pada kawasan selat tersebut sangat tinggi. Tabel 1.2 menunjukkan sejarah kejadian tumpahan minyak di kawasan tersebut. Tabel 1.2 : Peristiwa Tumpahan Minyak di Selat Malaka dan Singapura (Hadi dan Latief, -; Mauludiyah dan Mukhtasor, 2009) Tahun 1975 1975 1992 1992 1993 2000 Lokasi Selat Malaka Selat Malaka Selat Malaka Selat Malaka Selat Malaka Selat Malaka Kejadian Kandasnya Tanker Showa Maru dan menumpahkan 1 juta ton minyak mentah Tabrakan kapal tanker Isugawa Maru dengan kapal Silver Palace Karamnya Tanker Maersk Navigator yang memuat minyak mentah Tabrakan kapal Semi-Container Ocean Blessing dan kapal tanker Nagasaki Spirit. Tabrakan antara Tanker MV. Bandar Ayu dengan kapal ikan Tanker MT Natuna Sea kandas di Selat Malaka antara Pulau Batam dengan Pulau Sudong 8

Bab 1- Pendahuluan

2002

Selat Singapura Selat Malaka

2008

Tabrakan Tanker Singapura Agate dan Kapal Petikemas Tian Yu, mencemari pulau Bintan dan 4 kecamatan di Pulau Batam Tanker Aegis Leader kandas dan menumpahkan 550 ton minyak mentah

Republika (2010) dan HaluanKepri (2010) memberitakan bahwa pada 25 Mei 2010 antara pukul 06.00-07.00 waktu Singapura telah terjadi tabrakan antara kapal tanker dan kapal barang di perairan Malaysia lepas pantai Singapura. Lokasi tabrakan berada pada 011547 LU dan 1040237 BT atau 3 mil dari Singapura dan 4,2 mil dari Batam. Tabrakan itu menimbulkan tumpahan minyak. Otoritas pelabuhan Singapura mengatakan kapal yang terlibat adalah kapal tanker Bunga Kelana 3 dan kapal barang MV Waily. Kapal tanker berbendera Malaysia itu membawa 2000 ton minyak mentah bintulu dan kondensat (Republika, 2010; Detik, 2010a), namun diralat menjadi 5000 ton (Tribun Jakarta, 2010). Lapisan minyak berkelana terbawa ombak tergantung kepada arus dan angin laut. Dalam hal ini, Indonesia telah bersiap-siap meresponnya, jika lapisan minyak itu bergerak ke perairan Indonesia. Akibat dari tumpahan minyak kapal tanker Bunga Kelana 3 ini, para nelayan dan peternak ikan Singapura dilanda rasa kuatir (Detik, 2010b). Menurut The Straits Times (2010 dlm Detik, 2010b), para nelayan dan peternak ikan langsung mengambil langkah penyelamatan begitu tahu ada tumpahan minyak. Mereka melindungi jaring-jaring ikan dengan kanvas untuk mencegah masuknya minyak ke keramba mereka. Tindakan mereka ini diperkuat oleh perkiraan Otoritas Pertanian, Pangan dan Kehewanan Singapura (AVA) yang menyatakan ada kemungkinan tumpahan minyak akan mencapai utara Singapura, tempat para nelayan dan peternak ikan tersebut. Selain itu, pihak Singapura telah memasang ribuan meter alat penjerat minyak (boom) untuk menghalangi minyak mentah mencapai pantai. Namun usaha mereka itu gagal karena angin dan kondisi laut (Tribun Jakarta, 2010). 1.2.1 Permasalahan dalam Menangani Tumpahan Minyak Menurut AMSA (1999), jika terjadi tumpahan minyak terutama di lautan, ada dua pertanyaan yang harus dijawab, yaitu: (i) Kearah mana lapisan minyak bergerak? arah tumpahan, kecepatan gerak dan kerakteristik penyebarannya di laut, 9

Bab 1- Pendahuluan

(ii) Bagaimana dampaknya terhadap sumber-sumber di lingkungan laut dan pantai? Tanpa adanya alat bantu, kedua pertanyaan ini tidak dapat dijawab. Risiko kerusakan lingkungan pantai menjadi lebih besar ataupun pantai yang diperkirakan selamat dari tumpahan minyak dapat menjadi rusak. Arah pergerakan tumpahan minyak sesuai dengan arah angin dan arus laut. Selain mengetahui arah pergerakan tumpahan minyak, juga diperlukan respon yang tepat terhadap tumpahan minyak. Dalam merespon tumpahan minyak diperlukan strategi, kerjasama dan peralatan komunikasi. Strategi respon yang tepat akan mengurangi kerusakan pantai. Tanpa strategi yang jelas, kerusakan akan berakibat buruk terhadap kehidupan sosial lingkungan pantai. Untuk membangun Sistem Informasi Respon Terhadap Tumpahan Minyak berbasiskan GIS perlu dilakukan kajian terhadap beberapa perangkat lunak sejenis. Kajian terhadap perangkat lunak sejenis dikenal juga dengan Software review. Berikut ini adalah daftar perangkat yang perlu dikaji untuk mendapatkan keperluan pemakai, yaitu: 1) Oil Spill Information System (OSIS) luaran British Maritime Technology; 2) OILMAP luaran Applied Science Associates Inc. (ASA); 3) GIS Based Oil Spill Response Atlas (OSRA) luaran AMSA Australia; 4) Marine Spill Analysis System (MSAS) luaran NOAA; 5) The General NOAA Oil Modelling Environment (GNOME) luaran NOAA; 6) Environmental Information System luaran Texas A&M University; 7) GIS Oil Spill Prediction Model luaran McMaster University. 1.2.2 Tantangan Kajian di dalam GIScience Menurut Mark (2000), ada empat tantangan kajian di dalam GIScience. Tantangan-tantangan kajian itu meliputi: (i) Representation, (ii) Uncertainty, (iii) Cognition dan (iv) Simulation. Tantangan simulasi adalah untuk membuat simulasi fenomena geografi di dalam komputer dijital yang tidak membedakannya dari keadaan nyatanya (Mark, 2000). Selain Mark (2000), Radke et. al. (2000) juga menyatakan adanya tantangan di dalam Geographical Information System (GIS). Tantangan itu berupa perubahan dari GIS yang statik ke GIS yang dinamik. Jika dikaitkan dengan keadaan 10

Bab 1- Pendahuluan

darurat, tantangan simulasi juga mencakupi penyajian yang dinamis dari proses manusia dan fisik di dalam respon keadaan darurat (Radke et. al.,2000). Radke et. al. (2000) menyatakan bahwa GIS secara tradisional tidak dirancang untuk menyajikan fenomena yang dinamis, tetapi ini adalah hal yang krisis dalam penilaian dan respon keadaan darurat. Sangat sedikit penelitian yang sudah dikerjakan dalam area ini. Dengan demikian tantangan simulasi perlu diperhatikan. Seterusnya menurut Radke et. al. (2000), ..., kita harus membangun model operasional dan peramalan yang ditempelkan didalam suatu GIS. 1.2.3 Model Tumpahan Minyak Proses-proses dalam tumpahan minyak (advection dan spreading) telah banyak diubah ke dalam bentuk model matematik. Telah puluhan model tumpahan minyak dibangun, namun begitu hanya beberapa saja yang masih digunakan. Ini terjadi karena adanya perubahan pemahaman terhadap proses setelah minyak tertumpah, perangkat keras dan lunak serta kurang dukungan dari pembuat perangkat lunak. Model-model itu ada dalam bentuk sederhana dan ada pula dalam bentuk yang kompleks. Pengembangan model lintasan tumpahan minyak adalah langkah pertama dalam pengembangan program manajemen keadaan darurat tumpahan minyak (Low et. al., 1994). 1.2.4 Model Lintasan Tumpahan Minyak Model lintasan tumpahan minyak (MLTM) adalah satu model yang meramalkan kemana dan seberapa cepat lapisan minyak bergerak jika terjadi tumpahan minyak. Proses Advection merupakan mekanisme utama untuk menentukan lokasi lintasan lapisan minyak. Para peneliti sepakat menyatakan bahwa arus permukaan dan angin adalah penyebab utama dari advection. Menurut Low et. al. (1994), MLTM itu menjadi komponen yang penting dalam menyusun sistem Oil Spill Response. MLTM ini dimanfaatkan untuk meramalkan tempat-tempat yang mungkin terkena tumpahan, baik sewaktu terjadi tumpahan maupun untuk skenario kejadian tumpahan minyak. Ini menunjukkan bahwa tempat itu merupakan hal yang utama untuk diperhatikan, kemana lapisan minyak akan bergerak ? 11

Bab 1- Pendahuluan

1.2.5 Model Matematika Lintasan Tumpahan Minyak Kebanyakan model tumpahan minyak menggunakan teknik a simplified linear superposition untuk mendekati pergerakan lapisan minyak. Dengan cara ini, laju pengangkutan satu lapisan minyak dinyatakan dengan menggunakan penjumlahan vektor pengangkutan yang disebabkan oleh angin dan arus permukaan laut. Untuk kawasan yang dipengaruhi oleh arus pasang, arus permukaan laut diganti dengan arus pasang. Low et. al. (1994) memberikan bentuk umum model matematika vektor pergerakan lapisan minyak sebagai berikut: = Vw + Vc (1) dimana = vektor pergerakan lapisan minyak Vw,Vc = vektor kecepatan angin dan arus permukaan , = fungsi yang berhubungan dengan parameter angin dan arus. Sedangkan Fay (1971 dlm Chigbu dan Bassey, 2010) memberikan rumus luas tumpahan minyak adalah sebagai berikut: A=2.27[( w - o) / o]2/3 V2/3 t-1/2 + 0.04[( w - o)/o]1/3 V1/3 W4/3 t (2) dimana A = luas kawasan tumpahan minyak. W = kecepatan angin dan arus. o,w = kerapatan untuk minyak dan air. t = waktu. V = volume minyak yang tertumpah. 1.3 Penutup

Bentuk praktis dari apa yang disebut dengan pengembangan perangkat lunak itu seperti apa? Bab-bab berikut akan menunjukkan bentuk praktis dari tahapan analisis, perancangan, implementasi (pemograman dan pengujian) perangkat lunak perespon tumpahan minyak. Bentuk praktis tersebut merupakan hasil dari penelitian penulis di Universiti Teknologi Malaysia yang berjudul Pembangunan Sistem Maklumat Respons Tumpahan Minyak (OSRIS) Berasaskan GIS.

12