INTEGRITAS SISTEM : 1. Fault tolerance 2. Teknik analisa requirement 3. Verifikasi dan validasi 4. Compile-time environment 5.

Run-time environment
6. Concurrent version control sistem (CVS)

Fault Tolerance Fault tolerance sistem adalah suatu sistem yang dapat melanjutkan tugasnya dengan benar meskipun terjadi kegagalan perangkat keras (hardware failure) dan kesalahan perangkat lunak (software error). Fault tolerance perlengkapan yang memungkinkan sistem untuk mencapai operasi fault-tolerant. Istilah fault-tolerant komputing menggambarkan proses pelaksanaan perhitungan seperti yang dilakukan komputer, dalam cara fault-tolerant. Konsep fault tolerance menjadi semakin penting dalam dekade belakangan ini karena bertambahnya penggunaan komputer dalam aspek vital kehidupan hampir semua orang. Komputer tidak lagi terbatas digunakan sebagai kalkulator serbaguna dimana kesalahan yang dihasilkannya dapat mengakibatkan lebih dari sekedar frustasi atau kerugian waktu. Bahkan, komputer sekarang digabungkan dalam bidang komersil, sistem kontrol penerbangan pesawat militer, pengontrol industri, aplikasi antariksa, dan sistem perbankan. Dalam setiap aplikasi kesalahan kerja komputer dapat merusak catatan keuangan, keselamatan lingkungan, keamanan nasional, bahkan nyawa manusia. Singkatnya, fault tolerance menjadi

lebih penting karena fungsi komputer dan sistem digital lainnya menjadi lebih kritis. Fault tolerance merupakan sistem perlengkapan yang dirancang didalam suatu sistem untuk mencapai tujuan perancangannya. Sebagai rancangan maka harus sesuai dengan fungsi dan tujuan kerjanya, hal ini memerlukan pemenuhan kebutuhan lain. Ada tiga istilah pokok dalam rancangan fault tolerance yaitu, fault, error, dan failure. Ketiganya mempunyai hubungan sebab dan akibat. Tegasnya, fault adalah penyebab error, dan error adalah penyebab failure. Fault (kerusakan) adalah kerusakan fisik, ketidak sempurnaan, atau kerusakan yang terjadi di dalam komponen perangkat keras atau lunak. Contoh fault : short (hubungan singkat) antara konduktor listrik, open atau break dalam konduktor, atau kerusakan fisik atau ketidaksempurnaan dalam device semikonduktor. Demikian juga pemakai ingin membuat katup off, sistem akan mengalami kegagalan. Fault dapat disebabkan oleh bermacam-macam hal yang terjadi di dalam komponen elektronika, diluar komponen, atau selama komponen tersebut atau proses perancangan sistem. Hal ini sangat penting untuk memahami semua kemungkinan penyebab fault. Untuk memahami bermacam-macam penyebab fault, kita pertamatama memeriksa proses rancangan khusus untuk mengidentifikasi bidangbidang dimana fault dapat terjadi. Kemungkinan penyebab fault dapat dihubungkan dengan permasalahan pada empat bidang dasar yaitu : spesifikasi, implementasi, komponen, dan factor luar. 1. Kesalahan spesifikasi (Spesification Mistake). Ini termasuk algortima, arsitektur, atau spesifikasi perancangan hardware dan software yang salah. 2. Kesalahan implementasi (Implementation Mistake).

Implementasi, yang didefinisikan di sini, adalah proses transformasi spesifikasi hardware dan software ke dalam bentuk fisik hardware dan software sebenarnya. Implementasi dapat memasukkan fault yang disebabkan design yang jelek, pemilihan komponen yang jelek, konstruksi jelek, kesalahan perngkodean software. 3. Kerusakan komponen (Component Defect). Ketidaksempurnaan manufaktur, kerusakan device acak, dan komponen using adalah contoh jenis kerusakan komponen. Kerusakan dapat diakibatkan putusnya ikatan dalam rangkaian atau korosi logam. Kerusakan komponen paling umum dipertimbangkan sebagai salah satu dari beberapa penyebab fault. 4. Gangguan luar (External Disturbance). Seperti : radiasi, interfensi elektromagnetik, kerusakan akibat

perang,kesalahan operator dan lingkungan yang ekstrim.

Filosofi rancangan memberantas fault Ada tiga bentuk teknik utama usaha memperbaiki atau memelihara unjuk kerja normal sistem yaitu : fault avoidance, fault masking, dan fault tolerance. 1. Fault avoidance Fault avoidance adalah teknik yang digunakan untuk mencegah fault pada tempat yang pertama. Fault avoidance dapat termasuk hal-hal seperti : tinjauan design, penyaringan komponen, testing, metode kontrol kualitas lainnya. Jika tinjauan design misalnya, dilakukan dengan tepat, banyak kesalahan spesifikasi yang dapat mengakibatkan fault dapat dihilangkan. Juga sistem dapat sering dilindungi untuk mencegah gangguan luar yang menimbulakn fault dalam

sistem seperti halililntas atau radiasi. Perlindungan adalah bentuk fault avoidance. Terakhir, jika sistem setelah manufaktur dapat dideteksi dan dihilangkan sebelum sistem diletakkan dalam operasi. 2. Fault masking Fault masking adalah proses yang mencegah kerusakan dalam sistem dari error yang masuk ke dalam susunan informasi dari sistem tersebut. Error correcting memories, sebagai contohnya, memperbaiki data memori sebelum sistem memakai data. Jadi sistem tidak pernah mengalami dampak kerusakan dalam memori. Contoh lain dari fault masking adalah pengambilan suara mayoritas. Jika komite tiga orang membuat keputusan dengan voting ya atau tidak dalam suatu perbandingan, setiap saat vote yang disetujui menentukan keputusan dari komite. Keputusan yang dihasilkan oleh komite mewakili keinginan mayoritas anggota komite dan menutupi (mask) keinginan dari anggota yang mungkin saja tidak setuju dengan mayoritas. Teknik yang sama dapat diterapkan pada sistem digital sedemikian hingga dua modul dapat menutupi akibat dari modul yang rusak. 3. Fault tolerance Fault tolerance adalah kemampuan sistem untuk melanjutkan tugasnya setelah terjadinya kerusakan. Sasaran pokok fault tolerance adalah mencegah kegagalan (failure) sistem jika sekiranya terjadi. Karena failure disebabkan langsung oleh error, istilah fault tolerance dan error tolerance sering digunakan saling bertukaran. Untuk tujuan kita, bagaimana, kita memakai istilah faut tolerance. Fault tolerance dapat dicapai dengan banyak teknik. Tentu saja fault masking adalah salah satu pendekatan untu mentolerir fault yang terjadi. Pendekatan lainnya adalah mendeteksi dan melokasikan fault yang terjadi dan rekonfigurasi sistem untuk mengganti komponen yang rusak. Rekonfigurasi adalah proses penghilangan bagian sistem yang rusak dan memperbaiki sistem pada kondisi atau keadaan operasional. Jika teknik rekonfigurasi digunakan, perncang harus memperhatikan proses-proses berikut ini :
4

1. Fault detection adalah proses pengenalan apakah sebuah fault terjadi. Fault detection sering digunakan sebelum prosedur pemulihan dapat diimplementasikan. 2. Fault location adalah proses penentuan dimana fault terjadi sehingga pemulihan yagn tepat dapat diimplementasikan. 3. Fault containment adalah proses pengisolasian fault dan mencegah akbiat fault menyebar ke selururh sistem. Fault containment dibutuhkan dalam semua rancangan fault tolerance. 4. Fault recovery adalah proses dari penetapan operasional atau perolehan kembali status operasional lewat rekonfigurasi jika sekiranya ada fault. Pengembangan fault-tolerant sistem membutuhkan pertimbangan dari banyak persoalan design. Diantaranya adalah fault detection, fault containment, fault recovery, dan fault masking. Masing-masing konsep ini sudah dijelaskan dalam bab sebelumnya, tetapi di sini kita mempertimbangkan peranan dari masing-masing fungsi dalam mendesign fault-tolerant sistem. Bab ini memperkenalkan teknik untuk mencapai fault detection, fault location, fault containment, fault masking, fault recovery, dan fault tolerance, masing masing membutuhkan beberapa bentuk redundansi (cadangan). Sebelum kita membahas bentuk khusus redundansi, sebuah definisi fundamental dari redundansi akan dipaparkan dan dijelaskan.

TEKNIK ANALISA REQUIREMENT

Dalam tahap ini akan dicapai 4 tujuan, yaitu: a) Menjelaskan sistem saat ini secara lengkap.
b) Menggambarkan sistem informasi yang ideal. c) Membawa sistem informasi yang ideal ke kondisi saat ini dengan

memperhatikan kendala sumber daya.

d) Memberi

dorongan

terhadap

keyakinan

pemakai

kedalam

team

pengembangan sistem. Tahap requirement analysis adalah tahap interaksi intensif antara analis sistem dengan komunitas pemakai sistem (end-user), dimana team pengembangan sistem menunjukkan keahliannya untuk mendapatkan tanggapan dan kepercayaan pemakai, sehingga mendapat partisipasi yang baik. Merupakan pekerjaan sulit untuk mendapatkan kesepakatan (skeptical) pemaka tentang kebutuhan mereka dari sebuah sistem informasi, karena mungkin pemakai mengalami kegagalan sistem informasi sebelumnya. Keinginan pemakai Tahap awal dalam requirement sistem adalah melakukan survey terhadap keinginan pemakai dan menjelaskan sistem informasi yang ideal. Ideal disini merupakan konsep daripada kenyataan, artinya bahwa tidak ada sistem yang ideal (tidak ada sistem informasi yang sempurna) tetapi bersifat subyektif saja. Kalau hal ini tidak dijelaskan secara mendalam dapat menimbulkan perbedaan pandangan atau akan mengecewakan end-user.

 Metode kebutuhan analisis Perlu pemilihan metode pengumpulan data yang tepat selama melakukan requirement sistem. Metode tersebut adalah interviews, questionnaires,observation, procedure analysis, dan document survey. Setiap metode akan dijelaskan secara mendalam sebagai berikut : Tanya jawab (Interviews) 1. Bagaimana metode itu digunakan. Pemilihan potential interviewees. Membuat perjanjian terhadap potential interviewees. Menyiapkan struktur pertanyaan yang lengkap dan jelas. Memilih person yang diinterview secara pribadi dan merekamnya. 2. Target dari metode. Kunci pribadi dalam proses DFD. Kadangkala melibatkan orang luar, seperti pelanggan atau vendors. 3. Keuntungan metode. Pewawancara dapat mengukur respon melalui pertanyaan dan menyesuaikannya sesuai situasi yang terjadi. Baik untuk permasalahan yang tidak terstruktur, seperti mengapa anda berpikir hal ini dapat terjadi ? Menunjukkan kesan interviewer secara pribadi. Memunculkan respons yang tinggi sejak penyusunan pertemuan.

4. Kerugian metode. Membutuhkan waktu dan biaya yang tidak sedikit. Membutuhkan pelatihan dan pengalaman khusus dari pewawancara. Sulit membandingkan laporan wawancara karena subyektivitas alamiah. 5. Kapan metode tersebut baik digunakan. Mendapatkan penjelasan atau pandangan dari personel kunci. Test kredibilitas dari interviewees. Mencari interview yang unsureness atau contradictions. Memantapkan kredibilitas team.

Beberapa faktor penting dalam interview yang baik, yaitu objektives, audience, format, weighting dan combining responses, and docummentation. Kuesioner (Questionnaires) 1. Bagaimana metode itu digunakan. Mendisain dengan menggunakan standar kuesioner. Kuesioner dikirimkan ke lingkungan kerja end-users. Struktur respon diringkas dalam statistik distribusi. 2. Target dari metode. Semua end-user dengan wawasannya akan dilibatkan dalam proses solusi pemecahan sistem.

 End-user dihubungkan dengan proses pemakaian simbol-simbol dalam DFD.

3. Keuntungan metode. Murah dan cepat dari pada interviews. Tidak membutuhkan investigator yang terlatih (hanya satu ahli yang dibutuhkan untuk mendesain kuesioner untuk end-user yang terpilih. Mudah untuk mensintesis hasil sejak pembuatan kuesioner. Dengan mudah dapat meminimalkan biaya untuk semua end-user. 4. Kerugian metode. Tidak dapat membuat pertanyaan yang spesifik bagi end-user. Analis melibatkan kesan sehingga tidak dapat menampakkan pribadi end-user. Tanggapan yang rendah karena tidak adanya dorongan yang kuat untuk mengembalikan kuesioner. Tidak dapat menyesuaikan pertanyaan ke end-user secara spesifik. 5. Kapan metode tersebut baik digunakan. Pertanyaannya sederhana, dan tidak memiliki arti mendua. Membutuhkan wawasan yang luas dari end-user. Bila memiliki sedikit waktu dan biaya. Observasi (Observation)

1. Bagaimana metode itu digunakan. Secara pribadi seorang analis mengunjungi lokasi pengamatan. Analis merekam kejadian dalam lokasi pengamatan, termasuk volumen dan pengolahan lembar kerja. 2. Target dari metode. Lokasi proses secara geografis ditunjukkan dalam DFD (Data Flow Diagram) 3. Keuntungan metode. Mendapatkan fakta records daripada pendapat (opinion). Tidak membutuhkan konstruksi pertanyaan. Tidak menganggu atau menyembunyikan sesuatu (end-users tidak mengetahui bahwa mereka sedang diamati). Analis tidak bergantung pada penjelasan lisan dari end-users. 4. Kerugian metode. Jika terlihat, analis mungkin mengubah operasi (end-user merasa diamati). Dalam jangka panjang, fakta yang diperoleh dalam satu observasi mungkin tidak tepat (representative) dalam kondisi harian atau mingguan. Membutuhkan pengalaman dan kehlian khusus dari analis. 5. Kapan metode tersebut baik digunakan. Membutuhkan gambaran kuantitatif seperti waktu, volume dan sebagainya. Kecurigaan bahwa end-user mengatakan suatu kejadian yang sebenarnya tidak terjadi (dibuat-buat).

10

Tip praktis dalam melakukan observasi : a. Jangan mengamati dalam waktu yang lama. Terdapat dua alasan, yaitu : dengan waktu yang lama akan mengacau operasi yang sedang diamati, dan akan membiaskan permasalahan yang sebenarnya. b. Buat catatan yang ringkas. c. Sebelum observasi, beritahukan kepada supervisor dan pemakai yang terlibat tentang apa yang akan dikerjakan dan mengapa dikerjakan, sehingga akan mengurangi gangguan. d. Gunakan checklist yang singkat tentang informasi yang dibutuhkan bersama. e. Jangan melakukan observasi tanpa rencana.. Prosedur analisis (Procedure Analysis) 1. Bagaimana metode itu digunakan. Dengan prosedur operasi dapat mempelajari dan mengidentifikasikan aliran dokumen kunci melalui sistem informasi, yaitu dengan data flow diagram (DFD). Setiap aliran dokumen kunci menjelaskan prosedur operasi sistem. Melalui observasi, analis mempelajari kenyataan daripada mendeskripsikan volume distribusi (tinggi, rendah, sedang) dan apa yang selanjutnya dikerjakan terhadap salinan dari dokumen aslinya. 2. Target dari metode. Dokumen utama dalam DFD (Data Flow Diagram) Proses dalam DFD.

11

3. Keuntungan metode. Evaluasi prosedur dapat dikerjakan dengan campur tangan (interferences) yang minimal dan tidak mempengaruhi operasi pemakai. Prosedur aliran dapat dapat menjadi sebuah struktur checklist untuk melakukan observasi. 4. Kerugian metode. Prosedure mungkin tidak lengkap dan tidak -up to date lagi. Mempelajari bagan aliran dokumen membutuhkan waktu dan keahlian analis. 5. Kapan metode tersebut baik digunakan. Memutuskan apakah masalah kegagalan sistem dapat membantu perancangan yang baik. Tim analis tidak secara total familiar dengan aliran dokumen. Mendeskripsikan aliran dokumen yang menganggu kerjanya fungsi. Pengamatan dokumen (Document Survey) 1. Bagaimana metode itu digunakan. Mengidentifikasikan dokumen utama dan laporan (physical data flow diagram). Mengumpulkan salinan dokumen aktual dan laporan. Setiap dokumen atau laporan, digunakan untuk record data, meliputi field (ukuran dan tipe), frekuensi penggunaan dan struktur kodingnya (coding structure). 2. Target dari metode. Aliran data kunci ditunjukkan dalam data flow diagram (DFD).
12

3. Keuntungan metode. Meminimalkan interupsi dari fungsi operasionalnya. Permulaan elemen kamus data. Seringkali, dapat mempertimbangkan modifikasi major procedural. 4. Kerugian metode. Membutuhkan waktu yang cukup (terdapat organisasi bisnis yang mengalami kebanjiran dokumen dan laporan). 5. Kapan metode tersebut baik digunakan. Harus dikerjakan jika sebuah sistem akan didesain (selama kegiatan analisis, dalam memperjelas desain sistem yang baru dan analisis dokumen dapat membantu untuk menentukan tugas perancangan selanjutnya). Sampling Sampling dapat membantu mengurangi waktu dan biaya. Perlu kecermatan untuk memilih sample dari populasi, sehingga membutuhkan keahlian statistik supaya tidak mengalami kegagalan atau ancaman. Kendala sumber daya a. Waktu Sebuah pengantian sistem harus diutarakan dalam kerangka kerja sejak sistem mengalami penurunan fungsi dengan cepat. Kendala waktu ini dapat mempengaruhi analis untuk mempertimbangkan inovasi teknologi yang tidak mungkin dioperasikan dalam waktu yang singkat. Oleh karena itu perlu membutuhkan waktu yang cukup supaya memiliki kelonggaran waktu sehingga dapat membuat alternatif yang paling baik.
13

b. Uang Sistem informasi yang ideal akan membutuhkan biaya yang mahal, sehingga membutuhkan pendanaan yang cukup. Hal ini akan terjadi karena terjadi persaingan dengan para pesaingnya dimana mereka menanamkan investasi yang besar dalam sistem informasinya. c. Keahlian. Staff sistem informasi mungkin tidak memiliki pengetahuan atau pengalaman yang cukup seperti masalah telekomunikasi, integrasi database, dan interactive setting. Perusahaan dapat mengkontrak konsultan untuk menambah kemampuan mendesain. Hal ini nantinya akan diperhadapkan pada kendala biaya yang dikeluarkan untuk tenaga konsultan. d. Teknologi. Kebutuhan teknologi mungkin akan menjadi masalah utama dalam mendukung kerja sistem, sehingga perlu memperhatikan perkembangan teknologi terusmenerus, yang konsekuensinya terjadi pengeluaran biaya yang besar dan jangan sampai teknologi yang dipakai ketinggalan dari para pesaingnya. e. Faktor ekternal. Banyak kendala yang datang dari luar setting design, seperti pencegahan menggunakan teknologi eksotik (exotic of technologies), mencegah memelihara data lokal dalam sebuah sistem database pusat, dan sebagainya. Dokumen kebutuhan analisis 1. Arahan (conduct) analisis. Hubungan dengan pemakai akhir. Menganalisa records, forms dan laporan.

14

 Pengamatan proses. Menganalisa metode yang digunakan. Permasalahan dalam pengumpulan data.

2. Kebutuhan pemakai. Apa yang menjadi kebutuhan sebenarnya. Kebutuhan laporan (jenis dan frekuensinya). Kebutuhan pelatihan. Pengaruh sistem baru. 3. Kendala sistem. Menjelaskan kendala waktu, biaya, keahlian, teknologi dan faktor ekternal. Realistik sistem. 4. Dokumentasi. Intrumen pengumpulan data (kebutuhan kuesioner, interview). Konsensus statistik. Aliran data secara logikal dan phisik. Element awal dalam kamus data.

15

VERIFIKASI DAN VALIDASI MODEL SIMULASI

Model simulasi yang dibangun harus kredibel. Representasi kredibel sistem nyata oleh model simulasi ditunjukkan oleh verifikasi dan validasi model. Verifikasi adalah proses pemeriksaan apakah logika operasional model (program komputer) sesuai dengan logika diagram alur. Kalimat sederhananya, apakah ada kesalahan dalam program? (Hoover dan Perry, 1989); verifikasi adalah pemeriksaan apakah program komputer simulasi berjalan sesuai dengan yang diinginkan, dengan pemeriksaan program komputer. Verifikasi memeriksa penerjemahan model simulasi konseptual (diagram alur dan asumsi) ke dalam bahasa pemrograman secara benar (Law dan Kelton, 1991) .

16

Validasi adalah proses penentuan apakah model, sebagai konseptualisasi atau abstraksi, merupakan representasi berarti dan akurat dari sistem nyata? (Hoover dan Perry, 1989); validasi adalah penentuan apakah mode konseptual simulasi (sebagai tandingan program komputer) adalah representasi akurat dari sistem nyata yang sedang dimodelkan (Law dan Kelton, 1991).

Aturan verifikasi Dan Validasi dalam Simulasi Ketika membangun model simulasi sistem nyata, kita harus melewati

beberapa tahapan atau level pemodelan. Seperti yang dapat dilihat pada Gambar 1, pertama kita harus membangun model konseptual yang memuat elemen sistem nyata. Dari model konseptual ini kita membangun model logika yang memuat relasi logis antara elemen sistem juga variable eksogenus yang mempengaruhi sistem. Model kedua ini sering disebut sebagai model diagram alur. Menggunakan model diagram alur ini, lalu dikembangkan program komputer, yang disebut juga sebagai model simulasi, yang akan mengeksekusi model diagram alur. Pengembangan model simulasi merupakan proses iteratif dengan beberapa perubahan kecil pada setiap tahap. Dasar iterasi antara model yang berbeda adalah kesuksesan atau kegagalan ketika verifikasi dan validasi setiap model. Ketika validasi model dilakukan, kita mengembangkan representasi kredibel sistem nyata, ketika verifikasi dilakukan kita memeriksa apakah logika model diimplementasikan dengan benar atau tidak. Karena verifikasi dan validasi berbeda, teknik yang digunakan untuk yang satu tidak selalu bermanfaat untuk yang lain. Baik untuk verifikasi atau validasi model, kita harus membangun sekumpulan kriteria untuk menilai apakah diagram alur model dan logika internal adalah benar dan apakah model konseptual representasi valid dari sistem nyata. Bersamaan dengan kriteria evaluasi model, kita harus spesifikasikan siapa yang

17

akan mengaplikasikan criteria dan menilai seberapa dekat kriteria itu memenuhi apa yang sebenarnya.

Praktisi simulasi harus dapat menentukan aspek apa saja, dari sistem yang kompleks, yang perlu disertakan dalam model simulasi. Petunjuk umum dalam menentukan tingkat kedetailan yang diperlukan dalam model simulasi : Hati-hati dalam mendefinisikan Model-model tidak valid secara universal
Memanfaatkan pakar dan analisis sensitivitas untuk membantu

menentukan level detil model Validasi Model Konseptual Validasi model konseptual adalah proses pembentukan abstraksi relevan sistem nyata terhadap pertanyaan model simulasi yang diharapkan akan dijawab.

18

Validasi model simulasi dapat dibayangkan sebagai proses pengikat dimana analis simulasi, pengambil keputusan dan manajer sistem setuju aspek mana dari sistem nyata yang akan dimasukkan dalam model, dan informasi apa (output) yang diharapkan akan dihasilkan dari model. Tidak ada metode standar untuk validasi model konseptual, kita hanya akan melihat beberapa metode yang berguna untuk validasi. Representasi Kejadian Sistem Metode ini menggunakan graf kejadian seperti yang digunakan dalam pengembangan model simulasi. Teknik pembuatan grafnya juga sama. Kita harus mendefinisikan dengan jelas relasi kondisional antar kejadian. Representasi graf dapat digunakan sebagai jembatan ke model logis (model diagram alur) juga sebagai alat bantu komunikasi antara analis simulasi, pengambil keputusan dan manajer. Hampir sama dengan graf kejadian adalah model diagram alur, merepresentasikan aliran entitas melalui sistem. Ingat kembali, representasi kejadian sistem komputer time shared adalah:

Secara konseptual, kita modelkan sistem sebagai interaksi kejadian:

pemakai melakukan koneksi ke sistem

pemakai terhubung dan sesi mulai

19

 pemakai menyudahi sesi

pemakai yang ditolak mencoba koneksi ke sistem

Identifikasi Eksplisit Elemen yang Harus Ada dalam Model Pada umunya model konseptual tidak dapat memasukkan semua detil sistem nyata, melainkan hanya elemen yang relevan dengan pertanyaan yang diharapkan akan dijawab. Dalam pembuatan model konseptual, semua kejadian, fasilitas, peralatan, aturan operasi, variabel status, variabel keputusan dan ukuran kinerja harus jelas diidentifikasikan dan akan menjadi bagian dari model simulasi. Kita juga harus mengidentifikasikan dengan jelas semua elemen yang tidak akan dimasukkan dalam model simulasi. Analis simulasi, pengambil keputusan dan manajer harus bergabung untuk memutuskan berapa banyak sistem nyata harus dimasukkan untuk menghasilkan representasi valid sistem nyata. Dua filosofi yang digunakan untuk memutuskan berapa banyak sistem nyata harus dimasukkan dalam model simulasi: 1. Masukkan semua aspek sistem yang dapat mempengaruhi perilaku sistem dan menyederhanakan model begitu dapat memahami elemen relevan sistem. 2. Mulai dengan model sederhana sistem dan biarkan model berkembang semakin kompleks sejalan degan semakin jelasnya eleme-elemen sistem yang harus dimasukkan dalam model untuk menjawab pertanyaan. Kita juga percaya bahwa filosofi berikut ini juga perlu diikuti. 3. keluarkan usaha dan waktu yang lebih banyak dengan mereka yang lebih memahami sistem nyata, identifikasikan semua elemen yang akan

20

memberikan dampak signifikan akan jawaban pertanyaan model yang diharapkan akan dijawab. Sistem komputer time-shared adalah sebagai berikut: Kejadian :

1. pemakai berusaha koneksi ke sistem 2. pemakai terhubung dan sesi mulai 3. pemakai menyudahi sesi Fasilitas :

1. Komputer server 2. Port Variabel status :

1. Jumlah port yang sedang digunakan 2. Waktu pemanggilan berikutnya 3. Waktu akhir koneksi port ke-i 4. Mengindikasikan apakah port sibuk atau menganggur Ukuran kinerja:

1. Waktu kumulatif pemakai terhubung ke sistem 2. Jumlah total pemakai memanggil sistem 3. Jumlah total panggilan yang terhubung 4. Jumlah total panggilan yang gagal terhubung

21

5. Utilitas portq Variabel keputusan:

1. Jumlah port 2. Ekspektasi lama sesi pemakai

Aturan operasional :

1. Klien mencoba berulang-ulang sampai tersambung. Aspek sistem nyata yang tidak dimasukkan diantaranya:

2. Klien tidak akan mencoba hubungan lagi pada periode waktu tertentu jika menemukan port semua sibuk. 3. Kerusakan fasilitas Verifikasi dan Validasi Model Logis Bentuk model logis tergantung dari bahasa pemrograman yang akan digunakan. Jika model konseptual sudah dibangun dengan baik, verifikasi model konseptual bukan pekerjaan kompleks. Ada beberapa pertanyaan yang harus dijawab sebelum kita yakin bahwa model logis merepresentasikan model konseptual. Salah satu pendekatan yang digunakan untuk verifikasi model logis adalah dengan fokus pada: 1. apakah kejadian dalam model diproses dengan benar? 2. apakah rumus matematika dan relasi dalam model valid? 3. apakah statistik dan ukuran kinerja diukur dengan benar?

22

Verifikasi dan Validasi Pemrosesan Kejadian validasi bahwa model logis mengandung semua kejadian dalam model konseptual verifikasi hubungan di antara kejadian verifikasi bahwa model logis memproses kejadian secara simultan dengan urutan benar.

Verifikasi bahwa semua variabel status yang berubah karena terjadinya suatu kejadian diperbaiki dengan benar.

Metode umum yang digunakan untuk verifikasi dan validasi pemrosesan kejadian dalam model logis adalah structured walk-through, dimana pengembang model logis harus menjelaskan (walk through) logika detil model ke anggota lain tim pengembang model simulasi. Kembali ke kasus sistem komputer time-shared, verifikasi dan validasi pemrosesan kejadian bisa diperiksa mulai dari kondisi TT_FINAL? sampai dengan N=K?. Verifikasi Rumus dan Relasi Termasuk dalam model simulasi adalah sejumlah eksplisit atau implisit fungsi dan relasi matematik. Penurunan angka acak dan variabel acak berbasis matematik, dan dalam model simulasi pada umumnya ada hukum konservasi yang harus dipenuhi. Verifikasi Statistik dan Ukuran Kinerja Kesalahan umum yang terjadi dalam pemodelan simulasi adalah gagal memperbaharui statistik relevan dan ukuran kinerja secara tepat ketika suatu

23

kejadian terjadi. Salah satu cara yang dapat digunakan untuk verifikasi bahwa statistik dan ukuran kinerja diperbaharui dengan benar adalah menggunakan graf kejadian. Dalam kebanyakan bahasa simulasi, beberapa tipe ukuran statistik dapat dikumpulkan secara otomatis saat simulasi dieksekusi. Oleh karena itu, ukuran statistik dibangun dalam metode yang transparan ke analis, sehingga mengurangi kesempatan kesalahan statistik. Ketika model logis dibangun adalah penting melakukan validasi bahwa sttaistik dan ukuran kinerja adalah satu-satunya yang perlu dijawab.

Verifikasi Model Komputer Teknik Verifikasi Progam: Teknik1.Buatlah dan debug program komputer dalam modul-modul atau subprogramsubprogram Teknik2. Buatlah program komputer secara bersama-sama (lebih dari satu orang) Teknik3.Menjalankan simulasi dengan berbagai variasi parameter input dan memeriksa apakah outputnya reasonable Teknik4.Melakukan trace. Teknik ini merupakan salah satu teknik yang powerful yang dapat digunakan untuk mendebug program simulasi event diskrit. Teknik 5. Model sebaiknya dapat dijalankan (jika memugkinkan) dengan asumsi sederhana.

24

Teknik6.Untuk beberapa model simulasi, akan lebih bermanfaat untuk melakukan observasi sebuah animasi dari output simulasi. Teknik7.Tulislah mean sampel dan varinasi sampel untuk setiap probabilitas distribusi input simulasi, dan bandingkan dengan mean dan variansi yang diinginkan (misalnya secara historis) Teknik 8. Gunakan paket simulasi Model komputer diverifikasi dengan menunjukkan bahwa program komputer adalah implementasi tepat model logis. Beberapa metode yang digunakan untuk verifikasi model komputer adalah unik terhadap simulasi, sementara metode verifikasi lain sama dengan yang digunakan dalam setiap pengembangan perangkat lunak lainnya. Verifikasi model computer sangat tergantung dengan bahasa pemrograman yang digunakan dan tidak ada metodologi umum yang disetujui. Verifikasi model komputer sering membutuhkan imaginasi dan keahlian tinggi analis, dan ini adalah satu aktivitas dalam proyek simulasi yang dilakukan tanpa bantuan pengambil keputusan dan manajer. Verifikasi model komputer dapat dilakukan dengan: Metode pemrograman terstruktur Penelusuran model simulasi Pengujian Pengujian relasi logis Verifikasi dengan model analitis Verifikasi menggunakan grafik

25

Metode Pemrograman Terstruktur Prinsip pemrograman terstruktur termasuk :

1. Disain Atas-Bawah (Top-Down). Program dirancang mulai dari proses

level tertinggi yang kemudian didekomposisi menjadi modul pendukung yang kemudian dapat didekomposisi lagi.
2. Modularitas : setiap modul pendukung bertanggung jawab untuk satu

fungsi.
3. Perbaikan langkah demi langkah : setiap modul dikembangkan dengan

perbaikan langkah demi-langkah dan diakhiri dengan kode khusus-bahasa pemrograman. Beberapa langkah perbaikan sudah terjadi pada pengembangan model logis.
4. Pemampatan modul: modul harus pendek. 5. Kontrol terstruktur : semua kode kontrol harus sangat terstruktur

menggunakan pernyataan IF-THEN-ELSE, WHILE, REPEAT-UNTIL, FOR DAN CASE. Penggunan pernyataan GOTO harus dihindarkan.

Penelusuran Simulasi Beberapa bahasa simulasi menyediakan kemampuan-terpasang

penelusuran simulasi sebagaimana terjadinya. Ketika model simulasi diprogram menggunakan bahasa umum (seperti FORTRAN, Pascal, C++), tentu saja analis harus membangun kemampuan penelusuran dalam kode program. Ketika membangun memprogram model logika, mekanisme penelusuran simulasi harus dimasukkan sebagai bagian dari disain program dan tidak ditutupi ketika ada kesalahan dalam program komputer. Pengujian

26

Dua pendekatan pengujian adalah bottom-up dan top-down. Pada pendekatan bottom-up, yang terendah, modul dasar pada umumnya diuji dan diverifikasi terlebih dahulu. Pendekatan kadang-kadang disebut dengan pengujian unit. Setelah modul dasar diuji, uji terintegrasi dilakukan dimana interface diantara kedua modul diuji. Pendekatan bottom-up ini berlanjut terus sampai model dapat diuji sebagai sistem tunggal. Bagian terpenting dalam pengujian adalah seleksi data uji. Keuntungan pengujian modul paling rendah terlebih dahulu adalah pengujian itu membutuhkan himpunan data uji yang lebih kecil daripada modul integrasi yang lebih besar. Modul dapat diuji menggunakan driver yang menurunkan data uji, dan kemudian modul dieksekusi. Pada pendekatan top-down, pengujian dimulai dengan modul utama dan secara inkremntal bergerak turun ke modul paling rendah. Dalam pengujian topdown, rutin (routine) dummy dibutuhkan untuk mensimulasikan fungsi modul level paling rendah. Keuntungan pendekatan top-down adalah proses berlangsung secara logika, paralel dengan aliran program. Programmer dan manajer biasanya lebih menyukai pendekatan top-down karena keberlangsungna proses dapat dilihat. Setelah model diuji baik dengan pendekatan bottom-up ataupun top-down, model harus diuji coba dengan kondisi paling ekstrim. Jika dipilih dengan hatihati, hasil simulasi dengan kondisi ekstrim dapat diprediksi. Pengujian Relasi Logis Relasi ini dapat didasarkan pada hukum konservasi atau secara statistik. Jika relasi ini tidak diperhatikan, maka program bukan implementasi benar dari model logis. Titik paling sesuai untuk memeriksa relasi itu adalah ketika model berjalan tahap demi tahap. Secara tipikal, kesalahan pemrograman tidak acak dan berdistribusi secara uniform, tetapi berkumpul secara kluster. Validasi Model Simulasi

Persfektif Umum Simulasi:

27

1. Eksperimen dengan model simulasi untuk eksperimen sistem actual 2. Kemudahan

atau kesulitan dari proses validasi tergantung pada

kompleksitas sistem yang dimodelkan

3. Sebuah model simulasi dari sebuah sistem yang kompleks hanya dapat

menjadi pendekatan terhadap aktual sistem 4. Sebuah model simulasi sebaiknya selalu dibangun untuk sekumpulan tujuan tertentu 5. Sebuah buku catatan dari asumsi-asumsi model simulasi sebaiknya diupdate berkala
6. Sebuah model simulasi sebaiknya divalidasi relatif terhadap ukuran kinerja

yang akan digunakan untuk pengambilan keputusan 7. Pembentukan model dan validasi sebaiknya dilakukan sepanjang pensimulasian
8. Pada umumnya tidak mungkin untuk membentuk validasi statistik secara

formal diantara data output model dengan data output sistem actual

Langkah 1. Membangun sebuah model dengan usaha melibatkan informasi semaksimal mungkin:

Berdiskusi dengan para pakar sistem Melakukan observasi terhadap sistem Memanfaatkan Teori yang ada Memanfaatkan hasil dari Model simulasi yang sama dan relevan
28

Menggunakan pengalaman atau intuisi Memanfaatkan Teori yang ada Memanfaatkan hasil dari Model simulasi yang sama dan relevan Menggunakan pengalaman atau intuisi

Langkah 2. Menguji asumsi-asumsi model secara empiris Jika distribusi probabilitas secara teoritis cocok dengan observasi dan digunakan sebagai input untuk model simulasi, dapat diuji dengan pembuatan grafik dan uji goodness-of-fit Jika beberapa himpunan data diobservasi untuk fenomena random yang sama, maka perbaikan dari penggabungan data tersebut dapat ditentukan dengan uji Kruskal-Wallis Salah satu utiliti yang sangat berguna adalah analisis sensitivitas Langkah 3. Menentukan seberapa representatif output Simulasi Prosedur Statistik untuk membandingkan data output dari observasi dunia nyata dan simulasi: Korelasi pendekatan inspeksi : Pendekatan pendugaan selang kepercayaan berdasarkan data independen Pendekatan Time Series

29

Validasi model simulasi dilakukan dengan partisipasi analis, pengambil keputusan dan manajer sistem. Uji validasi model adalah apakah pengambil keputusan dapat mempercayai model yang digunakan sebagai bagian dari proses pengambilan keputusan. Tidak ada teknik tunggal untuk melakukan validasi model. Prosedur validasi model simulasi tergantung dari sistem yang sedang dimodelkann dan lingkungan pemodelan. Beberapa metode validasi adalah:
1. Perbandingan output simulasi dengan sistem nyata. 2. Metode Delphi. 3. Pengujian Turing. 4. Perilaku ekstrim

Perbandingan Output Simulasi dengan Sistem Nyata Membandingkan output ukuran kinerja model simulasi dengan ukuran kinerja yang sesuai dari sistem nyata adalah metode yang paling sesuai untuk melakukan validasi model simulasi. Jika ukuran kinerja sistem nyata cukup tersedia, uji statistik umum seperti uji t digunakan dimana kita menguji hipotesis kesamaan nilai rata-rata. Kadang-kadang uji F juga dapat digunakan untuk

30

menguji kesamaan ragam sistem nyata dengan model simulasi. Beberapa metode nonparametrik lainnya juga bisa digunakan, misalnya ChiSquare dan Kolmogorov Smirnov. Perbandingan antara model dan sistem nyata merupakan perbandingan statistik dan perbedaan dalam performans harus diuji untuk signifikansi statistiknya. Perbandingan ini tidak bisa dilakukan dengan sederhana begitu, karena performans yang diukur menggunakan simulasi didasarkan pada periode waktu yang sangat lama, mungkin beberapa tahun. Kinerja yang diukur dalam sistem nyata sebaliknya didasarkan pada periode waktu singkat, mungkin hanya dalam ukuran minggu atau paling lama bulan. Kendala kedua, semua kondisi awal sistem, yang mempunyai pengaruh pada performans sistem secara umum tidak diketahui pada sistem nyata. Permasalahan lainnya dalam membuat perbandingan statistikal antara sistem nyata dengan model simulasi adalah bahwa performan yang diukur dalam sistem nyata mungkin merefleksikan banyak elemen atau pengaruh dalam sistem yang dikeluarkan dari sistem. Contohnya, ukuran kinerja untuk sistem produksi mungkin memasukkan pengaruh seperti shift kerja panjang, liburan dan kecelakaan industri. Pengaruh ini elbih disukai dikeluarkan dari model simulasi karena pengaruhnya akan konstan untuk sembarang alternatif model simulasi yang diharapkan untuk dievaluasi. Dalam banyak proyek model yang sedang disimulasikan, sistem nyata bahkan belum ada. Dalam kasus seperti itu, tidak ada ukuran kinerja sistem nyata yang dapat digunakan sebagai perbandingan dengan ukuran kinerja model simulasi. Cara terbaik mungkin mencari sistem yang mirip, tapi perbandingan seperti itu lemah.

31

Metode Delphi Metode Delphi dikembangkan sebagai pendekatan ke analisis

permasalahan ketika sangat sedikit data tersedia atau sistem nyata sedang dipertimbangkan. Dalam metode Delphi, sekelompok ahli terpilih membentuk panel yang akan menghasilkan jawaban konsensus terhadap pertanyaan yang diajukan ke mereka. Dalam lingkungan simulasi, panel mungkin terdiri dari manager dan pengguna sistem yang sedang dimodekan dan pertanyaan adalah tentang perilaku atau kinerja sistem di bawah kondisi operasi tertentu. Metode Delphi tidak memasukkan diskusi tatap muka, oleh karena itu terhindar dari ketegangan diskusi kelompok seperti dominasi peserta paling vokal. Metode dikembangkan oleh perusahaan RAND dan telah digunakan dalam berbagai bentuk. Metode Delphi terdiri dari prosedur interaktif berikut:
1. Kuesioner yang memuat pertanyaan respon sistem nyata terhadap input

tertentu atau perubahan struktural dikirim ke setiap anggota panel.

2. Didasarkan pada respon akan kuesioner pertama, kuesioner kedua

dibentuk yang akan menarik respon lebih spesifik dari panel.

3. Kuesioner baru dikirimkan ke panel bersamaan dengan pemurnian respon

panel akan pertanyaan dari tahap sebelumnya. Tahap 1 sampai 3 diulang 2 kali atau lebih sampai analis mendapatkan prediksi ahli akan respon sistem terhadap input atau perubahan struktural yang sedang dipertimbangkan. Kritikan pertama terhadap metode Delphi adalah bahwa itu mahal dan memerlukan waktu lama. Hal ini tidak selalu benar. Metode validasi Delphi tidak harus menyebabkan penundaan proyek simulasi karena itu dapat dilakuakn

32

bersamaan dengan pembangunan mode komputer. Metode Delphi mungkin akan sangat mahal, tetapi untuk beberapa proyek simulasi itu bisa relatif lebih murah dibandingkan metode lain. Kritikan kedua terhadap metode Delphi adalah jika metode itu cukup efektif memprediksi perilaku sistem nyata, mengapa tidak menggunakan metode Delphi in lieu pemodelan simulasi? Dalam beberapa situasi, faktanya metode Delphi mungkin menjadi metode yang efektif biaya; tetapi bagaimanapun, adalah tidak praktis untuk mempertahankan panel ahli untuk memprediksi respon sistem terhadap perubahan yang sedang dipertimbangkan. Pengujian Turing Metode ini diajukan oleh Alan Turing sebagai uji intelegensia buatan. Seorang ahli atau panel ahli menyediakan ringkasan gambaran atau laporan berdasarkan sistem nyata dan model simulasi. Jika ahli tidak dapat mengidentifikasi laporan berdasarkan output model simulasi, kredibilitas model ditingkatkan. Kesulitan utama validasi model menggunakan uji Turing adalah penyesuaian ukuran kinerja sistem nyata sehingga pengaruh tidak dimaksudkan sebagai bagian dari model simulasi dihilangkan. Perilaku Ekstrim Kadang-kadang sistem nyata dapat diamati di bawah kondisi ekstrim dimana situasi tidak biasa muncul. Kadang-kadang hal ini menjadi solusi ideal untuk mengumpulkan data ukuran kienrja sistem nyata untuk perbandingan output mode simulasi yang dijalankan pada kondisi yang sama. Kadang-kadang juga manager sistem lebih mudah memprediksi bagaimana perilaku sistem nyata pada kondisi ekstrim daripada pada kondisi normal. Dengan membandingkan prediksi perilaku sistem nyata di bawah kondisi ekstrim dengan kinerja model pada kondisi sama, mode dapat divalidasi.

33

COMPILE-TIME AND RUNTIME ENVIRONTMENT Perbedaan antara compile time dan run time adalah contoh dari teori yang utama yang disebut the phase distinction Itu adalah salah satu konsep yang harus dipelajari dengan sungguh sungguh, kususnya untuk orang orang yang tanpa baground yang cukup dalam bahasa pemrograman. Ada beberapa pertanyaan yang dapat membantu menjelaskan pertanyaan ini : 1. Sejauh mana program ini memuaskan? 2. Apakah fase ini dapat terjadi kesalahan?
3. Jika fase berhasil, Apa input dan outputnya, jika ada?

Compile time 1. Program ini tidak perlu memenuhi setiap infarians. Bahkan tidak perlu menjadi program well formed sama sekali. 2. Apa yang menjadi suatu kesalahan pada compile time Syntax errors Typechecking errors (Rarely) compiler crashes 3.Jika compiler berhasil, maka apa yg harus diketahui? a. Program ini dapat berjalan dengan baik dan dapat menggunakan

bahasa apapun

34

b.

Ini memungkinkan untuk menjalankan program

4. Apa yang menjadi input dan output nya?

a.

Masukan merupakan program yang sudah di compile, ditambah

file header, interface, perpustakaan dll, yang di butuhkan untuk menginpor agar dapat di kompilasi b. Output adalah kode assembly di dalam sebuah program yang dapat

dieksekusi

Run Time 1 . Kita tidak tahu apapun mengenai program invarian --- programmer memasukan apapun kedalam mereka. Invarian waktu berjalan yang jarang ditegakkan oleh kompilator saja, itu membutuhkan bantuan dari para pemrogram . 2 .Apa yang bisa salah adalah kesalahan waktu berjalan : divisi dengan nol deferencing sebuah penunjuk nol kehabisan memori

Juga akan ada kesalahan yang terdeteksi oleh program itu sendiri :

untuk berusaha membuka sebuah file yang sudah tidak ada mencoba menemukan sebuah halaman web yang diduga dan menemukan bahwa URL tidak terbentuk dengan baik

35

3 . Jika run-time berhasil , program tersebut selesai ( atau tetap akan )tanpa hancur . 4 . Input dan output yang seluruhnya tergantung kepada para pemrogram . File ,windows di layar , paket jaringan , pekerjaan yang dikirim ke printer , anda dapat sebutkan . Jika program ini meluncurkan rudal , yang ' s output , dan itu terjadi hanya pada jangka waktu.

36

CONCURRENT VERSION CONTROL SISTEM (CVS) CVS adalah singkatan dari Concurrent Version Sistem, sebuah sistem yang dapat membantu untuk mengontrol perubahan perubahan file. CVS bermula sebagai serangkaian script shell yang ditulis oleh Dick Grune, yang dikirimkan ke newsgroup comp.source.unix dalam rilis 6 volume pada Desember 1986. Meski tidak ada kode yang berasal dari script ini dalam versi baru CVS, banyak algoritma resolusi konflik berasal dari script tersebut. Bulan April 1989, Brian Berliner merancang dan mengkodekan CVS. Jeff Polk kemudian membantu Brian dengan desain modul CVS dan dukungan cabang vendor (vendor branch support). CVS ini biasanya dipakai oleh programmer untuk membantunya bekerja, walaupun sebenarnya CVS ini bisa dimanfaatkan tidak hanya oleh programmer. Contohnya CVS ini bisa juga dimanfaatkan oleh webmaster atau bisa juga dimanfaatkan oleh orang orang yang ingin membuat dokumen, dan banyak lagi lainnya. Sebenarnya ada banyak sistem yang menawarkan pengontrolan versi, tapi biasanya sistem itu hanya berlaku untuk satu lingkungan tertentu. Contohnya saja seperti Microsoft Word, aplikasi keluaran Microsoft menyediakan fasilitas pengontrolan versi untuk dokumen yang diolahnya, kemudian ada contoh lain misalnya Delphi, produk keluaran Borland ini dulu juga pernah menyertakan sistem pengontrolan versi yang dikenal dengan nama Version Control Sistem (VCS), tetapi pada akhirnya fasilitas ini malah dihilangkan. Masih banyak lagi contoh sistem pengontrolan versi yang lain, tetapi kebanyakan hanya bisa berjalan untuk aplikasi tertentu. Pada prinsipnya, CVS sangat membantu bagi para pengembang aplikasi dalam pengolahan file, terutama bagi development team yang memiliki banyak programmer yang bekerja dalam satu group. Salah satu manfaat CVS dapat dilihat dari contoh kasus dibawah ini : Seseorang pelanggan memesan aplikasi kepada programmer. Pelanggan tersebut ingin aplikasi yang dia pesan selesai dalam 2 minggu. Setelah melakukan persetujuan maka programmer mulai melakukan pengembangan aplikasi yang
37

telah dipesan. Ditengah proses pengembangan ketika kita menyerahkan prototype aplikasi ke pelanggan untuk diuji coba, ternyata ada beberapa bagian yang tidak cocok, akhirnya programmer harus menyesuaikan aplikasi lagi. Setelah programmer telah melakukan penyesuaian ulang ternyata pelanggan mengiginkan prototype aplikasi yang sebelumnya. Seandainya programmer masih menyimpan versi yang sebelumnya tentu saja persoalan semacam ini bukan menjadi suatu masalah dan sebagai programmer yang baik seharusnya memang memiliki source code program yang dibuatnya dari awal hingga akhir beserta dengan dokumentasinya. Dengan CVS, kita dapat mengambil kembali versi sebelumnya dari aplikasi yang sudah kita buat. Dengan CVS kita dapat pula menyimpan semua versi dari tiap file yang kita buat. CVS juga sangat bermanfaat jika adalah anggota sekelompok orang yang bekerja pada proyek yang sama. Dengan proyek yang dikerjakan oleh banyak orang, maka kemungkinan terjadi konflik pada file file source code sangat besar. CVS mengatasi masalah ini dengan cara membatasi para pengembang satu sama lain. Setiap pengembang bekerja di direktorinya masing masing. Fitur CVS (Concurrent Version Sistem) a) Dengan CVS kita dapat kembali ke versi sebelumnya dari software anda b) Dengan CVS kita dapat pula menyimpan semua versi dari tiap file yang anda buat c) CVS juga bermanfaat jika anda adalah anggota sekelompok orang yang bekerja pada proyek yang sama. Dengan proyek yang dikerjakan oleh banyak orang, maka kemungkinan terjadinya konflik pada file-file source code sangat besar, misalnya satu orang merubah file yang telah dirubah oleh orang lainnya. CVS mengatasi masalah ini dengan cara meng-insulate para pengembang satu sama lain. Setiap pengembang bekerja di direktorinya, dan CVS menggabungkan pekerjaannya ketika mereka telah selesai.

38

REFERENSI
-http://dimasdisini.wordpress.com/2010/02/14/definisi-sistem-waktu-nyata/ -http://id.wikipedia.org/wiki/Waktu_nyata -http://danang.staff.ugm.ac.id/so/SistemOperasi.pdf -http://dwiishartono.wordpress.com/2008/09/17/real-time-systemrts/ -http://machine-vision-adhiguna.blogspot.com/2007/08/apakah-embedded-systemitu-embedded.html -http://iblogger.web.id/post/definisi-real-time/216/webq/ -http://aryoharrispana.wordpress.com/2012/02/07/real-time-metocean-monitoring-system/ -http://agfi.staff.ugm.ac.id/blog/index.php/2011/03/perancangan-aplikasi-realtime-bagian-1-pendahuluan/ -http://dienwalid.blogspot.com/2009/06/real-time-software.html -http://jevoentnakke.blogspot.com/2009/11/real-time-system.html -http://www.scribd.com/doc/23040505/Real-Time-System -http://www.google.co.id/url?sa=t&rct=j&q=bab%20iv%20penjadwalan%20proses &source=web&cd=3&ved=0CCwQFjAC&url=http%3A%2F %2Fyusufhdc.edublogs.org%2Ffiles%2F2010%2F01%2FBAB-IV-Penjadwalanproses.ppt&ei= RItLT4qgAYftrAe7keSmDw&usg=AFQjCNHkjfYY7fGogEfaZJP5BKUfwm4t6 -http://www.google.co.id/url?sa=t&rct=j&q=penjadwalan%20proses&source=web&cd =2&ved=0CC0QFjAB&url=http%3A%2F%2Frusdyana.files.wordpress.com %2F2009%2F11%2Fpenjadwalan-proses.ppt&ei=iotLT DkFMbIrQel16yOBQ&usg= AFQjCNF3VE0HQTt6eHMLl2xNSErcbPFtIA -http://www.stmik-im.ac.id/userfiles/file/bsswn10.pdf -http://oke.or.id/wp-content/plugins/downloads-manager/upload/Yamta~Real%20Time

39

%20OKE.pdf -http://rtscs4613.blog.ittelkom.ac.id/blog/files/2010/08/Pert-02-Ch01-KonsepRTS-20100824.pdf

40