ANALISA & PERANCANGAN SISTEM INFORMASI · berkaitan dengan Analisa & Perancangan Sistem Informasi...

Program Studi Sistem Informasi | DST@2020

ANALISA & PERANCANGAN SISTEM INFORMASI



KATA PENGANTAR Bismillaahirrahmaanirrahiim

Alhamdulillahirobbil‘alamiin serta Puji dan Syukur penulis panjatkan kehadirat Allah SWT atas segala Rahmat dan Ridho-Nya penulis dapat menyelesaikan Modul Pembelajaran mata kuliah Analisa & Perancangan Sistem Informasi ini sebagai salah satu bahan referensi untuk mendukung proses belajar mengajar mahasiswa.

Modul ini dirancang khusus untuk membantu mahasiswa memahami hal-hal yang berkaitan dengan Analisa & Perancangan Sistem Informasi yang merupakan salah satu mata kuliah wajib yang ada di Program Studi Sistem Informasi, Universitas Bina Sarana Informatika.

Tujuan penulis membuat modul pembelajaran ini dimaksudkan sebagai literatur teori dasar tentang Analisa & Perancangan Sistem Informasi. Isi modul ini disesuaikan dengan silabus mata kuliah untuk pembahasan dalam satu semester.

Dalam penulisan dan menyelesaikan Modul Pembelajaran ini, penulis banyak mendapat masukan dari berbagai pihak, dan secara khusus dalam kesempatan ini, dengan segala kerendahan dan keikhlasan hati penulis mengucapkan rasa hormat dan terima kasih yang sebesar-besarnya kepada : 1. Orang tua serta Saudara tercinta yang telah banyak memberikan bantuan dan

dorongan selama penulis menyelesaikan penulisan modul ini 2. Istri dan Anak-anak ku tercinta yang selalu memberikan dorongan dan motivasi bagi

penulis selama penyelesaian Modul ini. 3. Rekan-rekan dan Sahabat baik berada didalam maupun diluar lingkungan saya yang

telah memberi kritik, komentar maupun saran yang membangun untuk perbaikannya, penulis mengucapkan terima kasih. Saran dan kritik yang sangat membantu dan berguna adalah untuk penyelesaian isi dari modul ini.

Dengan izin dan ridho Allah SWT, semoga Modul Pembelajaran ini dapat memberikan manfaat khususnya bagi penulis pribadi dan dapat memberikan sumbangsih ilmu bagi mahasiswa dan orang lain yang membutuhkannya, dengan harapan akan semakin berkembang wawasan dan keberagaman ilmu khususnya di bidang Analisa & Perancangan Sistem Informasi. Semua yang baik sumbernya dari Sang Maha Ilmu, Allah SWT... Semua yang kurang baik sumbernya dari kealpaan dan kekhilafan hamba sebagai makhluk-Nya...

Pontianak, Maret 2020 Penulis

Dedi Saputra, S.Pd, M.Kom

ii



DAFTAR ISI

KATA PENGANTAR ............................................................................................ ii DAFTAR ISI .......................................................................................................... iii PENDAHULUAN .................................................................................................. 1 BAB I TERMINOLOGI SISTEM ........................................................................... 1

1.1 Terminologi Analisa Sistem Informasi ................................................... 1 1.2 Konsep Dasar Sistem ............................................................................... 3

A. Definisi Sistem ..................................................................................... 3 B. Karakteristik Sistem ............................................................................ 4 C. Klasifikasi Sistem ................................................................................ 6 D. Pengembangan Sistem ....................................................................... 7 E. Prinsip Pengembangan Sistem .......................................................... 9 F. Siklus Hidup Pengembangan Sistem ................................................. 10 G. Pendekatan Pengembangan Sistem .................................................. 13 H. Metodologi Pengembangan Sistem ................................................... 17 I. Tools Pengembangan Sistem ............................................................. 17 J. Fungsi Analisis Sistem ........................................................................ 19

BAB II METODE PENGEMBANGAN SISTEM .................................................... 22

2.1 Metode Pengembangan Sistem ............................................................... 22 A. Definisi .................................................................................................. 22 B. Jenis Metode Pengembangan Sistem ................................................ 22

2.2 Model Waterfall ......................................................................................... 24 2.3 Model Prototyping .................................................................................... 28 2.4 Model RAD (Rapid Application Development) ....................................... 29 2.5 Model Spiral .............................................................................................. 32 2.6 Model Iteratif ............................................................................................. 34 2.7 Object Oriented Technology .................................................................... 36 2.8 Metode End-User Devlopment ................................................................. 38

BAB III ANALISA SISTEM INFORMASI .............................................................. 39 3.1 Pendekatan Analisa Model Driven .......................................................... 39 3.2 Analisa Kebutuhan Sistem ...................................................................... 40 3.3 Metode Pengumpulan Data ..................................................................... 40 3.4 Perumusan Proses Bisnis ....................................................................... 43

BAB IV ENTITY RELATIONSHIP DIAGRAM (ERD), SPESIFIKASI FILE DAN

PENGKODEAN ................................................................................................ 45 4.1 Entity Relationship Diagram (ERD) ......................................................... 45 4.2 Spesifikasi File .......................................................................................... 52 4.3 Teknik Pengkodean .................................................................................. 53

BAB V UNIFIED MODELLING LANGUAGE (UML) ............................................ 56

5.1 Terminologi UML ...................................................................................... 56 5.2 Diagram Use Case .................................................................................... 58 5.3 Diagram Class ........................................................................................... 58

iii



5.4 Package dan Object.................................................................................. 60 5.5 Diagram Sequence ................................................................................... 61 5.6 Diagram Collaboration ............................................................................. 62 5.7 Diagram State Chart ................................................................................. 62 5.8 Diagram Activity ....................................................................................... 63 5.9 Diagram Component dan Deployment .................................................... 65

BAB VI ANALISA PERANCANGAN INPUT DAN OUTPUT ............................... 66

6.1 Perancangan Input ................................................................................... 66 6.2 Perancangan Output ................................................................................ 67

BAB VII PENGUJIAN PERANGKAT LUNAK ...................................................... 71

7.1 Pengujian Perangkat Lunak ..................................................................... 71 7.2 Pengujian Functional (Black Box) ........................................................... 74 7.3 Pengujian Structural (White Box) ............................................................ 75 7.4 Pengujian Basis Path ............................................................................... 75

Daftar Pustaka ..................................................................................................... 78

iv



PENDAHULUAN Mata kuliah Analisa & Perancangan Sistem Informasi ini memiliki bobot 4 SKS adalah salah satu Mata kuliah Wajib di Program Studi Sistem Informasi. KOMPETENSI : Setelah mengikuti mata kuliah ini, mahasiswa diharapkan akan terampil dalam: 1. Mengetahui dan memahami peranan konsep analisa sistem dan perancangan sistem

informasi 2. Mampu membuat dan menjelaskan konsep pengembangan system. 3. Mampu menggambarkan system baik yang berjalan maupun usulan dengan

menggunakan diagram alir data dan mengaplikasikannya dalam bentuk kamus data serta merancang dokumen masukan maupun keluaran.

4. Mahasiswa mampu membuat presentasi yang menarik dan atraktif. 5. Mahasiswa mampu bekerja sama dalam kelompok kerja untuk menyelesaikan

makalah tugas ujian akhir semester (UAS). 6. Membuat presentasi dan memaparkan hasil riset di depan kelas kepada dosen

pengajar dengan sistematika yang baik dan tepat.

DESKRIPSI MATA KULIAH : Matakuliah ini membahas materi tentang analisa system dan teknik merancang pada sistem yang sudah terkomputerisasi maupun yang masih manual sehingga mampu menggambarkan sistem secara konsep dan membuat analisa dalam bentuk makalah secara berkelompok serta mampu mempresentasikan hasil analisa tersebut di kelas. TUJUAN UMUM : 1. Mahasiswa mampu membuat makalah tentang sistem informasi manajemen pada

sebuah Organisasi. 2. Mahasiswa mampu mengaplikasikan satu model pengembangan system. 3. Mahasiswa mampu menggambarkan satu prosedur kemudian membuat gambar DFD

dan membuat rancangan input dan output baik internal maupun eksternal pada sebuah organisasi, membuat kamus data untuk masing-masing dokumen dari dokumen yang sudah di riset dan membuat contoh HIPo dan program flowchart dari DAD usulan

BAB I TERMINOLOGI SISTEM

1.1 Terminologi Analisa Sistem Informasi

Analisa berasal dari kata Yunani Kuno “analusis” yang berarti melepaskan. Analusis terbentuk dari dua suku kata yaitu “ana” yang berarti kembali dan “luein” yang berarti melepas. Sehingga pengertian analisa yaitu suatu usaha dalam mengamati secara detail pada suatu hal atau benda dengan cara menguraikan komponen-komponen pembentuknya atau menyusun komponen tersebut untuk dikaji lebih lanjut. Kata analisa atau analisis banyak digunakan dalam berbagai bidang ilmu pengetahuan, baik ilmu bahasa, alam dan ilmu sosial. Untuk mengkaji suatu permasalahan, dikenal dengan suatu metode yang disebut dengan metode ilmiah. Disimpulkan analisa adalah suatu kegiatan yang dimulai dari proses awal didalam mempelajari serta mengevaluasi suatu bentuk permasalahan (case) yang ada.

1



Pengertian Analisa Menurut Para Ahli

Menurut Gorys Keraf, analisa adalah sebuah proses untuk memecahkan sesuatu

ke dalam bagian-bagian yang saling berkaitan satu sama lainnya. sedangkan menurut

Komarrudin mengatakan bahwa analisis merupakan suatu kegiatan berfikir untuk

menguraikan suatu keseluruhan menjadi komponen sehingga dapat mengenal tanda-

tanda dari setiap komponen, hubungan satu sama lain dan fungsi masing-masing dalam

suatu keseluruhan yang terpadu. Menurut kamus akuntansi yaitu bahwa analisa

merupakan sebuah kegiatan untuk evaluasi terhadap kondisi dari ayat-ayat yang berkaitan

dengan akuntansi dan alasan tentang perbedaan yang bisa muncul. Terakhir yaitu

menurut Robert J. Schreiter (1991) mengatakan analisa merupakan membaca teks,

dengan menempatkan tanda-tanda dalam interaksi yang dinamis dan pesan yang

disampaikan.

Dari beberapa pengertian analisa diatas dapat ditarik kesimpulan bahwa analisa

merupakan sekumpulan kegiatan, aktivitas dan proses yang saling berkaitan untuk

memecahkan masalah atau memecahkan komponen menjadi lebih detail dan

digabungkan kembali lalu ditarik kesimpulan. Bentuk dari kegiatan analisa salah satunya

yaitu merangkum data mentah menjadi sebuah informasi yang bisa disampaikan ke

khalayak. Segala macam bentuk analisis menggambarkan pola-pola yang konsisten di

dalam data, sehingga hasil analisa dapat dipelajari dan diterjemahkan dengan singkat dan

penuh makna. Analisa juga dapat diartikan sebagai sebuah penyelidikan terhadap suatu

peristiwa dengan tujuan mengetahui keadaan yang sebenarnya terjadi.

Belajar dari Para ahli yang telah mendefinisikan pengertian analisa maka sebuah

analisis data, proses dan hasil dari analisa biasanya dilakukan meliputi kegiatan seperti

mengorganisasikan data, mengelompokkan data, mengklasifikasi data, memaparkan data

dan menarik kesimpulan dari keseluruhan data tersebut. Mengorganisasikan data yaitu

berarti mengatur data-data yang telah diperoleh peneliti selama kegiatan penelitian

sedang berlangsung, sedangkan pengelompokan data yaitu mengelompokkan data mana

yang hendak dipakai dan data mana yang tidak dipakai. Mengklasifikasi data juga

mengelas-ngelaskan data sesuai kebutuhan. Memaparkan data yaitu menyampaikan hasil

proses analisis data dan menarik kesimpulan atas informasi dari data yang telah

disampaikan.

Sistem : hubungan satu unit dengan unit-unit lainnyayang saling berhubungan satu sama lainnya dan yang tidak dapat dipisahkan serta menuju suatu kesatuan dalam rangka mencapai tujuan yang telah ditetapkan Chr. Jimmy L. Gaol (2008:9).

Informasi : data yang telah diklasifikasikan atau diolah atau di interpretasikan

untuk digunakan dalam proses pengambilan keputusan (Sutabri, 2012:22).

Analisis Sistem : Penguraian dari suatu sistem informasi yang utuh ke dalam bagian-

bagian komponennya dengan maksud untuk mengidentifikasikan dan mengevaluasi permasalahan, kesempatan, hambatan yang terjadi dan kebutuhan yang diharapkan sehingga dapat diusulkan perbaikan.

2



Tahap analisis dilakukan setelah tahap perencanaan sistem dan sebelum tahap desain sistem. Tahap ini merupakan tahap yang kritis dan sangat penting, karena kesalahan dalam tahap ini menyebabkan kesalahan pada tahap selanjutnya. Contoh : Misalkan anda dihadapkan pada suatu sistem untuk menentukan seberapa jauh sistem tersebut telah mencapai sasarannya. Jika sistem mempunyai beberapa kelemahan, anda harus dapat menemukannya. Tugas ini yang disebut sebagai analisis sistem. Tugas utama dari menganalisis sistem meliputi :

1. Menentukan lingkup sistem 2. Mengumpulkan fakta 3. Menganalisis fakta 4. Mengkomunikasikan temuan-temuan tersebut melalui laporan analisis sistem.

1.2 Konsep Dasar Sistem A. Definisi Sistem

Sistem berasal dari bahasa Latin (systema) dan bahasa Yunani (sustema) adalah suatu kesatuan yang terdiri komponen atau elemen yang dihubungkan bersama untuk memudahkan aliran informasi, materi atau energi. Istilah ini sering dipergunakan untuk menggambarkan suatu entitas yang berinteraksi.

Sistem juga merupakan kesatuan bagian-bagian yang saling berhubungan yang berada dalam suatu wilayah serta memiliki item-item penggerak, contoh umum misalnya seperti negara. Negara merupakan suatu kumpulan dari beberapa elemen kesatuan lain seperti provinsi yang saling berhubungan sehingga membentuk suatu negara dimana yang berperan sebagai penggeraknya yaitu rakyat yang berada dinegara tersebut. Kata "sistem" banyak sekali digunakan dalam percakapan sehari-hari, dalam forum diskusi maupun dokumen ilmiah. Kata ini digunakan untuk banyak hal, dan pada banyak bidang pula, sehingga maknanya menjadi beragam. Dalam pengertian umum menurut beberapa ahli bahwa definisi sistem adalah merupakan sekelompok elemen yang terintegrasi dan bekerja sama untuk mencapai suatu tujuan. Jadi yang dimaksud dengan sistem bisa berbentuk apa saja dan berada dimana saja. Sistem adalah kumpulan / group / komponen apapun baik phisik yang saling berhubungan satu sama lain dan bekerja sama secara harmonis untuk mencapai satu tujuan tertentu.

Terdapat dua kelompok pendekatan didalam mendefinisikan sistem, yaitu yang menekankan pada prosedurnya dan yang menekankan pada komponen atau elemennya. Pendekatan sistem yang lebih menekankan pada prosedur mendefinisikan sistem sebagai berikut ini : “Suatu sistem adalah suatu jaringan kerja dari prosedur-prosedur yang saling berhubungan, berkumpul bersama-sama untuk melakukan suatu kegiatan atau untuk menyelesaikan suatu sasaran yang tertentu.”

Menurut Jerry Fitzgerald, Ardra F. Fitzgerald dan Warren D. Stallings, Jr., mendefinisikan prosedur sebagai berikut : Suatu prosedur adalah urut-urutan yang tepat dari tahapan-tahapan instruksi yang menerangkan Apa (What) yang harus dikerjakan, Siapa (Who) yang mengerjakannya, Kapan (When) dikerjakan dan Bagaimana (How) mengerjakannya.

Pendekatan sistem yang lebih menekankan pada elemen atau komponennya mendefiniskan sistem sebagai berikut ini : “Sistem adalah kumpulan dari elemen-elemen yang berinteraksi untuk mencapai suatu tujuan tertentu.”

Kedua kelompok definisi tersebut adalah benar dan tidak bertentangan, yang berbeda adalah cara pendekatannya. Pendekatan sistem yang merupakan kumpulan elemen-elemen atau komponen-komponen atau subsistem-subsistem merupakan definisi yang lebih luas. Definisi ini lebih banyak diterima, karena kenyataannya suatu sistem

3



dapat terdiri dari beberapa subsistem atau sistem bagian. Sebagai misal, sistem akuntansi dapat terdiri dari beberapa subsistem-subsistem, yaitu subsistem akuntansi penjualan, subsistem akuntansi pembelian, subsistem akuntansi penggajian, subsistem akuntansi biaya dan lain sebagainya.

Apa itu Subsistem ? Subsistem sebenarnya hanyalah sistem di dalam suatu sistem, ini berarti bahwa sistem berada pada lebih dari satu tingkat. Pemisalan lainnya, mobil adalah suatu sistem yang terdiri dari sistem-sistem bawahan seperti sistem mesin, sistem badan mobil dan sistem rangka. Masing-masing sistem ini terdiri dari sistem tingkat yang lebih rendah lagi. Misalnya, sistem mesin adalah kombinasi dari sistem karburator, sistem generator, sistem bahan bakar dan seterusnya.

Apa itu Supersistem ? Walaupun istilah supersistem jarang digunakan, sistem seperti ini ada. Jika suatu sistem adalah bagian dari sistem yang lebih besar, sistem yang lebih besar itu adalah supersistem. Contohnya, pemerintahan kota adalah suatu sistem, tetapi ia juga merupakan bagian dari sistem yang lebih besar – pemerintahan propinsi. Pemerintahan propinsi adalah supersistem dari pemerintahan kota dan juga merupakan subsistem dari pemerintahan nasional. Dari definisi dan penjelasan diatas dapatlah diambil kesimpulan, suatu sistem terdiri dari elemen yang bisa berbentuk individu atau bagian-bagian yang terpisah, kemudian berinteraksi satu sama lain untuk mencapai tujuan. Mobil terdiri dari bagian-bagian sistem yang berinteraksi/kerjasama untuk tujuan mobil tersebut bergerak ke suatu arah. Keluarga, pertama kali terdiri dari 2 individu yang terpisah yang mana individu itu sendiri merupakan suatu sistem yang terdiri dari subsistem-subsistem, kemudian bersatu membentuk keluarga untuk mencapai suatu tujuan. Keluarga itu sendiri merupakan subsistem dari sistem Rukun Tetangga (RT), RT merupakan subsistem dari Rukun Warga (RW), RW subsistem dari suatu Kelurahan, Kelurahan subsistem dari suatu Kecamatan, dan demikian seterusnya.

B. Karateristik Sistem

Suatu sistem mempunyai karakteristik atau sifat-sifat tertentu, yaitu mempunyai komponen-komponen, batas sistem, lingkungan luar sistem, penghubung, masukkan (input), keluaran (output), pengolahan(prosessing) dan sasaran(objectiv) atau tujuan(goal). Gambaran dari karakteristik sistem dapat dilihat pada gambar berikut ini:

Gambar 1. Karakteristik suatu sistem

4



1. Komponen Sistem Suatu sistem terdiri dari sejumlah komponen yang saling berinteraksi, yang artinya saling bekerja sama membentuk satu kesatuan. Komponen-komponen sistem atau elemen-elemen sistem dapat berupa suatu subsistem atau bagian-bagian dari sistem. Setiap sistem tidak perduli betapapun kecilnya, selalu mengandung komponen-komponen atau subsistem-subsistem. Setiap subsistem mempunyai sifatsifat dari sistem untuk menjalankan suatu fungsi tertentu dan mempengaruhi proses sistem secara keseluruhan. Jadi, dapat dibayangkan jika dalam suatu sistem ada subsistem yang tidak berjalan/berfungsi sebagaimana mestinya. Tentunya sistem tersebut tidak akan berjalan mulus atau mungkin juga sistem tersebut rusak sehingga dengan sendirinya tujuan sistem tersebut tidak tercapai 2. Batas Sistem (Boundary) Batas sistem (boundary) merupakan daerah yang membatasi antara suatu sistem dengan sistem yang lainnya atau dengan lingkungan luarnya. Batas sistem ini memungkinkan suatu sistem dipandang sebagai satu kesatuan. Batas suatu sistem menunjukkan ruang lingkup (scope) dari sistem tersebut. 3. Lingkungan Luar Sistem (Environments) Lingkungan luar dari suatu sistem adalah apapun diluar batas dari sistem yang mempengaruhi operasi sistem. Lingkungan luar sistem dapat bersifat menguntungkan dan dapat juga bersifat merugikan sistem tersebut. Lingkungan luar yang menguntungkan merupakan energi dari sistem dan dengan demikian harus tetap dijaga dan dipelihara. Sedang lingkungan luar yang merugikan harus ditahan dan dikendalikan, kalau tidak maka akan menggangu kelangsungan hidup dari sistem. 4. Penghubung (Interface) Sistem Penghubung sistem merupakan media penghubung antara satu subsistem dengan subsistem lainnya. Melalui penghubung ini memungkinkan sumber-sumber daya mengalir dari satu subsistem ke yang lainnya. Keluaran (output) dari satu subsistem akan menjadi masukan (input) untuk subsistem lainnya dengan melalui penghubung. Dengan penghubung satu subsistem dapat berintegrasi dengan subsistem yang lainnya membentuk satu kesatuan. 5. Masukan (Input) Sistem Masukan sistem adalah energi yang dimasukkan ke dalam sistem. Masukan dapat berupa masukan perawatan (maintenance input) dan masukan sinyal (signal input). Maintenance input adalah energi yang dimasukkan supaya sistem tersebut dapat beroperasi. Signal input adalah energi yang diproses untuk didapatkan keluaran. Sebagai contoh didalam sistem komputer, program adalah maintenance input yang digunakan untuk mengoperasikan komputernya dan data adalah signal input untuk diolah menjadi informasi. 6. Keluaran (Output) Sistem Keluaran sistem adalah hasil dari energi yang diolah dan diklasifikasikan menjadi keluaran yang berguna dan sisa pembuangan. Keluaran dapat merupakan masukan untuk subsistem yang lain atau kepada supersistem. Misalnya untuk sistem komputer, panas yang dihasilkan adalah keluaran yang tidak berguna dan merupakan hasil sisa pembuangan, sedang informasi adalah keluaran yang dibutuhkan.

5



7. Pengolah (Process) Sistem Suatu sistem dapat mempunyai suatu bagian pengolah yang akan merubah masukan menjadi keluaran. Suatu sistem produksi akan mengolah masukan berupa bahan baku dan bahan-bahan yang lain menjadi keluaran berupa barang jadi. Sistem akuntansi akan mengolah data-data transaksi menjadi laporan-laporan keuangan dan laporan-laporan lain yang dibutuhkan oleh manajemen. 8. Sasaran (Objectives) atau Tujuan (Goal) Suatu sistem pasti mempunyai tujuan atau sasaran. Kalau suatu sistem tidak mempnyai sasaran, maka operasi sistem tidak akan ada gunanya. Sasaran dari sistem sangat menentukan sekali masukan yang dibutuhkan sistem dan keluaran yang akan dihasilkan sistem. Suatu sistem dikatakan berhasil bila mengenai sasaran atau tujuannya. Perbedaan suatu sasaran (objectives) dan suatu tujuan (goal) adalah, goal biasanya dihubungkan dengan ruang lingkup yang lebih luas dan sasaran dalam ruang lingkup yang lebih sempit. Bila merupakan suatu sistem utama, seperti misalnya sistem bisnis perusahaan, maka istilah goal lebih tepat diterapkan. Untuk sistem akuntansi atau sistem-sistem lainnya yang merupakan bagian atau subsistem dari sistem bisnis, maka istilah objectives yang lebih tepat. Jadi tergantung dari ruang lingkup mana memandang sistem tersebut. Seringkali tujuan (goal) dan sasaran (objectives) digunakan bergantian dan tidak dibedakan C. Klasifikasi Sistem

Sistem dapat diklasifikasikan dari beberapa sudut pandang, diantaranya sebagai berikut ini :

1. Sistem diklasifikasikan sebagai sistem abstrak (abstract system) dan sistem fisik (physical system). Sistem abstrak adalah sistem yang berupa pemikiran atau ide-ide yang tidak tampak secara fisik. Misalnya sistem teologia, yaitu sistem yang berupa pemikiran-pemikiran hubungan antara manusia dengan Tuhan. Sistem fisik merupakan sistem yang ada secara fisik. Misalnya sistem komputer, sistem akuntansi, sistem produksi dan lain sebagainya.

2. Sistem diklasifikasikan sebagai sistem alamiah (natural system) dan sistem buatan manusia (human made system) Sistem alamiah adalah sistem yang terjadi melalui proses alam, tidak dibuat manusia. Misalnya sistem perputaran bumi. Sistem buatan manusia adalah sistem yang dirancang oleh manusia. Sistem buatan manusia yang melibatkan interaksi antara manusia dengan mesin disebut dengan human-machine system atau ada yang menyebut dengan man-machine system. Sistem informasi merupakan contoh man-machine system, karena menyangkut penggunaan komputer yang berinteraksi dengan manusia.

3. Sistem diklasifikasikan sebagai sistem tertentu (deterministic system) dan sistem tak tentu (probabilistic system) Sistem tertentu beroperasi dengan tingkah laku yang sudah dapat diprediksi. Interaksi diantara bagian-bagiannya dapat dideteksi dengan pasti, sehingga keluaran dari sistem dapat diramalkan. Sistem komputer adalah contoh dari sistem tertentu yang tingkah lakunya dapat dipastikan berdasarkan programprogram yang dijalankan. Sistem tak tentu adalah sistem yang kondisi masa depannya tidak dapat diprediksi karena mengandung unsur probabilitas.

4. Sistem diklasifikasikan sebagai sistem tertutup (closed system) dan sistem terbuka (open system) Sistem tertutup merupakan sistem yang tidak berhubungan dan tidak terpengaruh dengan lingkungan luarnya. Sistem ini bekerja secara otomatis tanpa

6



adanya turut campur tangan dari pihak diluarnya. Secara teoritis sistem tertutup ini ada, tetapi kenyataannya tidak ada sistem yang benar-benar tertutup, yang ada hanyalah relatively closed system (secara relatif tertutup, tidak benar-benar tertutup). Sistem terbuka adalah sistem yang berhubungan dan terpengaruh dengan lingkungan luarnya. Sistem ini menerima masukan dan menghasilkan keluaran untuk lingkungan luar atau subsistem yang lainnya. Karena sistem sifatnya terbuka dan terpengaruh oleh lingkungan luarnya, maka suatu sistem harus mempunyai suatu sistem pengendalian yang baik. Sistem yang baik harus dirancang sedemikian rupa, sehingga secara relatif tertutup karena sistem tertutup akan bekerja secara otomatis dan terbuka hanya untuk pengaruh yang baik saja. Klasifikasi sistem terbuka dan tertutup dapat digambarkan sebagai berikut :

Gambar 2. Sistem Terbuka

Gambar 3. Sistem Tertutup

Suatu sistem yang dihubungkan dengan lingkungannya melalui arus sumber daya disebut sistem terbuka. Sebuah sistem pemanas atau pendingin ruangan, contohnya, mendapatkan input-nya dari perusahaan listrik, dan menyediakan panas/dinginnya bagi ruangan yang ditempatinya. Dengan menggunakan logika yang sama, suatu sistem yang tidak dihubungkan dengan lingkungannya adalah sistem tertutup. Sebagai contohnya, sistem tertutup hanya terdapat pada situasi laboratorium yang dikontrol ketat. D. Pengembangan Sistem

Pengembangan sistem (systems development) dapat berarti menyusun suatu sistem yang baru untuk menggantikan sistem yang lama secara keseluruhan atau memperbaiki sistem yang telah ada. Sistem yang lama perlu diperbaiki atau diganti disebabkan karena beberapa hal, yaitu sebagai berikut ini: a. Adanya permasalahan-permasalahan (problems) yang timbul di sistem yang lama

yang dapat berupa ketidakberesan. Ketidakberesan dalam sistem yang lama menyebabkan sistem yang lama tidak dapat beroperasi sesuai dengan yang diharapkan. Ketidakberesan ini dapat berupa :

▪ kecurangan-kecurangan disengaja yang menyebabkan tidak amannya harta kekayaan perusahaan dan kebenaran dari data menjadi kurang terjamin;

7



▪ kesalahan-kesalahan yang tidak disengaja yang juga dapat menyebabkan kebenaran dari data kurang terjamin;

▪ tidak efisiennya operasi; ▪ tidak ditaatinya kebijaksanaan manajemen yang telah ditetapkan.

Pertumbuhan organisasi Pertumbuhan organisasi yang menyebabkan harus disusunnya sistem yang baru. Pertumbuhan organisasi diantaranya adalah kebutuhan informasi yang semakin luas, volume pengolahan data semakin meningkat, perubahan prinsip akuntansi yang baru. Karena adanya perubahan ini, maka menyebabkan sistem yang lama tidak efektif lagi, sehingga sistem yang lama sudah tidak dapat memenuhi lagi semua kebutuhan informasi yang dibutuhkan manajemen.

b. Untuk meraih kesempatan-kesempatan (opportunities) Teknologi informasi telah berkembang dengan cepatnya. Perangkat keras komputer, perangkat lunak dan teknologi komunikasi telah begitu cepat berkembang. Organisasi mulai merasakan bahwa teknologi informasi ini perludigunakan untuk meningkatkan penyediaan informasi sehingga dapat mendukung dalam proses pengambilan keputusan yang akan dilakukan oleh manajemen. Dalam keadaaan pasar bersaing, kecepatan informasi atau efisiensi waktu sangat menentukan berhasil atau tidaknya strategi dan rencana-rencana yang telah disusun untuk meraih kesempatan-kesempatan yang ada. Bila pesaing dapat memanfaatkan teknologi ini, maka kesempatan-kesempatan akan jatuh ke tangan pesaing. Kesempatan-kesempatan ini dapat berupa peluang-peluang pasar, pelayanan yang meningkat kepada langganan dan lain sebagainya.

c. Adanya instruksi-instruksi (directives) Penyusunan sistem yang baru dapat juga terjadi karena adanya instruksi-instruksi dari atas pimpinan ataupun dari luar organisasi, seperti misalnya peraturan pemerintah. Berikut ini dapat digunakan sebagai indikator adanya permasalahanpermasalahan dan kesempatan-kesempatan yang dapat diraih, sehingga menyebabkan sistem yang lama harus diperbaiki, ditingkatkan bahkan diganti keseluruhannya. Indikator-indikator ini diantaranya adalah sebagai berikut : keluhan dari langganan; pengiriman barang yang sering tertunda; pembayaran gaji yang terlambat; laporan yang tidak tepat waktunya; isi laporan yang sering salah; tanggung jawab yang tidak jelas; waktu kerja yang berlebihan; ketidakberesan kas; produktifitas tenaga kerja yang rendah; banyaknya pekerja yang menganggur; kegiatan yang tumpang tindih; tanggapan yang lambat terhadap langganan; kehilangan kesempatan kompetisi pasar; kesalahan-kesalahan manual yang tinggi; persediaan barang yang terlalu tinggi; pemesanan kembali barang yang tidak efisien; biaya operasi yang tinggi; file-file yang kurang teratur; keluhan dari supplier karena tertundanya pembayaran; bertumpuknya back-order (tertundanya pengiriman karena kurangnya persediaan barang); investasi yang tidak efisisen; peramalan penjualan dan produksi tidak tepat; kapasitas produksi yang menganggur (idle capasities); pekerjaan manajer yang terlalu teknis; dll.

Proses pengembangan sistem dapat digambarkan sebagai berikut :

8



Gambar 4. Proses Pengembangan Sistem

Dengan telah dikembangkannya sistem yang baru, maka diharapkan akan terjadi peningkatan-peningkatan di sistem yang baru. Peningkatan-peningkatan ini berhubungan dengan Performance, Information, Economy, Control, Efficiency, and Service (PIECES). ▪ Performance (kinerja), peningkatan terhadap kinerja (hasil kerja) sistem yang baru

sehingga menjadi lebih efektif. Kinerja dapat diukur dari throughput dan response time. Throughput adalah jumlah dari pekerjaan yang dapat dilakukan suatu saat tertentu. Response time adalah rata-rata waktu yang tertunda diantara dua transaksi atau pekerjaan ditambah dengan waktu response untuk menanggapi pekerjaan tersebut.

▪ Information (informasi), peningkatan terhadap kualitas informasi yang disajikan. ▪ Economy (ekonomis), peningkatan terhadap manfaat-manfaat atau

keuntungankeuntungan atau penurunan-penurunan biaya yang terjadi. ▪ Control (pengendalian), peningkatan terhadap pengendalian untuk mendeteksi dan

memperbaiki kesalahan-kesalahan serta kecurangan-kecurangan yang dan akan terjadi.

▪ Efficiency (efisiensi), peningkatan terhadap efisiensi operasi. Efisiensi berbeda dengan ekonomis. Bila ekonomis berhubungan dengan jumlah sumber daya yang digunakan, efisiensi berhubungan dengan bagaimana sumber daya tersebut digunakan dengan pemborosan yang paling minimum. Efisiensi dapat diukur dari outputnya dibagi dengan inputnya.

▪ Services (pelayanan), peningkatan terhadap pelayanan yang diberikan oleh sistem. E. Prinsip Pengembangan Sistem

1. Sistem yang dikembangkan adalah untuk manajemen 2. Sistem yang dikembangkan adalah investasi modal yang besar a. Semua alternatif

yang ada harus diinvestigasi b. Investasi yang terbaik harus bernilai 3. Sistem yang dikembangkan memerlukan orang yang terdidik 4. Tahapan kerja dan tugas-tugas yang harus dilakukan dalam proses pengembangan

sistem 5. Proses pengembangan sistem tidak harus urut 6. Jangan takut membatalkan proyek 7. Dokumentasi harus ada untuk pedoman dalam pengembangan sistem

9



F. Siklus Hidup Pengembangan Sistem Pengembangan sistem informasi yang berbasis komputer dapat merupakan tugas

kompleks yang membutuhkan banyak sumber daya dan dapat memakan waktu berbulan-bulan bahkan bertahun-tahun untuk menyelesaikannya. Proses pengembangan sistem melewati beberapa tahapan dari mulai sistem itu direncanakan sampai dengan sistem tersebut diterapkan, dioperasikan dan dipelihara. Bila operasi sistem yang sudah dikembangkan masih timbul kembali permasalahan-permasalahan yang kritis serta tidak dapat diatasi dalam tahap pemeliharaan sistem, maka perlu dikembangkan kembali suatu sistem untuk mengatasinya dan proses ini kembali ke tahap yang pertama, yaitu tahap perencanaan sistem. Siklus ini disebut dengan siklus hidup suatu sistem (systems life cycle). Daur atau siklus hidup dari pengembangan sistem merupakan suatu bentuk yang digunakan untuk menggambarkan tahapan utama dan langkah-langkah di dalam tahapan tersebut dalam proses pengembangannya. Dari sekian banyak siklus pengembangan sistem menurut beberapa penulis sejak tahun 1970-an, diambil salah satu yang akan menjadi acuan kita mengenai pengembangan sistem ini, yaitu menurut John Burch, Gary Grudnitski, Information Systems, Theory and Practice (New York: John Wiley & Sons) yang menuliskan tahapan pengembangan sistem sebagai berikut :

1. Kebijakan dan perencanaan sistem (system policy and planning). 2. Pengembangan sistem (system development)

a. Analisis sistem (system analysis) b. Desain sistem secara umum (general system design) c. Penilaian sistem (system evaluation) d. Desain sistem terinci (detailed system design) e. Implementasi sistem (system implementation)

3. Manajemen sistem dan operasi (system management and operation)

Gambar 5. Tahapan Pengembangan Sistem

1. Kebijakan dan perencanaan sistem (system policy and planning).

Sebelum suatu sistem informasi dikembangkan, umumnya terlebih dahulu dimulai dengan adanya suatu kebijakan dan perencanaan untuk mengembangkan sistem itu.

10



Tanpa adanya perencanaan sistem yang baik, pengembangan sistem tidak akan dapat berjalan sesuai dengan yang diharapkan. Tanpa adanya kebijakan pengembangan sistem oleh manajemen puncak (top management), makapengembangan sistem tidak akan mendapat dukungan dari manajemen puncak ini. Padahal dukungan dari manajemen puncak sangat penting artinya. Kebijakan sistem (systems policy) merupakan landasan dan dukungan dari manajemen puncak untuk membuat perencanaan sistem. Perencanaan sistem (systems planning) merupakan pedoman untuk melakukan pengembangan sistem. Kebijakan untuk mengembangkan sistem informasi dilakukan oleh manajemen puncak karena manajemen menginginkan untuk meraih kesempatan-kesempatan yang ada yang tidak dapat diraih oleh sistem yang lama atau sistem yang lama mempunyai banyak kelemahan-kelemahan yang perlu diperbaiki (misalnya untuk meningkatkan efektifitas manajemen, meningkatkan produktivitas atau meningkatkan pelayanan yang lebih baik kepada langganan). Partisipasi dan keterlibatan manajemen puncak masih diharapkan untuk keberhasilan sistem yang akan dikembangkan. Untuk itu manajemen puncak dilengkapi dengan suatu tim penasehat yang disebut dengan komite pengarah (steering commitee) yang umumnya dibentuk dari wakil-wakil pimpinan dari masing-masing departemen pemakai sistem seperti misalnya manajer-manajer departemen atau manajer-manajer divisi. Seringkali komite ini diketuai sendiri oleh direktur utama. Tugas komite ini adalah sebagai berikut : a. Mengkaji, menyetujui atau membuat rekomendasi yang berhubungan dengan

perencanaan sistem, proyek-proyek sistem serta pengadaan perangkat keras, perangkat lunak dan fasilitas-fasilitas lainnya.

b. Mengkoordinasi pelaksanaan proyek sistem sesuai dengan rencananya. c. Memonitor atau mengawasi kemajuan dari proyek sistem. d. Menilai kinerja dari fungsi-fungsi sistem yang telah dikembangkan. e. Memberikan saran-saran dan petunjuk-petunjuk terhadap proyek sistem yang

sedang dikembangkan, terutama yang berhubungan dengan pencapaian sasaran sistem, sasaran perusahaan dan juga terhadap kendala-kendala yang dihadapi. Setelah manajemen puncak menetapkan kebijakan untuk mengembangkan sistem informasi, sebelum sistem ini sendiri dikembangkan, maka perlu direncanakan terlebih dahulu dengan cermat. Perencanaan sistem (systems planning) ini menyangkut estimasi dari kebutuhan-kebutuhan fisik, tenaga kerja dan dana yang dibutuhkan untuk mendukung pengembangan sistem ini serta untuk mendukung operasinya setelah diterapkan. Perencanaan sistem dapat terdiri dari perencanaan jangka pendek (short-range) dan perencanaan jangka panjang (long-range). Perencanaan jangka pendek meliputi periode 1 sampai 2 tahun. Perencanaan jangka panjang melingkupi periode sampai dengan 5 tahun. Karena perkembangan teknologi komputer yang sangat cepat, maka perencanaan pengembangan sistem informasi untuk periode yang lebih dari 5 tahun sudah tidak tepat lagi.

Proses perencanaan sistem dikelompokkan menjadi 3 proses utama, yaitu : 1. Merencanakan proyek-proyek sistem yang akan dilakukan oleh staf perencana sistem. 2. Menentukan proyek-proyek sistem yang akan dikembangkan yang dilakukan oleh

komite. 3. Mendefinisikan proyek-proyek sistem dikembangkan yang dilakukan oleh analis

sistem.

11



Tahapan dari proses perencanaan sistem untuk ketiga bagian tersebut dapat dilihat pada gambar berikut ini :

Gambar 6. Tahapan Perencanaan Sistem

2. Pengembangan sistem (system development) a. Analisis sistem (system analysis)

Penelitian atas sistem yang telah ada dengan tujuan untuk merancang sistem yang baru atau diperbarui.

b. Desain sistem secara umum (general system design) Tujuan dari desain sistem secara umum adalah untuk memberikan gambaran secara umum kepada user tentang sistem yang baru.

c. Penilaian sistem (system evaluation) Hasil desain sistem secara umum tentunya harus menjadi pertimbangan pihak manajemen apakah melanjutkan pengembangan sistem yang baru berdasarkan gambaran desain sistem secara umum atau menolak rancangan baru tersebut.

d. Desain sistem terinci (detailed system design) Dengan memahami sistem yang ada dan persyaratan-persyaratan sistem baru, selanjutnya adalah penentuan proses dan data yang diperlukan oleh sistem baru. Jika sistem itu berbasis komputer, rancangan harus menyertakan spesifikasi jenis peralatan yang akan digunakan.

e. Implementasi sistem (system implementation) Merupakan kegiatan memperoleh dan mengintegrasikan sumber daya fisik dan konseptual yang menghasilkan suatu sistem yang bekerja.

3. Manajemen sistem dan operasi (system management and operation) Pemeliharaan sistem (systems maintenance ) dilaksanakan untuk 3 alasan : a. Memperbaiki kesalahan Penggunaan sistem mengungkapkan kesalahan (bugs)

dalam program atau kelemahan rancangan yang tidak terdeteksi dalam pengujian sistem. Kesalahan-kesalahan ini dapat diperbaiki.

12



b. Menjaga kemutakhiran sistem Dengan berlalunya waktu, terjadi perubahan-perubahan dalam lingkungan sistem yang mengharuskan modifikasi dalam rancangan atau perangkat lunak. Contohnya, pemerintah mengubah rumus perhitungan pajak jaminan sosial.

c. Meningkatkan sistem Saat sistem digunakan, akan ditemukan cara-cara membuat peningkatan sistem. Saran-saran ini diteruskan kepada spesialis informasi yang memodifikasi sistem sesuai saran tersebut. Pada titik tertentu, modifikasi sistem akan menajdi sedemikian rupa, sehingga lebih baik memulai dari awal. Lalu, siklus hidup sistem akan terulang.

G. Pendekatan Pengembangan Sistem

Terdapat beberapa pendekatan untuk mengembangkan sistem, yaitu sebagai berikut ini :

1. Pendekatan klasik lawan pendekatan terstruktur (dipandang dari metodologi yang digunakan) Metodologi pendekatan klasik mengembangkan sistem dengan mengikuti tahapan-tahapan di systems life cycle. Pendekatan ini menekankan bahwa pengembangan sistem akan berhasil bila mengikuti tahapan di systems life cycle. Akan tetapi sayangnya, didalam praktek, hal ini tidaklah cukup, karena pendekatan ini tidak memberikan pedoman lebih lanjut tentang bagaimana melakukan tahapan-tahapan tersebut dengan terinci karena pendekatan ini tidak dibekali dengan alat-alat dan teknik-teknik yang memadai. Sedangkan pendekatan terstruktur yang baru muncul sekitar awal tahun 1970-an pada dasarnya mencoba menyediakan kepada analis sistem tambahan alat-alat dan teknik-teknik untuk mengembangkan sistem disamping tetap mengikuti ide dari systems life cycle. Karena sifat dari sistem informasi sekarang menjadi lebih kompleks, pendekatan klasik tidak cukup digunakan untuk mengembangkan suatu sistem informasi yang sukses dan akan menimbulkan beberapa permasalahan. Permasalahan-permasalahan yang dapat timbul di pendekatan klasik antara lain adalah sebagai berikut : a. Pengembangan perangkat lunak akan menjadi sulit Pendekatan klasik kurang

memberikan alat-alat dan teknik-teknik di dalam mengembangkan sistem dan sebagai akibatnya proses pengembangan perangkat lunak menjadi tidak terarah dan sulit untuk dikerjakan oleh pemrogram. Lain halnya dengan pendekatan terstruktur yang memberikan alat-alat seperti diagram arus data (data flow diagram), kamus data (data dictionary), tabel keputusan (decision table), diagram IPO dan bagan terstruktur (structured chart) dan lain sebagainya yang memungkinkan pengembangan perangkat lunak lebih terarah berdasarkan alat-alat dan teknik-teknik tersebut.

b. Biaya perawatan atau pemeliharaan sistem akan menjadi lebih mahal Biaya pengembangan sistem yang termahal adalah terletak di tahap perawatannya. Mahalnya biaya perawatan di pendekatan klasik ini disebabkan karena dokumentasi sistem yang dikembangkan kurang lengkap dan kurang terstruktur. Dokumentasi ini merupakan hasil dari alat-alat dan teknik-teknik yang digunakan. Karena pendekatan klasik kurang didukung dengan alat-alat dan teknik-teknik, maka dokumentasi menjadi tidak lengkap dan walaupun ada tetapi strukturnya kurang jelas, sehingga pada waktu pemeliharaan sistem menjadi kesulitan.

c. Kemungkinan kesalahan sistem besar Pendekatan klasik tidak menyediakan kepada analis sistem cara untuk melakukan pengetesan sistem, sehingga

13



kemungkinan kesalahan-kesalahan sistem akan menjadi lebih besar. Berbeda dengan pendekatan terstruktur yang pengembangan sistemnya dilakukan dalam bentuk modul-modul yang terstruktur. Modul-modul ini akan lebih mudah dites secara terpisah dan kemudian pengetesan dapat dilakukan pada integrasi semua modul untuk meyakinkan bahwa interaksi antar modul telah berfungsi semestinya. Pengetesan sistem sebelum diterapkan merupakan hal yang kritis karena koreksi kesalahan sistem setelah diterapkan akan mengakibatkan pengeluaran biaya yang lebih besar. Beberapa penelitian menunjukkan bahwa sistem yang tidak dites selama tahap pengembangannya merupakan sumber utama dari kesalahan-kesalahan sistem.

d. Keberhasilan sistem kurang terjamin Penekanan dari pendekatan klasik adalah kerja dari personil-personil pengembang sistem, bukan pada pemakai sistem, padahal sekarang sudah disadari bahwa dukungan dan pemahaman dari pemakai sistem terhadap sistem yang sedang dikembangkan merupakan hal yang vital untuk keberhasilan proyek pengembangan sistem pada akhirnya. Salah satu kontribusi utama pendekatan terstruktur adalah partisipasi dan dukungan dari pemakai sistem. Pendekatan klasik mengasumsikan bahwa analis sistem telah mengerti akan kebutuhan-kebutuhan pemakai sistem dengan jelas dan benar. Pengalaman telah menunjukkan bahwa di beberapa kasus, kebutuhan-kebutuhan pemakai sistem tidaklah selalu jelas dan benar menurut analis sistem. Pendekatan klasik kurang melibatkan pemakai sistem dalam pengembangan sistem, maka kebutuhan-kebutuhan pemakai sistem menjadi kurang sesuai dengan yang diinginkan dan sebagai akibatnya sistem yang diterapkan menjadi kurang berhasil.

e. Masalah dalam penerapan sistem Karena kurangnya keterlibatan pemakai sistem dalam tahapan pengembangan sistem, maka pemakai sistem hanya akan mengenal sistem yang baru pada tahap diterapkan saja. Sebagai akibatnya pemakai sistem akan menjadi kaget dan tidak terbiasa dengan sistem baru yang tiba-tiba dikenalkan. Sebagai akibat lebih lanjut, pemakai sistem akan menjadi frustasi karena tidak dapat mengoperasikan sistem dengan baik.

2. Pendekatan sepotong lawan pendekatan sistem (dipandang dari sasaran yang

akan dicapai) Pendekatan sepotong (piecemeal approach) merupakan pendekatan pengembangan sistem yang menekankan pada suatu kegiatan atau aplikasi tertentu saja. Pada pendekatan ini, kegiatan atau aplikasi yang dipilih, dikembangkan tanpa memperhatikan posisinya di sistem informasi atau tanpa memperhatikan sasaran keseluruhan dari organisasi. Pendekatan in hanya memperhatikan sasaran dari kegiatan atau aplikasi itu saja. Lain halnya dengan pendekatan sistem (systems approach) yang memperhatikan sistem informasi sebagai satu kesatuan terintegrasi untuk masing-masing kegiatan atau aplikasinya. Pendekatan sistem ini juga menekankan pada pencapaian sasaran keseluruhan dari organisasi, tidak hanya menekankan pada sasaran dari sistem informasi itu saja.

3. Pendekatan bawah-naik lawan pendekatan atas-turun (dipandang dari cara menentukan kebutuhan dari sistem) Pendekatan bawah naik (bottom-up approach) dimulai dari level bawah organisasi, yaitu level operasional dimana transaksi dilakukan. Pendekatan ini dimulai dari perumusan kebutuhan-kebutuhan untuk menangani transaksi dan naik ke level atas dengan merumuskan kebutuhan

14



informasi berdasarkan transaksi tersebut. Pendekatan ini juga merupakan ciri-ciri dari pendekatan klasik. Pendekatan bawah-naik bila digunakan pada tahap analisis sistem disebut juga dengan istilah data analysis, karena yang menjadi tekanan adalah data yang akan diolah terlebih dahulu, informasi yang akan dihasilkan menyusul mengikuti datanya. Pendekatan atas-turun (top-down approach) sebaliknya dimulai dari level atas organisasi, yaitu level perencanaan strategi. Pendekatan ini dimulai dengan mendefinisikan sasaran dan kebijaksanaan organisasi. Langkah selanjutnya dari pendekatan ini adalah dilakukannya analisis kebutuhan informasi. Setelah kebutuhan informasi ditentukan, maka proses turun ke pemrosesan transaksi, yaitu penentuan output, input, basis data, prosedur-prosedur operasi dan kontrol. Pendekatan ini juga merupakan ciri-ciri dari pendekatan terstruktur. Pendekatan atas-turun bila digunakan pada tahap analisis sistem disebut juga dengan istilah decision analysis, karena yang menjadi tekanan adalah informasi yang dibutuhkan untuk pengambilan keputusan oleh manajemen terlebih dahulu, kemudian data yang perlu diolah didefinisikan menyusul mengikuti informasi yang dibutuhkan.

4. Pendekatan sistem-menyeluruh lawan pendekatan moduler (dipandang dari cara mengembangkannya) Pendekatan sistem-menyeluruh (total-system approach) merupakan pendekatan yang mengembangkan sistem serentak secara menyeluruh. Pendekatan ini kurang mengena untuk sistem yang komplek, karena akan menjadi sulit untuk dikembangkan. Pendekatan ini juga merupakan ciri-ciri dari pendekatan klasik. Pendekatan moduler (modular approach) berusaha memecah sistem yang rumit menjadi beberapa bagian atau modul yang sederhana, sehingga sistem akan lebih mudah dipahami dan dikembangkan. Akibat lebih lanjut adalah sistem akan dapat dikembangkan tepat pada waktu yang telah direncanakan, mudah dipahami oleh pemakai sistem dan mudah untuk dipelihara. Pendekatan ini juga merupakan ciri-ciri dari pendekatan terstruktur.

5. Pendekatan lompatan-jauh lawan pendekatan berkembang (dipandang dari

teknologi yang akan digunakan Pendekatan lompatan-jauh (great loop approach) menerapkan perubahan menyeluruh secara serentak menggunakan teknologi canggih. Perubahan ini banyak mengandung resiko, karena teknologi komputer begitu cepat berkembang dan untuk tahun-tahun mendatang sudah menjadi usang. Pendekatan ini juga terlalu mahal, karena memerlukan investasi seketika untuk semua teknologi yang digunakan dan pendekatan ini juga sulit untuk dikembangkan, karena terlalu komplek. Pendekatan berkembang (evolutionary approach) menerapkan teknologi canggih hanya untuk aplikasi-aplikasi yang memerlukan saja pada saat itu dan akan terus dikembangkan untuk periode-periode berikutnya mengikuti kebutuhannya sesuai dengan perkembangan teknologi yang ada. Pendekatan berkembang menyebabkan investasi tidak terlalu mahal dan dapat mengikuti perkembangan teknologi yang cepat, sehingga teknologi yang digunakan tidak cepat menjadi usang.

H. Metodologi Pengembangan Sistem

Metodologi adalah kesatuan metode-metode, prosedur-prosedur, konsep-konsep pekerjaan, aturanaturan dan postulat-postulat yang digunakan oleh suatu ilmu pengetahuan, seni atau disiplin lainnya. Metode adalah suatu cara/teknik yang sistematik

15



untuk mengerjakan sesuatu. Metodologi pengembangan sistem yang ada biasanya dibuat atau diusulkan oleh : penulis buku, peneliti, konsultan, systems house, pabrik software.

Metodologi pengembangan sistem diklasifikasikan menjadi 3 golongan: 1. Functional Decomposition Methodologies (Metodologi Pemecahan Fungsional).

Metodologi ini menekankan pada pemecahan dari sistem ke dalam subsitem-subsistem yang lebih kecil, sehingga akan lebih mudah untuk dipahami, dirancang dan diterapkan. Yang termasuk dalam kelompok metodologi ini adalah : - HIPO (Hierarchy plus Input-Process-Output) - SR (Stepwise Refinement) atau ISR (Iterative Stepwise Refinement) - Information-Hiding.

2. Data Oriented Methodologies (Metodologi Orientasi Data) Metodologi ini menekankan pada karakteristik dari data yang akan diproses. Metodologi ini dapat dikelompokkan kembali ke dalam dua kelas, yaitu : a. Data-flow oriented methodologies Metodologi ini secara umum didasarkan pada

pemecahan dari sistem kedalam modulo-modul berdasarkan dari tipe elemen data dan tingkah-laku logika modul tersebut di dalam sistem. Dengan metodologi ini, sistem secara logika dapat digambarkan secara logika dari arus data dan hubungan antar fungsinya di dalam modul-modul disistem. Yang termasuk dalam metodologi ini adalah - SADT (Structured Analisys and Design Techniques) - Composite Design - SSAD (Structured Systems Analysis and Design).

b. Data structure oriented methodologies Metodologi ini menekankan struktur dari input dan output di sistem. Struktur ini kemudian akan digunakan sebagai dasar struktur dari sistemnya. Hubungan fungsi antar modul atau elemen-elemen sistem kemudian dijelaskan dari struktur sistemnya. Yang termasuk dalam metodologi ini adalah : - JSD (Jackson’s systems development) - W/O (Warnier / Orr).

3. Prescriptive Methodologies Yang termasuk dalam metodologi ini adalah : ▪ ISDOS (Information Systems Design and Optimization System) Kegunaannya

adalah mengotomatisasi proses pengembangan sistem informasi. ISDOS mempunyai 2 komponen :

a. PSL Merupakan komponen utama dari ISDOS, yaitu suatu bahasa untuk mencatat kebutuhan pemakai dalam bentuk machine-readable form, sehingga output yang dihasilkannya dapat dianalisis oleh PSA. PSL merupakan bahasa untuk menggambarkan sistemnya dan bukan merupakan bahasa pemrograman prosedural.

b. PSA Merupakan paket perangkat lunak yang mirip dengan kamus data (data dictionary) dan digunakan untuk mengecek data yang dimasukkan, yang disimpan , yang dianalisis dan yang dihasilkan sebagai output laporan dengan pemanfaatan DBMS dalam penyimpanan datanya. Kegunaan dan hasil dari PSA adalah : PSA menganalisis PSL untuk kesalahan-kesalahan sintak dan akan menghasilkan laporan-laporan dalam bentuk data dictionary, function dictionary serta analisis dari hubungan-hubungan proses. Laporan dalam bentuk grafik, seperti laporan yang menggambarkan hubungan dari proses termasuk apakah suatu proses merupakan bagian dari porses yang lain atau suatu proses mempunyai komponen proses-proses lain. PSA akan melakukan analisis jaringan untuk mengecek kelengkapan dari semua hubungan data dan

16



proses-proses. PSA juga akan melakukan analisis dari hubungan ketergantungan waktu dari data dan analisis dari spesifikasi volume.

▪ PLEXSYS Kegunaannya adalah untuk melakukan transformasi suatu statemen bahasa komputer tingkat tinggi ke suatu executable code untuk suatu konfigurasi perangkat keras yang diinginkan. PLEXSYS merupakan tambahan untuk ISDOS. Kalau ISDOS digunakan pada aspek penntuan kebutuhan, PLEXSYS digunakan pad aspek penghasil kode program secar otomatis.

▪ PRIDE Merupakan perangkat lunak terpadu yang baik untuk analisis/disain sistem terstruktur, manajemen data, manajemen proyek dan pendokumentasian.

▪ SDM/70 Merupakan suatu perangkat lunak yang berisi kumpulan metode, estimasi, dokumentasi dan petunjuk administrasi guna membantu pemakai untuk mengembangkan dan merawat sistem yang efektif.

▪ SPECTRUM Perangkat lunak ini mempunyai beberapa versi untuk keperluan yang berbeda, semacam SPECTRUM-1 untuk life cycle konvensional, SPECTRUM-2 untuk sistem manajemen proyek terstruktur, SPECTRUM-3 untuk on-line interactive estimator.

▪ SRES (Software Requirement Engineering System) dan SREM (Software Requirement Engineering Methodology) DBO (Design By Objective), PAD (Program Analysis Diagram), HOS (Higher Order Software), MSR (Meta Stepwise Refinement), PDL (Program Design Language)

I. Tools Pengembangan Sistem

Untuk dapat melakukan langkah-langkah sesuai dengan yang diberikan oleh metodologi pengembangan sistem yang terstruktur, maka dibutuhkan alat dan teknik untuk melaksanakannya. Alat-alat yang digunakan dalam suatu metodologi umumnya berupa suatu gambar atau diagram atau grafik. Selain berbentuk gambar, alat-alat yang digunakan juga ada yang tidak berupa gambar atau grafik (nongraphical tools), seperti misalnya data dictionary, structured english, pseudocode serta formulir-formulir untuk mencatat dan menyajikan data.

Alat-alat pengembangan sistem yang berbentuk grafik diantaranya adalah sebagai berikut ini : a. HIPO diagram Hierarchy plus Input-Process-Output, HIPO, adalah alat dokumentasi

program yang berbasis pada fungsi, yaitu tiap-tiap modul di dalam sistem digambarkan oleh fungsi utamanya.

b. Data flow diagram Digunakan untuk menggambarkan suatu sistem yang telah ada atau sistem baru yang akan dikembangkan secara logika tanpa mempertimbangkan lingkungan fisik dimana data tersebut mengalir (misalnya lewat telpon, surat dan sebagainya) atau lingkungan fisik dimana data tersebut akan disimpan (misalnya file kartu, microfile, harddisk, tape, diskette dan lain sebagainya).

c. Structured chart Digunakan untuk mendefinisikan dan mengilustrasikan organisasi dari sistem informasi secara berjenjang dalam bentuk modul dan submodul dengan menunjukkan hubungan elemen data dan elemen kontrol antara hubungan modulnya, sehingga memberikan penjelasan lengkap dari sistem dipandang dari elemen data, elemen kontrol, modul dan hubungan antar modulnya.

d. SADT Structured Analysis and Design Technique, SADT, memandang suatu sistem terdiri dari dua hal : benda (obyek, dokumen atau data) dan kejadian (kegiatan yang dilakukan oleh orang, mesin atau perangkat lunak). Menggunakan dua tipe diagram

17



yaitu, diagram kegiatan (activity diagrams, disebut actigrams) dan diagram data (data diagrams, disebut datagrams)

e. Jackson’s diagram Jackson’s Systems Development (JSD), membangun suatu model dari dunia nyata (real world) yang menyediakan subyek-subyek permasalahan dari sistem. Disamping alat-alat berbentuk grafik yang digunakan pada suatu metodologi tertentu, masih terdapat beberapa alat berbentuk grafik yang sifatnya umum, yaitu dapat digunakan di semua metodologi yang ada. Alat-alat ini berupa suatu bagan yang dapat diklasifikasikan sebagai berikut : 1. Bagan untuk menggambarkan aktivitas (activity charting):

a. Bagan alir sistem (systems flowchart) b. Bagan alir program (program flowchart) yang dapat berupa bagan alir logika

program (program logic flowchart), bagan alir program komputer terinci (detailed computer program flowchart)

c. Bagan alir kertas kerja (paperwork flowchart) d. Bagan alir proses (process flowchart) e. Gantt chart

2. Bagan untuk menggambarkan tataletak (layout charting) 3. Bagan untuk menggambarkan hubungan personil (personal relationship charting):

a. Bagan distribusi kerja (working distribution chart) b. Bagan organisasi (organization chart)

Teknik-teknik dalam pengembangan sistem yang dapat digunakan antara lain: a. Teknik manajemen proyek, yaitu CPM (Critical Path Method) dan PERT (Program

Evaluation and Review Technique) Teknik ini digunakan untuk penjadwalan waktu pelaksanaan suatu proyek.

b. Teknik menemukan fakta (fact finding techniques) Yaitu teknik yang dapat digunakan untuk mengumpulkan data dan menemukan fakta-fakta dalam kegiatan mempelajari sistem yang ada. Teknik-teknik ini diantaranya adalah: ▪ wawancara (interview) wawancara memungkinkan analis sistem sebagai

pewawancara (interviewer) untuk mengumpulkan data secara tatap muka langsung dengan orang yang diwawancarai (interviewee).

▪ observasi (observation) observasi adalah pengamatan langsung suatu kegiatan yang sedang dilakukan yang mana pada waktu observasi analis sistem dapat ikut juga berpartisispasi dengan orang-orang yang sedang melakukan suatu kegiatan tersebut.

▪ daftar pertanyaan (questionaires) adalah suatu daftar yang berisi dengan pertanyaan-pertanyaan untuk tujuan khusus yang memungkinkan analis sistem untuk mengumpulkan data dan pendapat dari responden-responden yang dipilih.

▪ pengumpulan sampel (sampling) pengambilan sampel adalah pemilihan sejumlah item tertentu dari seluruh item yang ada dengan tujuan mempelajari sebagian item tersebut untuk mewakili seluruh itemnya dengan pertimbangan biaya dan waktu yang terbatas.

c. Teknik analisis biaya/manfaat (cost-effectiveness analysis atau cost-benefit analysis) Teknik ini menilai dari sisi kelayakan ekonomis suatu pengembangan sistem informasi.

d. Teknik untuk menjalankan rapat Selama proses pengembangan sistem dilakukan, seringkali rapat-rapat diadakan baik oleh tim pengembangan sistem sendiri atau rapat antara tim pengembangan sistem dengan pemakai sistem dan manajer, sehingga

18



kemampuan analis sistem untuk memimpin atau berpartisipasi di dalam suatu rapat merupakan hal yang penting terhadap kesuksesan proyek pengembangan sistem.

e. Teknik inspeksi/walkthrough Inspeksi merupakan kepentingan dari pemakai sistem dan walkthrough merupakan kepentingan dari analis sistem. Analis sistem melakukan walkthrough untuk maksud supaya dokumentasi yang akan diserahkan kepada pemakai sistem secara teknik tidak mengalami kesalahan dan dapat dilakukan dengan diverifikasi terlebih dahulu oleh analis sistem yang lain. Pemakai sistem melakukan inspeksi untuk maksud menilai dokumentasi yang diserahkan oleh analis sistem secara teknik tidak mengandung kesalahan. Penyebab kegagalan pengembangan sistem : ▪ Kurangnya penyesuaian pengembangan sistem ▪ Kelalaian menetapkan kebutuhan pemakai dan melibatkan pemakai sistem ▪ Kurang sempurnanya evaluasi kualitas analisis biaya ▪ Adanya kerusakan dan kesalahan rancangan ▪ Penggunaan teknologi komputer dan perangkat lunak yang tidak direncanakan

dan pemasangan teknologi tidak sesuai ▪ Pengembangan sistem yang tidak dapat dipelihara ▪ Implementasi yang direncanakan dilaksanakan kurang baik

J. Fungsi Analis Sistem

Analis sistem (systems analyst) adalah orang yang menganalisis sistem (mempelajari masalah-masalah yang timbul dan menentukan kebutuhan-kebutuhan pemakai sistem) untuk mengidentifikasikan pemecahan yang beralasan. Sebutan lain untuk analis sistem ini adalah analis informasi (information analyst), analis bisnis (business analyst), perancang sistem (systems designer), konsultan sistem (systems consultant) dan ahli teknik sistem (systems engineer). Analis sistem berbeda dengan pemrogram. Pemrogram (programmer) adalah orang yang menulis kode program untuk suatu aplikasi tertentu berdasarkan rancang bangun yang telah dibuat oleh analis sistem. Akan tetapi ada juga analis sistem yang melakukan tugas-tugas seperti pemrogram dan sebaliknya ada juga pemrogram yang melakukan tugas-tugas yang dilakukan oleh analis sistem. Orang yang melakukan tugas baik sebagai analis sistem maupun pemrogram disebut analis/pemrogram (analyst/programmer) atau pemrogram/analis (programmer/analyst). Tugas dan tanggung jawab analis sistem dan pemrogram adalah berbeda dan dapat dilihat pada tabel berikut :

Tabel 1. Tugas dan Tanggung Jawab Pemogram dan Analis Sistem

PEMOGRAM ANALIS SISTEM 1. Tanggung jawab pemrogram terbatas

pada pembuatan program komputer. 2. Pengetahuan pemrogram cukup terbatas

pada teknologi komputer. 3. Pekerjaan pemrogram sifatnya teknis dan

harus tepat dalam pembuatan instruksi-instruksi program.

4. Pekerjaan pemrogram tidak menyangkut hubungan dengan banyak orang, terbatas pada sesama pemrogram dan analis sistem yang mempersiapkan rancang

1. Tanggung jawab analis sistem tidak hanya pada pembuatan program komputer saja, tetapi pada sistem secara keseluruhan.

2. Pengetahuan analis sistem harus luas, tidak hanya pada teknologi komputer, tetapi juga pada bidang aplikasi yang ditanganinya.

3. Pekerjaaan analis sistem dalam pembuatan program terbatas pada pemecahan masalah secara garis

19



bangun (spesifikasi) programnya. besar. 4. Pekerjaan analis sistem melibatkan

hubungan banyak orang, tidak terbatas pada sesama analis sistem, pemrogram, tetapi juga pemakai sistem dan manajer.

Seorang Analis sistem harus mempunyai pengetahuan yang luas dan keahlian

yang khusus. Beberapa analis sistem setuju bahwa pengetahuan-pengetahuan dan keahlian berikut ini sangat diperlukan bagi seorang analis sistem yang baik : 1. Pengetahuan dan keahlian tentang teknik pengolahan data, teknologi komputer dan

pemrograman komputer a. Keahlian teknis yang harus dimiliki adalah termasuk keahlian dalam penggunaan alat dan teknik untuk pengembangan perangkat lunak aplikasi serta keahlian dalam menggunakan komputer. b. Pengetahuan teknis yang harus dimiliki meliputi pengetahuan tentang perangkat keras komputer, teknologi komunikasi data, bahasa-bahasa komputer, sistem operasi, utilities dan paket-paket perangkat lunak lainnya.

2. Pengetahuan tentang bisnis secara umum Aplikasi bisnis merupakan aplikasi yang sekarang paling banyak diterapkan, maka analis sistem harus mempunyai pengetahuan tentang ini. Pengetahuan ini dibutuhkan supaya analis sistem dapat berkomunikasi dengan pemakai sistem. Pengetahuan tentang bisnis ini meliputi akuntansi keuangan, akuntansi biaya, akuntansi manajemen, sistem pengendalian manajemen, pemasaran, produksi, manajemen personalia, keuangan, tingkah laku organisasi, kebijaksanaan perusahaan dan aspek-aspek bisnis lainnya.

3. Pengetahuan tentang metode kuantitatif Dalam membangun model-model aplikasi, analis sistem banyak menggunakan metode-metode kuantitatif, seperti misalnya pemrograman linier (linier programming), pemrograman dinamik (dynamic programming), regresi (regresion), network, pohon keputusan (decision tree), trend, simulasi dan lain sebagainya.

4. Keahlian pemecahan masalah Analis sistem harus mempunyai kemampuan untuk meletakkan permasalahanpermasalahan komplek yang dihadapi oleh bisnis, memecah-mecah masalah tersebut ke dalam bagian-bagiannya, menganalisisnya dan kemudian harus dapat merangkainya kembali menjadi suatu sistem yang dapat mengatasi permasalahanpermasalahan tersebut.

5. Keahlian komunikasi antar personil Analis sistem harus mempunyai kemampuan untuk mengadakan komunikasi baik secara lisan maupun secara tertulis. Keahlian ini diperlukan di dalam wawancara, presentasi, rapat dan pembuatan laporan-laporan.

6. Keahlian membina hubungan antar personil Manusia merupakan faktor yang kritis di dalam sistem dan watak manusia satu dengan yang lainnya berbeda. Analis sistem yang kaku dalam membina hubungan kerja dengan personil-personil lainnya yang terllibat, akan membuat pekerjaannya menjadi tidak efektif. Apalagi bila analis sistem tidak dapat membina hubungan yang baik dengan pemakai sistem, maka akan tidak mendapat dukungan dari pemakai sistem atau manajemen dan kecenderungan pemakai sistem akan mempersulitnya.

Dalam sebuah proyek pengembangan sistem, pembentukan sebuah Tim

Pengembangan Sistem dalam skala kecil dan sederhana, kemungkinan hanya ada seorang analis sistem yang merangkap sebagai pemrogram (analis/pemrogram) atau seorang pemrogram yang merangkap sebagai analis sistem (pemrogram/analis). Akan

20



tetapi untuk proyek pengembangan sistem yang besar atau komplek, pekerjaan ini biasanya dilakukan oleh sejumlah orang dalam bentuk tim. Anggota dari tim pengembangan sistem ini tergantung dari besar-kecilnya ruang-lingkup proyek yang kaan ditangani. Tim ini secara umum dapat terdiri dari personil-personil sebagai berikut ini : 1. Manajer analisis sistem, Manajer analisis sistem (manager of systems analysis) ini

disebut juga sebagai koordinator proyek dan mempunyai tugas dan tanggung jawab: a. Sebagai ketua/koordinator tim pengembangan sistem b. Mengarahkan, mengontrol dan mengatur anggota tim pengembangan sistem

lainnya c. Membuat jadwal pelakasanaan proyek pengembangan sistem yang akan dilakukan d. Bertanggungjawab dalam mendefinisikan masalah, studi kelayakan, disain sistem

dan penerapannya e. Memberikan rekomendasi-rekomendasi perbaikan sistem f. Mewakili tim untuk berhubungan dengan pemakai sistem dalam hal perundingan-

perundingan dan pemberian-pemberian nasehat kepada manajemen dan pemakai sistem

g. Membuat laporan-laporan kemajuan proyek (progress report) h. Mengkaji ulang dan memeriksa kembali hasil kerja dari tim

2. Ketua analis sistem, Ketua analis sistem (lead systems analyst) biasanya menjabat

sebagai wakil dari manajer analisis sistem. Tugasnya adalah membantu tugas dari manajer analisis sistem dan mewakilinya bila manajer analisis sistem berhalangan.

3. Analis sistem senior, Analis sistem senior (senior systems analyst) merupakan analis sistem yang sudah berpengalaman.

4. Analis sistem Analis sistem (systems analyst) merupakan analis sistem yang cukup berpengalaman dan dapat bekerja sendiri tanpa bimbingan dari analis sistem senior.

5. Analis sistem yunior Analis sistem yunior (junior systems analyst) merupakan analis sistem yang belum berpengalaman dan masih membutuhkan bimbingan-bimbingan dari analis sistem yang lebih senior. Analis sistem yunior ini sering juga disebut dengan analis sistem yang masih dilatih (systems analyst trainee).

6. Pemrogram aplikasi senior Pemrogram aplikasi senior (senior applications programmer) merupakan pemrogram komputer yang sudah berpengalaman dengan tugas merancang spesifikasi dari program aplikasi dan mengkoordinasi kerja dari pemrogram yang lainnya. Pemrogram aplikasi senior ini kadang-kadang juga disebut dengan pemrogram/analis.

7. Pemrogram aplikasi Pemrogram aplikasi (applications programmer) merupakan pemrogram komputer yang cukup berpengalaman dan dapat melakukan tugasnya tanpa harus dibimbing secara langsung lagi.

8. Pemrogram aplikasi yunior Pemrogram aplikasi yunior (junior applications programmer) merupakan pemrogram komputer yang belum berpengalaman dan masih dibawah bimbingan langsung dari pemrogram yang lebih senior. Pemrogram aplikasi yunior biasanya hanya dilibatkan pada pembuatan modul-modul program yang sederhana, seperti misalnya pembuatan bentuk-bentuk I/O. Pemrogram aplikasi yunior ini sering juga disebut dengan pemrogram aplikasi yang masih dilatih (applications programmer trainee).

21



BAB II METODE PENGEMBANGAN SISTEM

2.1 Metode Pengembangan Sistem A. Definisi

Metode pengembangan system adalah suatu proses pengembangan system yang formal dan presisi yang mendefinisikan serangkaian aktivitas, metode, best practices dan tools yang terautomasi bagi para pengembang danmanager proyek dalam rangka mengembangkan dan merawat sebagai keseluruhan system informasi atau software. Alasan perlunya metode pengembangan sistem adalah: a. Menjamin adanya konsistensi proses b. Dapat diterapkan dalam berbagai jenis proyek c. Mengurangi resiko kesalahan dan pengambilan jalan pintas. d. Menuntut adanya dokumentasi yang konsisten yang bermanfaat bagi personal baru

dalam tim proyek.

B. Jenis Metode Pengembangan System 1. Metode System Development Life Cycle (SDLC)

SDLC atau Software Development Life Cycle atau System Development Life Cycle adalah proses mengembangkan atau mengubah suatu sistem perangkat lunak dengan menggunakan model-model atau metodologi yang digunakan orang untuk mengembangkan sistem-sistem perangkat lunak sebelumnya (Rosa dan Shalahuddin). Metode ini adalah metode pengembangan sistem informasi yang pertama kali digunakan makanya disebut dengan metode tradisional. Metode ini prototype, adalah tahap-tahapan pekerjaan yang dilakukan oleh analis sistem dan programer dalam membangun sistem informasi.

Tahap-tahap SDLC yaitu:

• Melakukan survey dan menilai kelayakan proyek pengembangan sistem informasi. • Mempelajari dan menganalisis sistem informasi yang sedang berjalan. • Menentukan permintaan pemakai sistem informasi. • Memilih solusi atau pemecahan masalah yang paling baik. • Menentukan perangkat keras dan perangkat lunak computer. • Merancang sistem informasi baru. • Mengkomunikasikan dan mengimplementasikan sistem informasi baru. • Memelihara dan melakukan perbaikan/peningkatan sistem informasi baru.

22



Gambar 7. Tahapan SDLC

Gambar8. Siklus SDLC

Kelebihan • Mudah diaplikasikan. • Memberikan template tentang metode analisis, desain, pengkodean, pengujian, dan

pemeliharaan. Kekurangan

• Jarang sekali proyek riil mengikuti aliran sekuensial yang dianjurkan model karena model ini bisa melakukan itersi tidak langsung.

• Pelanggan sulit untuk menyatakan kebutuhan secara eksplisit sehingga sulit untuk megakomodasi ketidakpastian pada saat awal proyek.

23



• Pelanggan harus bersikap sabar karena harus menunggu sampai akhir proyek dilalui. Sebuah kesalahan jika tidak diketahui dari awal akan menjadi masalah besar karena harus mengulang dari awal.

• Pengembang sering malakukan penundaan yang tidak perlu karena anggota tim proyek harus menunggu tim lain untuk melengkapi tugas karena memiliki ketergantungan hal ini menyebabkan penggunaan waktu tidak efesien.

2.2 Model WATERFALL

Sering juga disebut model Sequential Linier. Beberapa pengertian dan pendapat ahli tentang Metode Air Terjun ( waterfall) dapat diuraikan berikut ini :

Menurut Pressman (2015:42), model waterfall adalah model klasik yang bersifat sistematis, berurutan dalam membangun software. Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut juga dengan “classic life cycle” atau metode waterfall. Model ini termasuk ke dalam model generic pada rekayasa perangkat lunak dan pertama kali diperkenalkan oleh Winston Royce sekitar tahun 1970 sehingga sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai dalam Software Engineering (SE). Model ini melakukan pendekatan secara sistematis dan berurutan. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan. Fase-fase dalam Waterfall Model menurut referensi Pressman :

Gambar 9. Tahapan Waterfall Model Pressman

a. Communication (Project Initiation & Requirements Gathering) Sebelum memulai pekerjaan yang bersifat teknis, sangat diperlukan adanya komunikasi dengan customer demi memahami dan mencapai tujuan yang ingin dicapai. Hasil dari komunikasi tersebut adalah inisialisasi proyek, seperti menganalisis permasalahan yang dihadapi dan mengumpulkan data-data yang diperlukan, serta membantu mendefinisikan fitur dan fungsi software. Pengumpulan data-data tambahan bisa juga diambil dari jurnal, artikel, dan internet.

b. Planning (Estimating, Scheduling, Tracking) Tahap berikutnya adalah tahapan perencanaan yang menjelaskan tentang estimasi tugas-tugas teknis yang akan dilakukan, resikoresiko yang dapat terjadi, sumber daya yang diperlukan dalam membuat sistem, produk kerja yang ingin dihasilkan, penjadwalan kerja yang akan dilaksanakan, dan tracking proses pengerjaan sistem.

c. Modeling (Analysis & Design) Tahapan ini adalah tahap perancangan dan permodelan arsitektur sistem yang berfokus pada perancangan struktur data, arsitektur software, tampilan interface, dan algoritma program. Tujuannya untuk lebih memahami gambaran besar dari apa yang akan dikerjakan.

24



d. Construction (Code & Test) Tahapan Construction ini merupakan proses penerjemahan bentuk desain menjadi kode atau bentuk/bahasa yang dapat dibaca oleh mesin. Setelah pengkodean selesai, dilakukan pengujian terhadap sistem dan juga kode yang sudah dibuat. Tujuannya untuk menemukan kesalahan yang mungkin terjadi untuk nantinya diperbaiki.

e. Deployment (Delivery, Support, Feedback) Tahapan Deployment merupakan tahapan implementasi software ke customer, pemeliharaan software secara berkala, perbaikan software, evaluasi software, dan pengembangan software berdasarkan umpan balik yang diberikan agar sistem dapat tetap berjalan dan berkembang sesuai dengan fungsinya. (Pressman, 2015:17)

Kapan sebaiknya metode waterfall digunakan? Ada teori-teori yang menyimpulkan beberapa hal, yaitu : 1. Ketika semua persyaratan yang diajukan sudah dipahami dengan baik pada awal

pengembangan program. 2. Definisi produk bersifat stabil dan tidak ada perubahan yang dilakukan saat

pengembangan untuk alasan apapun. Oleh karena itu, teknologi yang digunakan juga harus sudah dipahami dengan baik.

3. Menghasilkan produk baru, atau produk dengan versi baru. Sebenarnya, jika menghasilkan produk dengan versi baru maka itu sudah termasuk incremental development, yang setiap tahapannya sama dengan metode waterfall kemudian diulang-ulang.

4. Port-ing produk yang sudah ada ke dalam platform baru.

Dengan demikian, metode waterfall dianggap pendekatan yang lebih cocok digunakan untuk proyek pembuatan sistem baru dan juga pengembangan software dengan tingkat resiko yang kecil serta waktu pengembangan yang cukup lama. Tetapi salah satu kelemahan paling mendasar adalah menyamakan pengembangan hardware dan software dengan meniadakan perubahan saat pengembangan. Padahal, error diketahui saat software dijalankan, dan perubahan-perubahan akan sering terjadi.

Keuntungan menggunakan metode waterfall adalah prosesnya lebih terstruktur, hal ini membuat kualitas software baik dan tetap terjaga. Dari sisi user juga lebih menguntungkan, karena dapat merencanakan dan menyiapkan kebutuhan data dan proses yang diperlukan sejak awal. Penjadwalan juga menjadi lebih menentu, karena jadwal setiap proses dapat ditentukan secara pasti. Sehingga dapat dilihat jelas target penyelesaian pengembangan program. Dengan adanya urutan yang pasti, dapat dilihat pula perkembangan untuk setiap tahap secara pasti. Dari sisi lain, model ini merupakan jenis model yang bersifat dokumen lengkap sehingga proses pemeliharaan dapat dilakukan dengan mudah.

Kelemahan menggunakan metode waterfall adalah bersifat kaku, sehingga sulit melakukan perubahan di tengah proses. Jika terdapat kekurangan proses/prosedur dari tahap sebelumnya, maka tahapan pengembangan harus dilakukan mulai dari awal lagi. Hal ini akan memakan waktu yang lebih lama. Karena jika proses sebelumnya belum selesai sampai akhir, maka proses selanjutnya juga tidak dapat berjalan. Oleh karena itu, jika terdapat kekurangan dalam permintaan user maka proses pengembangan harus dimulai kembali dariawal. Karena itu, dapat dikatakan proses pengembangan software dengan metode waterfall bersifat lambat. Kelemahan lainnya menggunakan metode waterfall adalah membutuhkan daftar kebutuhan yang lengkap sejak awal. Tetapi, biasanya jarang sekali customer yang dapat memenuhi itu. Untuk menghindari

25



pengulangan tahap dari awal, user harus memberikan seluruh prosedur, data, dan laporan yang diinginkan mulai dari tahap awal pengembangan. Tetapi pada banyak kondisi, user sering melakukan permintaan ditahap pertengahan pengembangan sistem. Dengan metode ini, maka development harus dilakukan mulai lagi dari tahap awal. Karena development disesuaikan dengan desain hasil user pada saat tahap pengembangan awal. Di sisi lain, user tidak dapat mencoba sistem sebelum sistem benar-benar selesai. Selain itu, kinerja personil menjadi kurang optimal karena terdapat proses menunggu suatu tahap selesai terlebih dahulu. Oleh karena itu, seringkali diperlukan personil yang “multi-skilled” sehingga minimal dapat membantu pengerjaan untuk tahapan berikutnya. (Pressman, 2015:42-43)

Menurut Rosa A.S dan M. Shalahuddin (2015:28-30) Model SDLC air terjun (waterfall) sering juga disebut model sekuensial linier (sequential linier) atau alur hidup klasik (classic life cycle). Model air terjun menyediakan pendekatan alur hidup perangkat lunak secara sekuensial atau terurut dimulai dari analisis, desain, pengodean, pengujian, dan tahap pendukung (support).

Gambar 10. Tahapan Waterfall

Berikut langkah-langkah yang penting dalam model ini sebagai berikut: a. Analisis kebutuhan perangkat lunak

Proses pengumpulan kebutuhan dilakukan secara intensif untuk menspesifikasikan kebutuhan perangkat lunak agar dapat dipahami perangkat lunak seperti apa yang dibutuhkan oleh user. Spesifikasi kebutuhan perangkat lunak pada tahap ini perlu didokumentasikan.

b. Desain

Desain perangkat lunak adalah proses multi langkah yang fokus pada desain pembuatan program perangkat lunak termasuk struktur data, arsitektur perangkat lunak, representasi antarmuka, dan prosuder pengodean. Tahap ini mentranslasi kebutuhan perangkat lunak dari tahap analisis kebutuhan ke representasi desain agar dapat diimplementasikan menjadi program pada tahap selanjutnya. Desain perangkat lunak yang dihasilkan pada tahap ini juga perlu didokumentasikan.

c. Pembuatan kode program

Desain harus ditranslasikan ke dalam program perangkat lunak. Hasil dari tahap ini adalah program computer sesuai desain yang telah dibuat pada tahap desain.

26



d. Pengujian Pengujian focus pada perangkat lunak secara dari segi lojik dan fungsional dan memastikan bahwa semua bagian sudah diuji. Hal ini dilakukan untuk meminimalisir kesalahan (error) dan memastikan keluaran yang dihasilkan sesuai dengan yang diinginkan.

e. Pendukung (support) atau pemeliharaan (maintenance)

Tidak menutup kemungkinan sebuah perangkat lunak mengalami perubahan ketika sudah dikirimkan ke user. Perubahan bisa terjadi karena adanya kesalahan yang muncul dan tidak terdeteksi saat pengujian atau perangkat lunak harus beradaptasi dengan lingkungan baru. Tahap pendukung atau pemeliharaan dapat mengulangi proses pengembangan mulai dari analisis spesifikasi untuk perubahan perangkat lunak yang sudah ada, tapi tidak untuk membuat perangkat lunak baru.

Kelebihan Waterfall : Keuntungan pengembangan dengan metode waterfall adalah metode ini memungkinkan untuk departementalisasi dan kontrol. proses pengembangan model fase satu per satu, sehinggameminimalis kesalahan-kesalahan yang mungkin akan terjadi. Pengembanganya bergerak dari konsep, yaitu melalui desain, implementasi, pengujian, instalasi, troubleshooting, dan berakhir di operasi dan pemeliharaan.

a. Kualitas dari sistem yang dihasilkan akan baik. Ini dikarenakan oleh pelaksanaannya secara bertahap. Sehingga tidak terfokus pada tahapan tertentu.

b. Document pengembangan system sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya. Jadi setiap fase atau tahapan akan mempunyai dokumen tertentu.

c. Metode ini masih lebih baik digunakan walaupun sudah tergolong kuno, daripada menggunakan pendekatan asal-asalan. Selain itu, metode ini juga masih masuk akal jika kebutuhan sudah diketahui dengan baik.

Kerugian Waterfall :

a. Kerugian pembangunan menggunakan metode waterfall adalah tidak memungkinkan untuk banyak refleksi atau revisi jika terjadi kesalahan. Karna setelah aplikasi ini dalam tahap pengujian, sangat sulit untuk kembali dan mengubah sesuatu yang tidak terdokumentasi dengan baik dalam tahap konsep.

b. Diperlukan majemen yang baik, karena proses pengembangan tidak dapat dilakukan secara berulang sebelum terjadinya suatu produk.

c. Kesalahan kecil akan menjadi masalah besar jika tidak diketahui sejak awal pengembangan yang berakibat pada tahapan selanjutnya.

d. Pelanggan sulit menyatakan kebutuhan secara eksplisit sehingga tidak dapat mengakomodasi ketidak pastian pada saat awal pengembangan.

e. Pelanggan harus sabar, karena pembuatan perangkat lunak akan dimulai ketika tahap desain sudah selesai. Sedangkan pada tahap sebelum desain bisa memakan waktu yang lama.

Pada kenyataannya, jarang mengikuti urutan sekuensial seperti pada teori. Iterasi sering terjadi menyebabkan masalah baru

27



2.3 Model Prototyping Prototype adalah salat satu metode pengembangan perangkat lunak yang banyak

digunakan. Prototyping adalah proses iterative dalam pengembangan sistem dimana requirement diubah ke dalam sistem yang bekerja (working system) yang secara terus menerus diperbaiki melalui kerjasama antara user dan analis. Prototype juga bisa dibangun melalui beberapa tool pengembangan untuk menyederhanakan proses. Dengan menggunakan Metode prototyping ini, pengembang dan pelanggan dapat saling berinteraksi selama proses pembuatan sistem. Sering terjadi seorang pelanggan hanya mendefinisikan secara umum apa yang dibutuhkan, pemrosesan dan data-data apa saja yang dibutuhkan. Sebaliknya, disisi pengembang kurang memperhatikan efisiensi Algoritma. Kemampuan sistem operasi dan interface yang menghubungkan manusia dengan komputer.

Pada prototyping model kadang-kadang klien hanya memberikan beberapa kebutuhan umum software tanpa detail input, proses atau detail output dilain waktu mungkin tim pembangun (developer) tidak yakin terhadap efisiensi dari algoritma yang digunakan , tingkat adaptasi terhadap sistem operasi atau rancangan form user interface . Ketika situasi seperti ini terjadi, model prototyping sangat membantu proses pembangunan software. Proses pada prototyping dapat digambarkan pada gambar berikut ini :

Gambar 11. Proses Prototipe

1. Mendengarkan Pelanggan Pada tahap ini dilakukan pengumpulan kebutuhan dari sistem dengan cara mendengar keluhan dari pelanggan. Untuk membuat suatu sistem yang sesuai kebutuhan, maka harus diketahui terlebih dahulu bagaimana sistem yang sedang berjalan untuk kemudian mengetahui masalah yang terjadi.

2. Merancang dan Membuat Mockup Pada tahapan ini, dilakukan perancangan dan pembuatan prototype system . Mockup/ Prototype yang dibuat disesuaikan dengan kebutuhan sistem yang telah didefinisikan sebelumnya dari keluhan pelanggan atau pengguna.

3. Uji Coba Pada tahap ini, Mockup/ Prototype dari sistem di uji coba oleh pelanggan atau pengguna. Lalu dilakukan evaluasi kekurangan-kekurangan dari kebutuhan

28



pelanggan. Pengembangan kemudian kembali mendengarkan keluhan dari pelanggan untuk memperbaiki Prototype yang ada.

Mock-up adalah sesuatu yang digunakan sebagai model desain untuk mengajar, demonstrasi, evaluasi desain, promosi atau keperluan lain yang mempu menyediakan atau mendemonstrasikan sebagian besar fungsi perangkat lunak dan memungkinkan pengujian desain perangkat lunak Rangkuman Tahapan-tahapan Model Prototyping

• Pengumpulan Kebutuhan • Membangun Prototyping • Menggunakan Sistem • Mengkodekan Sistem • Menguji Sistem • Evaluasi Sistem • Evaluasi Protoptyping

Kelebihan

• Prototype melibatkan user dalam analisa dan desain. • Punya kemampuan menangkap requirement secara konkret. • Digunakan untuk memperluas SDLC.

Kekurangan

• Proses analisis dan perancangan terlalu singkat. • Mengesampingkan alternatif pemecahan masalah. • Bisanya kurang fleksible dalam mengahdapi perubahan. • Protitype yang dihasilkan tidak selamanya mudah dirubah dan cepat selesai.

2.4 Model RAD (Rapid Application Development) Rapid application development (RAD) adalah metode yang berfokus pada

pengembangan aplikasi secara cepat, melalui pengulangan dan feedback berulang-ulang. RAD diajukan oleh IBM pada tahun 1980 sampai 1990-an, ketika permintaan terhadap aplikasi semakin meningkat. Dengan banyaknya demand, orang-orang di dunia IT harus mencari solusi untuk memenuhi permintaan tersebut.

Metode ini merupakan semacam cikal bakal agile project management, karena bisa mengikuti pace bisnis yang terus berkembang dan juga kebutuhan pasar yang terus meningkat. Pengembangan software pada umumnya seperti waterfall model membutuhkan perencanaan yang terbilang cukup kaku. Klien atau pelanggan seakan ‘dipaksa’ untuk menyetujui banyak hal di awal, tetapi mereka tidak bisa melihat proses pembuatannya. RAD adalah penggabungan beberapa metode atau teknik terstruktur. RAD menggunakan metode prototyping dan teknik terstruktur lainnya untuk menentukan kebutuhan user dan perancangan sistem informasiselain itu RAD menekankan siklus perkembangan dalam waktu yang singkat (60 sampai 90 hari) dengan pendekatan konstruksi berbasis komponen.

29



Gambar 12. Model RAD

Gambar13. Model RAD

Seperti yang terlihat pada gambar di atas, terdapat 3 tim yang bekerja dalam sebuah proyek. Seperti yang telah dijelaskan di atas, 3 tim tersebut melakukan tahapan-tahapan yang sama namun setiap tim mengerjakan fungsi dari suatu proyek yang berbeda-beda. Berikut adalah penjelasan tahapan-tahapan diatas.

Bussiness Modeling

Pada tahap ini, kebutuhan-kebutuhan dari pelanggan dijelaskan secara detail dalam bentuk fungsi-fungsi yang akan dikerjakan. Kata Bussiness Modeling bukan berarti

30



mewakili kebutuhan-kebutuhan dari pelanggan yang bersifat bisnis saja. Nama tersebut hanya mewakili sebagian kecil dari kebutuhan-kebutuhan yang ada.

Data Modeling

Pada tahapan ini, data-data yang ada pada fungsi-fungsi tersebut (fungsi yang telah dijelaskan pada tahap Bussiness Modeling) akan dijelaskan. Kemudian akan diproses lebih lanjut pada tahapan selanjutnya yaitu Process Modeling.

Process Modeling

Seluruh data-data dan juga bahan-bahan yang lainnya akan diproses dan diolah pada tahapan ini. Hasil proses tersebut berupa informasi-informasi yang dapat berguna bagi pelanggan dan juga dapat berguna untuk tahapan selanjutnya.

Application Modeling

Pada tahapan ini, program mulai dibuat. Informasi-informasi yang telah didapatkan dari tahapan-tahapan sebelumnya digunakan oleh programmer selama pembuatan program. Seluruh konsep yang sudah didapatkan juga dijadikan sebagai acuan oleh programmer dalama pembuatan program.

Testing & Turnover Pada tahap ini, program yang telah jadi akan diuji coba satu per satu dari masing-masing tim. Apabila ada salah satu tim tidak lulu dalam pengujian, maka tim tersebut harus menyelesaikannya dengan cepat. Setelah program dari seluruh tim lulus dalam pengujian, maka program-program tersebut akan disatukan menjadi satu program utuh yang sesuai dengan permintaan pelanggan.

Kelebihan Model RAD: 1. Adanya pembagian tugas secara tim, membuat model RAD menjadi sangat ideal

dalam mengerjakan proyek yang membutuhkan waktu singkat sebab waktu yang dibutuhkan dalam menyelesaikan sebuah proyek relatif singkat. Hanya sekitar 60 – 90 hari waktu yang dibutuhkan sedangkan secara umum, penyelesaian sebuah proyek memakan waktu sekitar 180 hari. Nominal angka tersebut hanyalah sebagian contoh yang menunjukkan bahwa dengan menggunakan model RAD maka sebuah proyek akan jauh lebih cepat selesai, bahkan bisa mengurangi setengah dari waktu normal.

2. Proses pengembangan ulang tidak memakan waktu yang lama, sebab fungsi-fungsi sudah terbagi secara merata untuk setiap tim sehingga pengembangan dari fungsi-fungsi tersebut tidak membutuhkan waktu yang banyak. Apabila fungsi pada tim 1 yang akan dikembangkan misalnya, maka hanya pada tim 1 saja yang akan melakukan proses pengembangan ulang. Sedangkan tim 2, tim 3, tidak perlu melakukan pengembangan ulang.

Kekurangan RAD: 1. Memerlukan banyak sumber daya dalam mengerjakan sebuah proyek. Karena adanya

pembagian secara tim berarti membutuhkan orang yang cukup banyak. Misalnya dalam 1 tim berisi 5 orang, apabila sebuah proyek terbagi atas 4 tim maka dibutuhkan paling sedikit 20 orang untuk mengerjakan proyek tersebut. Selain itu, juga diperlukan banyak sumber daya yang lain yang akan diperlukan untuk setiap tim.

2. Tidak cocok untuk proyek berskala besar. Pengerjaan proyek berskala besar tentunya akan cepat selesai. Namun, semakin besar proyek maka tim yang akan terbagi semakin banyak. Dengan kata lain, sumber daya yang diperlukan akan semakin

31



banyak baik dari segi sumber daya manusianya (jumlah orang yang diperlukan) maupun sumber daya lainnya. Hal ini dapat menyebabkan biaya pengerjaan proyek menjadi membengkak.

3. Adanya keterbatasan dalam mengambil sebuah proyek. Selain proyek-proyek berskala besar yang sebaiknya tidak diambil, proyek-proyek yang tidak dapat dipecah (di modularisasi ) secara fungsi tidak dapat dikerjakan pada model ini.

4. Penggabungan hasil dari setiap tim sangat memerlukan kerja keras. Sebab setiap tim mungkin memiliki konsep yang berbeda selama pengerjaan. Sehingga apabila hasilnya mau digabungkan, maka seluruh tim harus berkumpul dan saling bekerja sama dalam menggabungkan hasil agar menjadi satu program yang utuh.

2.5 Model Spiral

Model Spiral (spiral model) adalah salah satu bentuk dari Metode Pengembangan Perangkat Lunak atau yang disebut SDLC (Software Development Life Cycle), yang sangat populer digunakan dalam bidang teknologi informasi. Model Spiral adalah gabungan dari Model Prototyping dan Model Waterfall dengan penekanan yang tinggi pada analisis risiko tiap tahapannya. Tahun 1986, model ini dikenalkan pertama kali oleh Barry Boehm pada makalahnya yang berjudul “A Spiral Model of Software Development and Enhancement”. Makalah tersebut menjelaskan tentang sebuah diagram yang dihasilkan dari berbagai publikasi yang mendiskusikan tentang model spiral ini. Model ini merupakan model yang sudah lama, tetapi sangat berguna untuk melakukan pembangunan proyek-proyek besar. Pada makalah awal yang dibuatnya, Barry Boehm menganggap bahwa model Spiral adalah suatu model proses yang berhubungan dengan inkrementasi, Model Waterfall dan Model Prototyping. Namun dalam publikasi selanjutnya, Boehm menjelaskan bahwa model Spiral sebagai model proses generator yang mana pilihan berdasarkan risiko proyek untuk menghasilkan suatu model proses yang tepat untuk proyek tersebut. Dengan demikian, inkrementasi, Model Waterfall dan Model Prototyping adalah kasus khusus dengan pola risiko proyek tertentu dari Model Spiral. Model iteratif ditandai dengan tingkah laku yang memungkinkan pengembang mengembangkan versi perangkat lunak yang lebih lengkap secara bertahap. Model Spiral dibagi menjadi beberapa kerangka aktivitas atau disebut juga wilayah kerja (task region). Cocok digunakan untuk mengembangkan aplikasi dengan skala besar tetapi target waktu dan biaya tidak terlalu tinggi.

32

https://www.dictio.id/t/apa-yang-anda-ketahui-tentang-berpikir-analisis/119666



Gambar 14. Model Spiral

a. Komunikasi dengan Pelanggan (customer Communication), Untuk membangun

komunikasi yang efektif antara pengembang (developer) dan pelanggan (customer). b. Perencanaan (Planning), Untuk mendefinisikan sumber daya, waktu, dan informasi

yang terkait dengan proyek. c. Analisa Resiko (Risk Analysis),Diperlukan untuk memperkirakan resiko dari segi teknis

maupun manajemen. d. Rekayasa, Diperlukan untuk membangun satu atau lebih representasi dari aplikasi

perangkat lunak (dapat juga berupa prototipe). e. Konstruksi dan Peluncuran (Construction and release), Dibutuhkan untuk

mengonstruksi, menguji, melakukan instalasi, dan menyediakan dukungan terhadap user.

f. Evaluasi Pelanggan (customer Evaluation), Untuk mendapatkan umpan balik berdasarkan evaluasi representasi perangkat lunak yang dihasilkan dari proses rekayasa dan diimplementasikan pada tahap instalasi.

33



Kelebihan • Dapat disesuaikan agar perangkat lunak bisa dipakai selama hidup perangkat lunak

komputer. • Lebih cocok untuk pengembangan sistem dan perangkat lunak skala besar • Pengembang dan pemakai dapat lebih mudah memahami dan bereaksi terhadap

resiko setiap tingkat evolusi karena perangkat lunak terus bekerja selama proses • Menggunakan prototipe sebagai mekanisme pengurangan resiko dan pada setiap

keadaan di dalam evolusi produk. • Tetap mengikuti langkah-langkah dalam siklus kehidupan klasik dan

memasukkannya ke dalam kerangka kerja iterative. • Membutuhkan pertimbangan langsung terhadp resiko teknis sehingga mengurangi

resiko sebelum menjadi permaslahan yang serius.

Kekurangan • Sulit untuk menyakinkan pelanggan bahwa pendekatan evolusioner ini bisa

dikontrol. • Memerlukan penaksiran resiko yang masuk akal dan akan menjadi masalah yang

serius jika resiko mayor tidak ditemukan dan diatur. • Butuh waktu lama untuk menerapkan paradigma ini menuju kepastian yang

absolute 2.6 Model Iteratif Mengkombinasikan proses-proses pada model air terjun dan iteratif pada model prototipe yang menghasilkan versi-versi perangkat lunak yang sudah mengalami penambahan fungsi untuk setiap pertambahannya. Model ini cocok untuk pengembang dengan turnover staf yang tinggi. Model Inkremental dibuat untuk mengatasi kelemahan model waterfall yang tidak mengakomodasi iterasi dan mengatasi kelemahan dari metode prototipe yang memiliki proses terlalu pendek.

Gambar15. Model Iteratif

34



Pengembangan iteratif dan inkremental adalah kombinasi dari iterative model dan incremental build model dalam pengembangan software. Dalam pengembangan perangkat lunak pada model ini, bisa terdapat lebih dari satu siklus pengulangan yang berjalan dalam waktu bersamaan. Proses ini lah yang dimaksud dengan incremental.

Dalam incremental model, kebutuhan dan persyaratan yang ada dikerjakan dalam beberapa bagian. Setiap iterasi, pengembangan melewati fase requirement, design, implementation, dan testing. Setiap rilis akan selalu ada penambahan fungsi dibandingkan versi sebelumnya. Proses berlanjut sampai sistem lengkap siap sesuai kebutuhan.

Kunci keberhasilan dalam saat menggunakan siklus ini ialah validasi prasyarat yang diverifikasi san diuji dalam setiap siklusnya. Ketika software berkembang melalui siklus yang beruntun, pengujian harus diulang dan diperluas untuk memverifikasi setiap versi yang dikembangkan.

Sebagaimana model lainnya dalam Software Development Life Cycle lainnya, penggunaan model ini memiliki beberapa kondisi untuk memaksimalkan hasilnya. Adapun, model ini paling sering digunakan dalam skenario-skenario berikut : a. Persyaratan dan kebutuhan sistem yang akan dibangun terdefinisi dengan jelas dan

dipahami dengan baik. b. Persyaratan utama harus ditentukan. Namun demikian, beberapa fungsi atau

peningkatan lain yang ingin ditambahkan dapat berkembang seiring berjalannya waktu.

c. Ada waktu dan batasan pasar. d. Tim yang mengerjakan sedang belajar dan menggunakan teknologi baru saat

menjalankan proyeknya. e. Tenaga ahli dengan keahlian yang dibutuhkan tidak ada dan hanya akan bergabung

pada saat iterasi tertentu, berdasarkan kontrak. f. Ada fitur-fitur dengan risiko tinggi yang mungkin berubah di masa depan.

Keuntungan dari model ini adalah adanya metode yang daoat bekerja dan menunjukkan kekurangan desain dan fungsi pada tahap pengembangan yang sangat dini. Menemukan permasalahan sedini mungkin memungkinkan pengembang untuk mengambil tindakan korektif dalam anggaran terbatas.

Kerugian model SDLC ini adalah bahwa iterative model hanya dapat dilakukan pada pengembangan software berskala besar. Ini diikarenakan, sulitnya memecah sistem perangkat lunak sederhana.

Keuntungan dari Iterative dan Incremental SDLC Model adalah sebagai berikut : a. Memungkinkan pengerjaan dan pengembangan fungsi-fungsi yang ingin dijalankan

secara cepat dalam tahap awal pengerjaan. b. Hasil diperoleh awal dan berkala. c. Pengembangan paralel dapat direncanakan. d. Kemajuan yang dapat diukur. e. Sumber daya untuk mengubah ruang lingkup / persyaratan lebih sedikit. f. Mudah melakukan pengujian dan perbaikan pada pengulangan spesifik. g. Risiko diidentifikasi dan diselesaikan selama iterasi; setiap iterasi

merupakan milestones yang mudah dikelola. h. Lebih mudah mengelola risiko – Bagian berisiko tinggi dilakukan terlebih dahulu. i. Dengan setiap peningkatan, operasional produk dikirimkan.

35



j. Masalah, tantangan, dan risiko yang diidentifikasi dari setiap kenaikan dapat dimanfaatkan / diterapkan pada kenaikan berikutnya.

k. Analisis risiko lebih baik. l. Mendukung perubahan persyaratan. m. Waktu pengoperasian awal cenderung singkat. n. Cocok untuk proyek-proyek besar dan penting. o. Selama siklus, software dihasilkan lebih awal, memberikan ruang evaluasi dan umpan

balik pelanggan. Kerugian dari SDLC iterative model adalah sebagai berikut: a. Kemungkinan memerlukan lebih banyak sumber daya. b. Meskipun biaya perubahan lebih rendah, tetapi tidak terlalu cocok untuk mengubah

persyaratan. c. Dibutuhkan lebih banyak perhatian manajemen. d. Arsitektur sistem atau masalah desain mungkin muncul karena tidak semua

persyaratan dikumpulkan pada awal seluruh siklus hidup. e. Menentukan peningkatan mungkin memerlukan definisi sistem yang lengkap. f. Tidak cocok untuk proyek yang lebih kecil. g. Kompleksitas manajemen lebih banyak. h. Risiko pada proyek akhir mungkin kurang diketahui. i. Memerlukan sumber daya yang terampil untuk analisis risiko. j. Kemajuan proyek sangat tergantung pada fase analisis risiko.

2.7 Object Oriented Technology Object Oriented Technology merupakan cara pengembangan perangkat lunak

berdasarkan abstraksi objek-objek yang ada di dunia nyata. Dasar pembuatan adalah Objek, yang merupakan kombinasi antara struktur data dan perilaku dalam satu entitas. Filosofi Object Oriented sangat luar biasa sepanjang siklus pengenbangan perangkat lunak (perencanaan, analisis, perancangan dan implementasi) sehingga dapat diterapkan pada perancangan sistem secara umum: menyangkut perangkat lunak, perangkat keras dan sistem secara keseluruhan. Kosep-konsep Object Oriented : 1. Kelas

Kelas adalah konsep OO yang mengencapsulasi/membungkus data dan abstraksi prosedural yang diperlukan untuk menggambarkan isi dan tingkah laku berbagai entitas. Kelas juga merupakan deskripsi tergeneralisir (misl template, pola, cetak biru) yang menggambarkan kumpulan objek yang sama.

2. Objek Objek digambarkan sebagai benda, orang, tempat dan sebagainya yang ada di dunia nyata yang penting bagi suatu aplikasi. Objek mempunyai atribut dan metoda.

3. Atribut Atribut menggambarkan data yang dapat memberikan informasi kelas atau objek dimana atribut tersebut berada.

4. Metoda/Servis/Operator Metoda adalah prosedur atau fungsi yang tergabumh dalam objek bersama dengan atribut. Metode ini digunakan untuk pengaksesan terhadap data yang terdapat dalam objek tersebut.

36



5. Message Message adalah alat komunikasi antar objek. Hubungan antar objek ditentukan oleh problem domain dan tanggung jawab sistem.

6. Event Event adalah suatu kejadian pada waktu yang terbatas yang menggambarkan rangsangan (stimulus) dari luar sistem.

7. State State adalah abstraksi dari nilai atribut dan link dalam sebuah objek. State merupakan tanggapan dari objek terhadap event-event masukan.

8. Skenario Skenario adalah urutan event yang terjadi sepanjang eksekusi sistem

Karakteristik-karakteristik yang terdapat dalam metode pengembangan sistem berorientasi objek adalah: a. Encapsulation

Encapsulation merupakan dasar untuk membatasi ruang lingkup program terhadap data yang diproses. Data dan prosedur dikemas dalam suatu objek sehingga prosedur lain dari luar tidak dapat mengaksesnya. Data akan terlindungi dari prosedur atau objek lain.

b. Inheritance Inheritance (pewarisan) adalah teknik yang menyatakan bahwa anak dari objek akan mewarisi data/atribut dan metode dari induknya langsung. Suatu kelas dapat ditentukan secara umum, kemudian ditentukan secara spesifik menjadi subkelas. Setiap subkelas mempunyai hubungan atau mewarisi semua sifat yang dimiliki kelas induknya dan ditambah dengan sifat nik yang dimilikinya.

c. Polymorphism Polymorphism menyatakan bahwa sesuatu yang sama dapat mempunyai bentuk dan perilaku berbeda. Polimorfisme juga menyatakan bahwa operasi yang sama mungkin mempunyai perbedaan kelas.

Tahapan-Tahapan Object Oriented Technology Pada Object Oriented Technology ada beberapa metode yang digunakan dalam pengembangan sistem. Salah satu yang terkenal adalah OMT (Object Modelling Technique). Aktivitas-aktivitas yang dilakukan dalam OMT ini adalah:

• Model Objek • Model Dinamis • Model Fungsional

Kelebihan

• Uniformity, OMT memungkinkan merancangn user interface secara terintegrasi bersama dengan perancangan perangkat lunak sekaligus dengan perancangan basis data.

• Understandability, Kode-kode yang dihasilkan dapat diorganisasi ke dalam kelas-kels yang berhubungan dengan masalah sesungguhnya sehingga lebih mudah dipahami.

• Stability, Kode program yang dihasilkan relatif stabil sebab mendekati permasalahn sesungguhnya dilapangan.

• Reusability, Dimungkinkan penggunaan kembali kode-kode sehingga akan mempercepat waktu pengembangan perangkat lunak.

37



Kelemahan Metode berorientasi objek merupakan konsep yang relatif baru sehingga belum ada standar yang diterima semua pihak dalam menentukan tool apa yang digunakan sebagai dasar analisi serat perancangan perangkat lunak.

2.8 Metode End-user Development Disini pengembangan dilakukan langsung oleh end-user. Keterlibatan langsung end-user sangat menguntungkan, karena memahami benar bagaimana sistem bekerja. Artinya tahap analisis sistem dapat dilakukan lebih cepat. Kelemahan adalah pada pengendalian mutu dan kecenderungan tumbuhnya “private”sistem informasi. Integrasi dengan sistem yang lain menjadi sulit. Tahapan-tahapan EUD

• Tahap inisasi (initiation), Yaitu tahap dimana organisasi(perusahaan) mulai pertama kali mngenal teknologi informasi.

• Tahap ketularan (contagion) • Tahap kendali (control) • Tahap matang (mature)

Kelebihan

• Dapat menghindari permasalahan kemacetan di departemen sistem informasi. • Kebutuhan pemakai sistem dapat lebih terpenuhi karena dapat dikembangkan

sendiri oleh pemakai. • Menambah atau meningkatkan partisifasi aktif pemakai dalam proses

pengembangan sistemnya sehingga akan ada kepuasan sendiri dari pemakai sistem.

• Dapat menambah kualitas pemahaman pemakai terhadap aplikasi yang dikembangkan serta teknollogi yang digunakan dalam sistem.

Kekurangan

• Karena pemakai sistem harus mengembangkan aplikasinya sendiri, maka dalam hal ini pemakai sekaligus pengembang sistem dituntut untuk memiliki pemahaman mengenai teknologi informasi (computer literacy) serta pemahaman tentang pengembangan sistem infomasi.

• End user computing memiliki resiko dapat menggangu bahkan merusak system informasi di luar yang dikembangkan oleh pemakai sistem.

• End user computing pasti akan berhadapan dengan maslah kemampuan teknis pemakai sekaligus pengembang sistem.

38



BAB III ANALISA SISTEM INFORMASI

3.1 Pendekatan Analisi Model Driven

Analisis sistem merupakan salah satu tahapan penting dalam pengembangan sistem. Analisis sistem adalah teknik pemecahan masalah yang menguraikan bagian-bagian komponen tersebut bekerja dan berinteraksi untuk mencapai tujuan mereka (Al Fatta, 2007). Analisis sistem merupakan tahapan paling awal dari pengembangan sistem yang menjadi fondasi menentukan keberhasilan sistem informasi yang dihasilkan nantinya. Tahapan ini sangat penting karena menentukan bentuk sistem yang harus dibangun. Proses pengembangan sistem sangat tergantung pada hasisl analisis sistem. Ketika salah analaisis, maka tahapan berikutnya akan ikut salah yang bisa mengakibatkan gagalnya proses pengembangan sistem. Tahap analisis sistem merupakan fase awal dalam pengembanagan sistem informasi yang difokuskan pada permasalahan sistem lama, dan kebutuhan bisnis sistem, terlepas dari teknologi apapun yang akan digunakan untuk mengimplementasikan sousi pada masalah tersebut.

Tujuan utama dari analisis sistem informasi, adalah: 1. Menentukan kelemahan dari proses-proses bisnis pada sistem lama. 2. Menentukan kebutuhan dari sistem baru untuk mengatasi permasalahan pada sistem

lama. 3. Menentukan tingkat kelayakan kebutuhan sistem baru ditinjau dari beberapa aspek,

diantaranya ekonomi, teknik, operasional, dan hukum.

Model driven adalah analisis yang menggunakan gambar untuk mengkombinasikan masalah-masalah, persyaratan-persyaratan, dan solusi-solusi bisnis. Contoh model yang dipakai adalah flowchart dan DFD. Contoh dari analisis dengan pendekatan model driven adalah: a. Analisis Terstruktur

Analisis ini terfokus pada aliran data dan proses bisnis dan perangkat lunak yang disebut dengan process oriented. Analisis terstruktur sederhana dalam konsep. Para analis menggambarkan serangkaian proses dalam bentuk diagram alir data data flow diagram yang menggambarkan proses yang ada atau yang diusulkan bersama-sama dengan input, output dan file mereka.

b. Rekayasa Informasi dan Pemodelan Data Rekayasa informasi dulu terfokus pada struktur data yang tersimpan pada sebuah sistem yang disebut dengan data centered. Model-model data dalam rekayasa informasi disebut entity relationship. Rekayasa informasi dikatakan berpusat pada data karena menekankan pada pembelajaran dan analisis persyaratan data sebelum persyaratan- persyaratan proses. Hal ini didasarkan pada tingkat kepercayaan bahwa data dan pengetahuan adalah sumber daya perusahaan yang harus direncanakan dan dipelihara. Akibatnya analis menggambarkan model data mentah ke dalam hubungan entitas, baru kemudian membuat diagram aliran data yang menjelaskan proses-proses yang terjadi.

c. Analisis Berorientasi Objek Sebagian besar pendekatan pengembangan sistem telah memisahkan pengetahuan data dari proses. Teknik objek muncul untuk memisahkan menghilangkan pemisahan data dan proses ini. Sebaliknya data dan proses spesifik yang membuat, membaca, memperbaharui atau menghapus data itu diintegrasikan ke dalam konstruksi yang

39



disebut data atau objek. Satu-satunya cara untuk membuat, membaca, memperbaharui atau menghapus data adalah dengan cara proses perlekatan embeded yang disebut metode OOA adalah teknik yang model driven yang mengintegrasikan data dan proses yang disebut objek. Model OOA adalah gambar-gambar yang mengilustrasikan objek-objek sistem dari berbagai perspektif, seperti struktur, perilaku dan interasi antar objek. Contoh yang paling terkenal adalah UML Unified Modelling Language.

3.2 Analisis Kebutuhan Sistem

Analisis kebutuhan sistem merupakan tahapan awal dan utama untuk membuat pondasi dalam langkah pengembangan sistem. Hasil dari analisa kelemahan sistem dapat digunakan untuk merekomendasikan analisa kebutuhan sistem (requirement system) dan juga rekomendasi fungsionalitas apa saja yang dibutuhkan sistem baru. Analisis kebutuhan sistem mencakup dua hal pokok yaitu analisis kebutuhan fungsional dan analisis kebutuhan nonfungsional. Analisis kebutuhan fungsional mempunyai tujuan untuk mendapatkan informasi terkait kebutuhan yang berisi proses-proses apa saja yang nantinya dilakukan sistem informasi perwalian mahasiswa ini. Analisis kebutuhan nonfungsional mempunyai perbedaan dengan analisis sebelumnya, yaitu untuk mendapatkan informasi terkait dengan kebutuhan-kebutuhan yang meliputi properti perilaku-perilaku yang dimiliki oleh sistem

Tujuan dari analisis pebutuhan sistem yaitu memahami sebenar-benar kebutuhan sistem yang baru, yang dapat juga diartikan: 1. Pernyataan tentang apa yang harus dikerjakan oleh sistem 2. Pernyatan tentang karakterisktik yang harus dimiliki sistem Tipe tipe Kebutuhan sistem: 1. Operasional yang menjelaskan teknis bagaimana sistem baru akan beroperasi. 2. Kinerja yang menjelaskan seberapa bagus kinerja perangkat lunak yang

dikembangkan dalam mengolah data, menampilkan informasi, dan secara keseluruhan menyelesaikan proses bisnis.

3. Keamanan, berisi pernyataan tentang mekanisme pengamanan aplikasi, data, maupun transaksi yang akan diimplementasikan pada sistem.

4. Politik dan Budaya, isinya menyangkut atau berhubungan dengan isu politik dan budaya yang tidak menimbulkan persepsi negatif terhadap 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) pemakai tentang kebutuhan mereka dari sebuah sistem informasi, karena mungkin pemakai mengalami kegagalan sistem informasi sebelumnya. Tahap awal dalam requirement system 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. 3.3 Metode Pengumpulan Data

Perlunya pemilihan metode pengumpulan data yang tepat selama melakukan requirement system. Metode pengumpulan data berupa suatu pernyataan (statement) tentang sifat keadaan, kegiatan tertentu dan sejenisnya. Pengumpulan data dilakukan

40



untuk memperoleh informasi yang dibutuhkan dalam rangka mencapai tujuan penelitian (Gulo, 2002 : 110). Proses pengumpulan data (PULTA) yang dilakukan pada Pembahasan Sistem Berjalan dalam fase tahap analisa ini, merupakan proses awal yang sangat penting untuk mendapatkan data yang akurat.

Metode tersebut adalah interviews, questionnaires, observation, procedure analysis, dan document survey. Setiap metode akan dijelaskan secara mendalam sebagai berikut: 1. Tanya jawab (Interviews)

a. Bagaimana metode itu digunakan. ▪ Pemilihan potential interviewees. ▪ Membuat perjanjian terhadap potential interview. ▪ Menyiapkan struktur pertanyaan yang lengkap dan jelas. ▪ Memilih person yang di interview secara pribadi dan merekamnya.

b. Target dari metode. ▪ Kunci pribadi dalam proses DFD. ▪ Kadangkala melibatkan orang luar, seperti pelanggan atau vendors.

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

d. Kerugian metode. ▪ Membutuhkan waktu dan biaya yang tidak sedikit. ▪ Membutuhkan pelatihan dan pengalaman khusus dari pewawancara. ▪ Sulit membandingkan laporan wawancara karena subyektivitas alamiah.

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

2. Kuesioner (Questionnaires) a. Bagaimana metode itu digunakan.

▪ Mendisain dengan menggunakan standar kuesioner. ▪ Kuesioner dikirimkan ke lingkungan kerja end-users. ▪ Struktur respon diringkas dalam statistik distribusi.

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

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

41



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

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

3. Observasi (Observation)

a. Bagaimana metode itu digunakan. ▪ Secara pribadi seorang analis mengunjungi lokasi pengamatan. ▪ Analis merekam kejadian dalam lokasi pengamatan, termasuk volumen dan

pengolahan lembar kerja. b. Target dari metode.

▪ Lokasi proses secara geografis ditunjukkan dalam DFD (Data Flow Diagram) c. 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.

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

e. 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). 4. Sumber data

a. Data Primer Data penelitian yang diperoleh sendiri melalui: Wawancara, Observasi, Tes, kuesioner (Daftar Pertanyaan), Pengukuran Fisik, Percobaan Laboratorium.

b. Data Sekunder Data yang diperoleh dari sumber kedua, dokumentasi lembaga: Biro Pusat Statistik (BPS), Rumah sakit, Lembaga atau institusi.

5. Pengamatan Dokumen (Document Survey) a. 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).

42



b. Target dari metode. Aliran data kunci ditunjukkan dalam data flow diagram (DFD).

c. Keuntungan metode. ▪ Meminimalkan interupsi dari fungsi operasionalnya. ▪ Permulaan elemen kamus data. ▪ Seringkali, dapat mempertimbangkan modifikasi major procedural.

d. Kerugian metode Membutuhkan waktu yang cukup (terdapat organisasi bisnis yang mengalami kebanjiran dokumen dan laporan).

e. 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).

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

7. Dokumen Analisis Kebutuhan

a. Arahan (conduct) analisis ▪ Hubungan dengan pemakai akhir ▪ Menganalisa records, forms dan laporan ▪ Pengamatan proses. ▪ Menganalisa metode yang digunakan. ▪ Permasalahan dalam pengumpulan data. b. Kebutuhan pemakai. ▪ Apa yang menjadi kebutuhan sebenarnya. ▪ Kebutuhan laporan (jenis dan frekuensinya). ▪ Kebutuhan pelatihan. ▪ Pengaruh sistem baru. c. Kendala sistem. ▪ Menjelaskan kendala waktu, biaya, keahlian, teknologi dan faktor ekternal. ▪ Realistik sistem. d. Dokumentasi. ▪ Intrumen pengumpulan data (kebutuhan kuesioner, interview). ▪ Konsensus statistik. ▪ Aliran data secara logikal dan phisik. ▪ Element awal dalam kamus data.

3.4 Perumusan Proses Bisnis

Bisnis Proses adalah suatu kumpulan pekerjaan yang saling terkait untuk menyelesaikan suatu masalah tertentu. Suatu proses bisnis dapat dipecah menjadi beberapa subproses yang masing-masing memiliki atribut sendiri tapi juga berkontribusi untuk mencapai tujuan dari superprosesnya. Analisis proses bisnis umumnya melibatkan pemetaan proses dan subproses di dalamnya hingga tingkatan aktivitas atau kegiatan. Beberapa karakteristik umum yang dianggap harus dimiliki suatu proses bisnis adalah: a. Definitif: Suatu proses bisnis harus memiliki batasan, masukan, serta keluaran yang

jelas.

43



b. Urutan: Suatu proses bisnis harus terdiri dari aktivitas yang berurut sesuai waktu dan ruang.

c. Pelanggan: Suatu proses bisnis harus mempunyai penerima hasil proses. d. Nilai tambah: Transformasi yang terjadi dalam proses harus memberikan nilai tambah

pada penerima. e. Keterkaitan: Suatu proses tidak dapat berdiri sendiri, melainkan harus terkait dalam

suatu struktur organisasi. f. Fungsi silang: Suatu proses umumnya, walaupun tidak harus, mencakup beberapa

fungsi. Contoh Proses Bisnis 1. Pendaftaran Anggota.

Seorang calon anggota yang belum menjadi anggota perpustakaan dapat mendaftarkan diri dengan mengisi formulir pendaftaran. Setelah mengisi formulir tersebut, maka data calon anggota dapat di input kedalam sistem oleh pustakawan. Pustakawan mencetak kartu anggota dan menyerahkan ke anggota perpustakaan.

2. Pengolahan Pustakawan harus memasukkan data koleksi bahan pustaka yang dibelinya ke dalam sistem. Proses pengelolan akan dilaksanakan dan pustakawan dapat mencetak label koleksi untuk masing-masing koleksi bahan pustaka.

3. Peminjaman. Koleksi bahan pustaka yang telah melalui proses pengolahan, dapat dipinjamkan kepada anggota. Saat seorang anggota meminjam koleksi bahan pustaka, pustakawan harus memasukkan nomor keanggotaan, dan sistem akan menyimpan data peminjaman serta menampilkan form untuk menambahkan data lengkap peminjaman. Pustakawan mengisikan nomor dari koleksi bahan pustaka yang akan dipinjam dan tanggal pengembalian.

4. Pengembalian. Pustakawan harus mencatat data pengembalian, pada saat anggota mengembalikan buku pinjamannya. Pustakawan mengisikan nomor dari koleksi bahan pustaka yang dikembalikan pada form Pengembalian. Pada form ini terdapat informasi seperti anggota peminjam, koleksi bahan pustaka yang telah dipinjam tapi belum dikembalikan, tanggal pengembalian, denda yang harus dibayar, dan perpanjangan waktu peminjaman.

44



BAB IV ENTITY RELATIONSHIP DIAGRAM (ERD), SPESIFIKASI FILE

DAN PENGKODEAN 4.1 ERD (Entity Relationship Diagram)

ERD (Entity Relationship Diagram) adalah suatu model untuk menjelaskan hubungan antar data dalam basis data berdasarkan objek-objek dasar data yang mempunyai hubungan antar relasi.ERD untuk memodelkan struktur data dan hubungan antar data, untuk menggambarkannya digunakan beberapa notasi dan simbol.

Menurut salah satu para ahli, Brady dan Loonam (2010), Entity Relationship Diagram (ERD) merupakan teknik yang digunakan untuk memodelkan kebutuhan data dari suatu organisasi, biasanya oleh System Analys dalam tahap analisis persyaratan proyek pengembangan system. Sementara seolah-olah teknik diagram atau alat peraga memberikan dasar untuk desain database relasional yang mendasari sistem informasi yang dikembangkan. ERD bersama-sama dengan detail pendukung merupakan model data yang pada gilirannya digunakan sebagai spesifikasi untuk database. Atau pengertian sempitnya adalah sebuah konsep yang mendeskripsikan hubungan antara penyimpanan (database) dan didasarkan pada persepsi dari sebuah dunia nyata yang terdiri dari sekumpulan objek yaitu disebut sebagai entity dan hubungan atau relasi antar objek- objek tersebut. Tahapan ERD : • Tahap pertama pada desain sistem informasi menggunakan model ER adalah

menggambarkan kebutuhan informasi atau jenis informasi yang akan disimpan dalam database. Teknik pemodelan data dapat digunakan untuk menggambarkan setiap ontologi (yaitu gambaran dan klasifikasi dari istilah yang digunakan dan hubungan anatar informasi) untuk wilayah tertentu.

• Tahap berikutnya disebut desain logis, dimana data dipetakan ke model data yang logis, seperti model relasional. Model data yang loguis ini kemudian dipetakan menjadi model fisik , sehingga kadang-kadang, Tahap kedua ini disebut sebagai “desain fisik”.

Metodologi ERD : Tabel 2. Metode ERD

45



Simbol-simbol ERD :

Gambar16. Simbol-simbol ERD

a. Entitas

Entiti merupakan objek yang mewakili sesuatu yang nyata dan dapat dibedakan dari sesuatu yang lain. Simbol dari entiti ini biasanya digambarkan dengan persegi panjang. b. Atribut

Setiap entitas pasti mempunyai elemen yang disebut atribut yang berfungsi untuk mendes-kripsikan karakteristik dari entitas tersebut. Isi dari atribut mempunyai sesuatu yang dapat mengidentifikasikan isi elemen satu dengan yang lain. Gambar atribut diwakili oleh simbol elips.

• Atribut Key Atribut Key adalah satu atau gabungan dari beberapa atribut yang dapat membedakan

semua baris data ( Row/Record ) dalam tabel secara unik. Dikatakan unik jika pada atribut yang dijadikan key tidak boleh ada baris data dengan nilai yang sama Contoh : Nomor pokok mahasiswa (NPM), NIM dan nomor pokok lainnya

• Atribut simple atribut yang bernilai atomic, tidak dapat dipecah/ dipilah lagi Contoh : Alamat, penerbit, tahun terbit, judul buku.

• Atribut Multivalue nilai dari suatu attribute yang mempunyai lebih dari satu (multivalue) nilai dari atrribute yang bersangkutan Contoh : dari sebuah buku, yaitu terdapat beberapa pengarang.

• Atribut Composite Atribut composite adalah suatu atribut yang terdiri dari beberapa atribut yang lebih kecil yang mempunyai arti tertentu yang masih bisah dipecah lagi atau mempunyai sub attribute.

46



Contoh : dari entitas nama yaitu nama depan, nama tengah, dan nama belakang

• Atribut Derivatif Atribut yang tidak harus disimpan dalam database Ex. Total. atau atribut yang dihasilkan dari atribut lain atau dari suatu relationship. Atribut ini dilambangkan dengan bentuk oval yang bergaris putus-putus

c. Hubungan / Relasi

Hubungan antara sejumlah entitas yang berasal dari himpunan entitas yang berbeda.

Gambar17. Kardinalitas ERD

One to One (1:1) Setiap anggota entitas A hanya boleh berhubungan dengan satu anggota entitas B, begitu pula sebaliknya.

Gambar 18. One to One

One to many (1: M / Many) Setiap anggota entitas A dapat berhubungan dengan lebih dari satu anggota entitas B tetapi tidak sebaliknya.

Gambar19. One to Many

47



Many to Many (M:M) Setiap entitas A dapat berhubungan dengan banyak entitas himpunan entitas B dan demikian pula sebaliknya

Gambar 20. Many to Many

Contoh Kasus 1 : Pada saat mendaftar menjadi anggota perpustakaan Fakultas, dicatatlah nama, nomor mahasiswa dan alamat mahasiswa. Setelah itu mereka baru bisa meminjam buku di perpustakaan. Buku-buku yang dimiliki perpustakaan banyak sekali jumlahnya. Tiap buku memiliki data nomor buku, judul, pengarang, penerbit, tahun terbit. Satu buku bisa ditulis oleh beberapa pengarang. Tentukan entitas, atribut dan relasi dari deskripsi di atas, dengan menggambar ERD nya. Jawab: Entitas : Mahasiswa, KAP (Kartu Anggota Perpustakaan), Buku Atribut : Nama, no.mahasiswa, Alamat mahasiswa, No.buku, Judul, Pengarang, Penerbit dan tahun terbit. Relasi : Daftar dan Pinjam Gambar ERD dalam peminjaman buku di perpustakaan

Gambar 21. ERD Contoh Kasus 1

48



contoh Kasus 2 : Seperti soal nomor 1, namun ada beberapa tambahan penjelasan seperti berikut : Mahasiswa kadang-kadang terlambat mengembalikan buku, sehingga dikenakan denda. Besarnya denda adalah Rp 500,- per hari keterlambatan. Mahasiswa dianggap terlambat jika mengembalikan buku lebih lama dari 1 minggu. Gambarkan ERDnya:

Gambar 22. ERD contoh kasus 2

Contoh Kasus 3 : Sebuah perusahaan mempunyai beberapa bagian. Masing-masing bagian mempunyai pengawas dan setidaknya satu pegawai. Pegawai ditugaskan paling tidak di satu bagian (dapat pula dibeberapa bagian). Paling tidak satu pegawai mendapat tugas di satu proyek. Tetapi seorang pegawai dapat libur dan tidak dapat tugas di proyek. Menentukan entitas Entitasnya : pengawas, bagian, pegawai, proyek Menentukan relasi dengan matrik relasi

Tabel 3. Contoh Kasus 3

Hubungkan entitas sesuai dengan matrik relasi yang dibuat

49



Gambar 23. Hubungan Entitas contoh kasus 3

Mengisi kardinalitas Dari gambaran permasalahan dapat diketahui bahwa:

• masing-masing bagian hanya punya satu pengawas

• seorang pengawas bertugas di satu bagian

• masing-masing bagian ada minimal satu pegawai

• masing-masing pegawai bekerja paling tidak di satu bagian

• masing-masing proyek dikerjakan paling tidak oleh satu pegawai

Mengisi kardinalitas Menentukan kunci utama : Kunci utamanya: Nomor Pengawas, Nama Bagian, Nomor Pegawai, Nomor Proyek

Gambar 24. Hubungan Entitas

50



Menentukan Kunci Utama Menggambar ERD berdasarkan kunci Ada dua relasi many to many pada ERD sementara, yaitu antara bagian dengan pegawai, pegawai dengan proyek, oleh sebab itu kita buat entitas baru yaitu bagian -pegawai dan pegawai-proyek Kunci utama dari entitas baru adalah kunci utama dari entitas lain yang akan menjadi kunci tamu di entitas yang baru.

Gambar25. ERD berdasarkan Kunci

Menggambar ERD berdasarkan kunci Menentukan atribut Atribut yang diperlukan adalah: nama bagian, nama proyek, nama pegawai, nama pengawas, nomor proyek, nomor pegawai, nomor pengawas Memetakan atribut

▪ Bagian : Nama bagian ▪ Proyek: Nama proyek ▪ Pegawai:Nama pegawai ▪ Pengawas: Nama pengawas ▪ Proyek-Pegawai : Nomor proyek, Nomor pegawai ▪ Pengawas: Nomor pengawas

Menggambar ERD dengan atribut

51



Gambar 26. ERD berdasarkan Atribut

Periksa apakah masih terdapat redundasi. ERD akhir: untuk pemodelan data pada sistem. 4.2 Spesifikasi File Menjelaskan tentang file atau tabel yang terbentuk dari transformasi ERD (dan atau filefile penunjang untuk web). File-file ini tersimpan pada <<namaDatabase>> dengan parameter-parameter yang telah ditentukan. Contoh Spesifikasi File • Spesifikasi File Buku Nama File : Buku Akronim : buku.MYD Tipe File : File Master Acces File : Random Panjang Record : 250 bytes Field Key : kd_buku Software : MySQL

52



Tabel 4. Spesifikasi File

4.3 Teknik Pengkodean Kode digunakan untuk mengklasifikasikan data, memasukan data ke dalam komputer

dan untuk mengambil bermacam-macam informasi yang berhubungan dengannya. Kode dapat berupa kumpulan angka, huruf dan karakter khusus. Maksud Pengkodean : 1. Menjaga hubungan dengan sesuatu

Maksud dari pengkodean ini hanya untuk mengenali seseorang, tempat atau hanya sesuatu untuk menjaga hubungan dengan informasi yang diwakili, yaitu :

a. Urutan kode sederhana, yaitu nomor yang ditandai untuk sesuatu jika memerlukan penomoran yang tidak memerlukan hubungan dengan dirinya sendiri. Contoh: 5676 Rocking Chair/with Leather 5677Dining Room Chair/Upholstered

b. Kode Deviasi Abjad, pada umumnya dipakai pendekatan dalam identifikasi suatu nomor rekening dan untuk mencetak label surat.

53



Contoh: 15417TNG7533TGP 15417 menunjukkan kode pospelanggan YNT menujukkan nama pelanggan 7533 menujukkan alamat pelanggan TGP menujukkan kode majalah

2. Klasifikasi Informasi Menghasilkan kemampuan untuk membedakan diantara kelas-kelas item, yaitu :

a. Klasifikasi Kode, yaitu pengelompokan untuk membedaan diantara kelas-kelas item.

Contoh: kelas F

kelas S F menunjukkan Freshman 1-30 jam kredit S menunjukkan Sophomore 31-60 jam kredit

b. Blok urutan kode, yaitu untuk menbedakan satu grup data dengan karakteristik khusus lainnya yang bisa berupa hurup tunggal atau angka.

Contoh: I menunjukkan Interest Payment M menunjukkan Medical Payments

3. Merahasiakan Informasi Yang digunakan untuk merahasiakan atau menyembunyikan

informasi yang kita tidak ingin orang lain mengetahuinya, yaitu : Kode Chiper yaitu substitusi langsung satu hurup untuk lainnya, satu angka untuk lainnya atau satu hurup untuk suatu angka.

Contoh: B L E A C H M I N D

1 2 3 4 5 6 7 8 9 0 4. Mengumumkan informasi Yang digunakan untuk mengumumkan informasi melalui

suatu kode sehingga membuat informasi data lebih berarti, yaitu : a. Kode subset digit-signifikasi, yaitu memungkinkan untuk menjelaskan suatu produk

dengan baik dari kategorinya di dalam beberapa grup. contoh: 202-395-40-10 202= Departement, 395 = Produk 40 = Warna 10 = Ukuran

b. Kode Mnemonik, yaitu menggunakan kombinasi hurup dan simbol untuk mudah diingat dan dimengerti

Contoh: BDG = Bandung JKT= Jakarta

Petunjuk Pembuatan Kode 1. Meringkas 2. Menjaga kode tidak berubah 3. Memastikan bahwa kode adalah unik

54



4. Membiarkan kode dapat diurut 5. Menghindari kode yang mirip 6. Menjaga kode yang seragam 7. Membolehkan modifikasi kode 8. Membuat kode berarti 9. Menggunakan kode Contoh Format Kode

Gambar 27. Format Pengkodean

55



BAB V UNIFIED MODELLING LANGUAGE (UML)

5.1 Terminologi UML

UML (Unified Modeling Language) adalah sebuah bahasa yang berdasarkan grafik/ gambar untuk memvisualisasi, menspesifikasikan, membangun, dan pendokumentasian dari sebuah sistem pengembangan software berbasis OO (Object-Oriented). UML sendiri juga memberikan standar penulisan sebuah sistem blue print, yang meliputi konsep bisnis proses, penulisan kelas-kelas dalam bahasa program yang spesifik, skema database, dan komponenkomponen yang diperlukan dalam sistem software. UML adalah salah satu tool / model untuk merancang pengembangan software yang berbasis object oriented. UML sebagai sebuah bahasa yang memberikan vocabulary dan tatanan penulisan kata-kata dalam ‘MS Word’ untuk kegunaan komunikasi. Sebuah bahasa model adalah sebuah bahasa yang mempunyai vocabulary dan konsep tatanan / aturan penulisan serta secara fisik mempresentasikan dari sebuah sistem.

UML adalah sebuah bahasa standard untuk pengembangan sebuah software yang dapat menyampaikan bagaimana membuat dan membentuk model-model, tetapi tidak menyampaikan apa dan kapan model yang seharusnya dibuat yang merupakan salah satu proses implementasi pengembangan software. UML tidak hanya merupakan sebuah bahasa pemograman visual saja, namun juga dapat secara langsung dihubungkan ke berbagai bahasa pemograman, seperti JAVA, C++, Visual Basic, atau bahkan dihubungkan secara langsung ke dalam sebuah object-oriented database. Begitu juga mengenai pendokumentasian dapat dilakukan seperti; requirements, arsitektur, design, source code, project plan, tests, dan prototypes. Untuk dapat memahami UML membutuhkan bentuk konsep dari sebuah bahasa model, dan mempelajari 3 (tiga) elemen utama dari UML seperti building block, aturan-aturan yang menyatakan bagaimana building block diletakkan secara bersamaan, dan beberapa mekanisme umum (common). Hubungan / Relationship. Ada 4 macam hubungan didalam penggunaan UML, yaitu;

1. Dependency, adalah hubungan semantik antara dua benda/things yang mana sebuah benda berubah mengakibatkan benda satunya akan berubah pula. Umumnya sebuah dependency digambarkan sebuah panah dengan garis terputus-putus.

2. Association, hubungan antar benda struktural yang terhubung diantara obyek. Kesatuan obyek yang terhubung merupakan hubungan khusus, yang menggambarkan sebuah hubungan struktural diantara seluruh atau sebagian. Umumnya assosiation digambarkan dengan sebuah garis yang dilengkapi dengan sebuah label, nama, dan status hubungannya.

3. Generalizations, adalah menggambarkan hubungan khusus dalam obyek anak/child yang menggantikan obyek parent / induk. Dalam hal ini, obyek anak memberikan pengaruhnya dalam hal struktur dan tingkah lakunya kepada obyek induk. Digambarkan dengan garis panah.

4. Realizations, merupakan hubungan semantik antara pengelompokkan yang menjamin adanya ikatan diantaranya. Hubungan ini dapat diwujudkan diantara interface dan kelas atau elements, serta antara use cases dan collaborations. Model dari sebuah hubungan realization.

56



Bagan/Diagram UML sendiri terdiri atas pengelompokkan diagram-diagram sistem menurut aspek atau

sudut pandang tertentu. Diagram adalah yang menggambarkan permasalahan maupun solusi dari permasalahan suatu model. UML mempunyai 9 diagram, yaitu; use-case, class, object, state, sequence, collaboration, activity, component, dan deployment diagram.

1. Use Case Diagram, menggambarkan sekelompok use cases dan aktor yang disertai dengan hubungan diantaranya. Diagram use cases ini menjelaskan dan menerangkan kebutuhan / requirement yang diinginkan/ dikehendaki user/pengguna, serta sangat berguna dalam menentukan struktur organisasi dan model dari pada sebuah sistem.

2. Class Diagram, yang memperlihatkan struktur statis dari kelas actual didalam sistem.

3. Object Diagram, yang merupakan varian dari kelas diagram yang memperlihatkan lebih detail banyaknya obyek yang mengintantiasi (instances) kelas.

4. State Diagram, yang memperliatkan semua keadaan (state) yang dapat dimiliki oleh kelas dan event yang dapat merubah keadaan tersebut.

5. Sequence Diagram, yang memperlihatkan kolaborasi dinamik antara objek-objek dengan suatu urutan pesan (a sequence of message) antar objek tersebut.

6. Collaboration Diagram, yang memperlihatkan kolaborasi dinamik antar objek tanpa memperhatikan aspek waktu.

7. Activity Diagram, yang memperlihatkan aliran urutan aktifitas. 8. Component Diagram, yang memperlihatkan struktur fisik dari source code dalam

terminology code components. Komponen berisi informasi tentang logical class dapat berupa komponen source code, komponen biner atau komponen yang dapat dieksekusi.

9. Deployment Diagram, yang memperlihatkan arsitektur fisik dari hardware dan software pada sistem.

Pemecahan masalah utama dari Object Oriented biasanya dengan penggambaran dalam bentuk model. Model abstrak (semu) merupakan gambaran detail dari inti masalah yang ada, umumnya sama seperti refleksi dari problem yang ada pada kenyataan. Beberapa modeling tool yang dipakai adalah bagian dari dasar UML, kependekan dari United Modeling Language.

Semakin kompleks bentukan sistem yang akan dibuat, maka semakin sulit komunikasi antara orang-orang yang saling terkait dalam pembuatan dan pengembangan software yang akan dibuat. Pada masa lalu, UML mempunyai peranan sebagai software blueprint (gambaran) language untuk analisis sistem, designer, dan programmer. Sedangkan pada saat ini, merupakan bagian dari software trade (bisnis software). UML memberikan jalur komunikasi dari sistem analis kemudian designer, lalu programmer mengenai rancangan software yang akan dikerjakan. Salah satu pemecahan masalah Object Oriented adalah dengan menggunakan UML. Oleh karena itu orang-orang yang berminat dalam mempelajari UML harus mengetahui dasar-dasar mengenai Object Oriented Solving (pemecahan masalah OO). Tahap pertama, pembentukan model. Model adalah gambaran abstrak dari suatu dasar masalah. Dan dunia nyata atau tempat dimana masalah itu timbul bisa disebut dengan domain. Model mengandung obyek-obyek yang beraktifitas dengan saling mengirimkan messages (pesan-pesan). Obyek mempunyai sesuatu yang diketahui (atribut /attributes) dan sesuatu yang dilakukan (behaviors atau operations). Attributes hanya berlaku dalam ruang lingkup obyek itu sendiri (state). Lalu “blue print” dari suatu obyek adalah Classes (kelas). Obyek merupakan bagian-bagian dari kelas.

57



5.2 Diagram Use Case Diagram Use Case menggambarkan apa saja aktifitas yang dilakukan oleh suatu

sistem dari sudut pandang pengamatan luar. yang menjadi persoalan itu apa yang dilakukan bukan bagaimana melakukannya. Diagram Use Case dekat kaitannya dengan kejadian-kejadian. Kejadian (scenario) merupakan contoh apa yang terjadi ketika seseorang berinteraksi dengan sistem. untuk lebih memperjelas lihat gambaran suatu peristiwa untuk sebuah klinik kesehatan di bawah ini : “Pasien menghubungi klinik untuk membuat janji (appointment) dalam pemeriksaan tahunan. Receptionist mendapatkan waktu yang luang pada buku jadwal dan memasukkan janji tersebut ke dalam waktu luang itu.” contoh kegiatan pasien yang membuat janji.

Gambar 28. Contoh Use Case Kegiatan Pasien Membuat Janji Diagram Use Case berguna dalam tiga hal :

1. Menjelaskan fasilitas yang ada (requirements) Use Case baru selalu menghasilkan fasilitas baru ketika sistem di analisa, dan design menjadi lebih jelas.

2. Komunikas dengan klien Penggunaan notasi dan simbol dalam diagram Use Case membuat pengembang lebih mudah berkomunikasi dengan klien-kliennya.

3. Membuat test dari kasus-kasus secara umum Kumpulan dari kejadian-kejadian untuk Use Case bisa dilakukan test kasus layak untuk kejadian-kejadian tersebut.

5.3 Diagram Class

Diagram Class memberikan pandangan secara luas dari suatu sistem dengan menunjukan kelas-kelasnya dan hubungan mereka. Diagram Class bersifat statis; menggambarkan hubungan apa yang terjadi bukan apa yang terjadi jika mereka berhubungan. Diagram Class mempunyai 3 macam relationalships (hubungan), sebagai berikut :

1. Association Suatu hubungan antara bagian dari dua kelas. Terjadi association antara dua kelas jika salah satu bagian dari kelas mengetahui yang lainnya dalam melakukan suatu kegiatan. Di dalam diagram, sebuah association adalah penghubung yang menghubungkan dua kelas.

2. Aggregation Suatu association dimana salah satu kelasnya merupakan bagian dari suatu kumpulan. Aggregation memiliki titik pusat yang mencakup keseluruhan bagian. Sebagai contoh : OrderDetail merupakan kumpulan dari Order.

3. Generalization Suatu hubungan turunan dengan mengasumsikan satu kelas merupakan suatu superClass (kelas super) dari kelas yang lain. Generalization memiliki tingkatan yang berpusat pada superClass. Contoh : Payment adalah superClass dari Cash, Check, dan Credit.

58



Untuk tambahan bahwa association mempunyai 2 titik. Salah satu titik bisa memiliki label untuk menjelaskan association tersebut, contoh : OrderDetail adalah line Item untuk setiap permintaan.

Panah navigability (pengatur alur arah) dalam suatu association menggambarkan arah mana association dapat ditransfer atau disusun. Seperti dalam contoh : OrderDetail dapat disusun dari item-nya, namun tidak bisa sebaliknya. Panah ini juga menjelaskan siapa “memiliki” implementasi dari association; dalam kasus ini OrderDetail memiliki Item. Association tanpa arah panah merupakan bidirectional (bolak-balik).

Multiplicity dari suatu titik association adalah angka kemungkinan bagian dari hubungan kelas dengan single instance (bagian) pada titik yang lain. Multiplicity berupa single number (angka tunggal) atau range number (angka batasan). Pada contoh, hanya bisa satu ‘Customer’ untuk setiap ‘Order’, tapi satu ‘Customer’ hanya bisa memiliki beberapa ‘Order’.

Tabel di bawah mengenai multiplicity yang sering digunakan :

Tabel 5. Multiplicity

Setiap diagram Class memiliki Class (kelas), association, dan multiplicity. Sedangkan navigability (alur arah) dan role (kegiatan) merupakan optional (tidak diharuskan). Contoh Diagram Class transaksi Pembelian barang.

Gambar 29. Contoh Diagram Class transaksi Pembelian barang.

59



5.4 Package dan Object Untuk mengatur pengorganisasian diagram Class yang kompleks, dapat dilakukan

pengelompokan kelas-kelas berupa package (paket-paket). Package adalah kumpulan elemen-elemen logika UML. Gambar di bawah ini mengenai model bisnis dengan pengelompokan kelas-kelas dalam bentuk paket-paket :

Gambar 30. Contoh Pengelompokan Kelas

Ada jenis khusus dari diagram Class yaitu diagram Object. Kegunaannya untuk penjelasan yang sedikit dengan relasi yang sulit, khususnya relasi rekursif. Lihat gambar dibawah, diagram Class kecil menunjukkan bahwa ‘department’ dapat mengandung banyak ‘department’ yang lain.

Gambar 31. Contoh Diagram Class kecil Setiap tingkatan pada diagram berpengaruh pada single instance (bagian tunggal). Nama bagian digarisbawahi dalam diagram UML. Untuk Class name (nama kelas) maupun instance name (nama bagian) bisa mengambil dari diagram Object selama arti diagram tersebut masih jelas.

60



Gambar 32. Contoh diagram Class 5.5 Diagram Sequence

Diagram Class dan diagram Object merupakan suatu gambaran model statis. Namun ada juga yang bersifat dinamis, seperti Diagram Interaction. Diagram sequence merupakan salah satu diagram Interaction yang menjelaskan bagaimana suatu operasi itu dilakukan; message (pesan) apa yang dikirim dan kapan pelaksanaannya. Diagram ini diatur berdasarkan waktu. Obyek-obyek yang berkaitan dengan proses berjalannya operasi diurutkan dari kiri ke kanan berdasarkan waktu terjadinya dalam pesan yang terurut. Di bawah ini adalah diagram Sequence untuk pembuatan Hotel Reservation. Obyek yang mengawali urutan message adalah ‘aReservation Window’.

Contoh 33. Diagram Sequence ‘Pemesanan kamar di Hotel’. ‘Reservation window’ mengirim pesan makeReservation() ke ‘HotelChain’. Kemudian ‘HotelChain’ mengirim pesan yang sama ke ‘Hotel’. Bila ‘Hotel’ punya kamar kosong, maka dibuat ‘Reservation’ dan ‘Confirmation’. Lifeline adalah garis dot (putus-putus) vertikal pada gambar, menerangkan waktu terjadinya suatu obyek. Setiap panah yang ada adalah pemanggilan suatu pesan. Panah berasal dari pengirim ke bagian paling atas dari batang kegiatan (activation bar) dari suatu pesan pada lifeline penerima. Activation bar menerangkan lamanya suatu pesan diproses. Pada gambar diagram, terlihat bahwa ‘Hotel’ telah melakukan pemanggilan diri sendiri untuk pemeriksaan jika ada kamar

61



kosong. Bila benar, maka ‘Hotel’ membuat ‘Reservation’ dan ‘Confirmation’. Pemanggilan diri sendiri disebut dengan iterasi. Expression yeng dikurung dengan “[ ]”, adalah condition (keadaan kondisi). Pada diagram dapat dibuat note (catatan). Pada gambar, terlihat seperti selembar kertas yang berisikan teks. Note bisa diletakan dimana saja pada diagram UML. 5.6 Diagram Collaboration

Diagram Collaboration juga merupakan diagram interaction. Diagram membawa informasi yang sama dengan diagram Sequence, tetapi lebih memusatkan atau memfokuskan pada kegiatan obyek dari waktu pesan itu dikirimkan.

Contoh 34. Diagram Collaboration ‘Pemesanan kamar di Hotel’.

Kotak kegiatan obyek diberi label dengan nama kelas atau obyek (atau keduanya). Nama kelas dibatasi dengan colons /titik dua ( : ). Setiap pesan pada diagram Collaboration mempunyai angka yang terurut. Pesan yang tingkatannya tertinggi adalah angka 1. Pesan yang berada pada tingkat yang sama memiliki prefix yang sama, namun suffix berbeda bergantung pada posisinya; hanya untuk angka 1, 2, dan seterusnya. 5.7 Diagram StateChart Behaviors dan state dimiliki oleh obyek. Keadaan dari suatu obye kbergantung pada kegiatan dan keadaan yang berlaku pada saat itu. Diagram StateChart menunjukan kemungkinan dari keadaan obyek dan proses yang menyebabkan perubahan pada keadaannya. Untuk lebih jelas, contoh yang digunakan model diagram untuk login yang merupakan bagian dari Online Banking System. Logging in terdiri atas masukan input Social Security Number dan Personal Id Number yang berlaku, lalu memutuskan kesahan dari informasi tersebut.

62



Contoh 35. Diagram StateChart ‘Sistem Perbankkan secara Online’

Logging in dapat dibagi menjadi empat tahapan proses, yaitu :

• Getting SSN (masukkan SSN),

• Getting PIN (masukkan PIN),

• Validating (periksa kesahannya), dan

• Rejecting (keluar).

Proses peralihan digambarkan dengan panah dari satu state ke yang lainnya. Event (peristiwa) atau condition (keadaan) yang menyebabkan perubahan dituliskan pada samping panah. Diagram ini mengandung dua self-transition (transisi sendiri), satu pada getting SSN dan lainnya pada getting PIN. Keadaan awal Start (black circle /lingkar hitam) adalah dummy (model) untuk memulai action (kegiatan). Keadaan akhir juga keadaan model yang menghentikan kegiatan. Aksi yang terjadi sebagai hasil dari suatu peristiwa atau keadaan ditandai dalam bentuk /action. Pada Validating State, obyek tidak menunggu peristiwa dari luar untuk menyebabkan suatu perubahan. Sebagai gantinya melakukan suatu activity (aktifitas). Hasil dari aktifitas tersebut menentukan keadaan berikutnya dari obyek tersebut. 5.8 Diagram Activity

Pada dasarnya diagram Activity sering digunakan oleh flowchart. Diagram ini berhubungan dengan diagram Statechart. Diagram Statechart berfokus pada obyek yang dalam suatu proses (atau proses menjadi suatu obyek), diagram Activity berfokus pada aktifitas-aktifitas yang terjadi yang terkait dalam suatu proses tunggal. Jadi dengan kata lain, diagram ini menunjukkan bagaimana aktifitas-aktifitas tersebut bergantung satu sama lain. Sebagai contoh, perhatikan proses yang terjadi. “Pengambilan uang dari bank melalui ATM.” Ada tiga aktifitas kelas (orang, dan lainnya) yang terkait yaitu : Customer, ATM, and Bank. Proses berawal dari lingkaran start hitam pada bagian atas dan berakhir di pusat lingkaran stop hitam/putih pada bagian bawah. Aktivitas digambarkan dalam bentuk kotak persegi. Lihat gambar di bawah ini, agar lebih jelas :

63



Contoh 36. Diagram Activity ‘Pengambilan Uang melalui ATM’.

Diagram Activity dapat dibagi menjadi beberapa jalur kelompok yang menunjukkan obyek yang mana yang bertanggung jawab untuk suatu aktifitas. Peralihan tunggal (single transition) timbul dari setiap adanya activity (aktifitas), yang saling menghubungi pada aktifitas berikutnya. Sebuah transition (transisi) dapat membuat cabang ke dua atau lebih percabangan exclusive transition (transisi eksklusif). Label Guard Expression (ada di dalam [ ]) yang menerangkan output (keluaran) dari percabangan. percabangan akan menghasilkan bentuk menyerupai bentuk intan. transition bisa bercabang menjadi beberapa aktifitas paralel yang disebut Fork. Fork beserta join (gabungan dari hasil output fork) dalam diagram berbentuk solid bar (batang penuh).

64



5.9 Diagram Component dan Deployment Component adalah sebuah code module (kode-kode module). Diagram Component

merupakan fisik sebenarnya dari diagram Class. Diagram Deployment menerangkan bahwa konfigurasi fisik software dan hardware. Gambar 2.10 menerangkan hubungan sekitar komponen software dan hardware yang berperan dalam ruang lingkup real estate.

Contoh 37. Diagram Deployment ‘Sistem Real Estate’

Fisik hardware berbentuk seperti node-node. Setiap komponen merupakan bagian dari node. Pada gambar komponen berbentuk dua kotak tersusun yang terletak di sebelah kiri atas.

65



BAB VI ANALISA PERANCANGAN INPUT DAN OUTPUT

6.1 Perancangan INPUT

Merupakan awal dimulainya proses informasi. Bahan mentah dari informasi adalah data yang terjadi dari transaksi-transaksi yang dilakukan oleh organisasi. Formulir adalah perangkat penting untuk mengendalikan aliran kerja dan digunakan untuk menangkap (capture) data yang terjadi sering juga disebut Dokumen Dasar.

Tujuan perancangan input : a. Membuat penyelesaian input yang mudah dan efisien b. Menjamin input akan memenuhi tujuan yang diharapkan c. Menjamin penyelesaian yang tepat. d. Membuat tampilan layar dan formulir yang menarik e. Membuat input yang tidak rumit f. Membuat tampilan layar dan formulir yang konsisten

Terdapat beberapa hal yang perlu diperhatikan dari dokumen dasar. A. Fungsi dokumen dasar :

1. Dapat menunjukan macam dari data 2. Dapat dicatat dengan jelas, konsisten dan akurat 3. Bertindak sebagai pendistribusian data 4. Membantu pembuktian terjadinya transaksi 5. Dapat digunakan sebagai back up 6. Petunjuk merancang dokumen dasar 7. Kertas yang digunakan 8. Ukuran dari dokumen dasar 9. Warna yang digunakan 10. Judul dokumen dasar 11. Nomor dokumen dasar 12. Nomor urut dokumen dasar 13. Nomor dan jumlah halaman 14. Spasi 15. Pembagian area 16. Caption, yaitu box caption, yes no chech off caption, horizontal check off caption,

blocked spaces caption, scannable from caption B. Instruksi dalam dokumen dasar :

1. Membuat formulir mudah diisi, yaitu dengan memperhatikan aliran formulir, pengelompokan tujuh bagian sebuah formulir, pembuatan judul.

2. Memastikan bahwa formulir akan memenuhi tujuan yang telah dibuat 3. Membuat formulir yang memastikan penyelesaian tepat. 4. Buatlah formulir yang menarik

C. Cara mengurangi masukan

Ada beberapa cara yang dapat digunakan untuk mengurangi jumlah masukan, cara yang dapat dilakukan adalah : 1. menggunakan kode 2. data yang relatif konstan yang disimpan di file induk 3. jam dan tanggal dapat diambil dari sistem 4. rutin perhitungan dilakukan oleh sistem.

66



D. Rancangan Input di Screen

Contoh 38. Contoh Rancangan Input

6.2 Perancangan OUTPUT Rancangan Output merupakan hasil dari adanya inputan data yang akan diberikan kepada entitas luar. Output adalah informasi yang dikirim kepada pengguna melalui sistem informasi yang dapat berupa : Print, Screen, Audio, CD-ROM or CD-RW, DVD, E-mail, World Wide Web, Electronic output. Tujuan dibuat rancangan output adalah :

a. Merancang output untuk tujuan tertentu b. Membuat output bermanfaat bagi para pengguna c. Mengirim jumlah output yang tepat d. Menyediakan distribusi output yang tepat e. Menyediakan output tepat waktu f. Memilih metoda output yang paling tepat dan paling efektif

Tipe output :

a. Output internal b. Output eksternal

67



a. Bentuk Laporan 1. Laporan berbentuk tabel

• Notice Report : merupakan bentuk laporan yang memerlukan perhatian khusus. Laporan ini harus dibuat sesederhana mungkin, tetapi jelas, karena dimaksudkan supaya permasalahan-permasalahan yang terjadi tampak dengan jelas sehingga dapat langsung ditangani.

Tabel 6. Contoh. Notice Report

LAPORAN PENURUNAN PENJUALAN MENURUT

JENIS BARANG BULAN DESEMBER 2017

• Equiposed Report : Laporan ini biasanya digunakan untuk maksud perencanaan. Dengan disajikannya informasi yang berisi hal-hal bertentangan, maka dapat dijadikan sebagai dasar di dalam pengambilan keputusan.

Tabel 7. Contoh. Equipost Report

LAPORAN PERENCANAAN MEMASUKI PASAR YANG BARU

DAERAH PONTIANAK UNTUK TAHUN FISKAL 2017

Penjualan Jelek Baik

Rp 1.000.000 Rp 1.750.000

Harga pokok penjualan Rp 600.000 Rp 1.050.000

Laba Kotor Rp 400.000 Rp 700.000

Biaya penjualan Rp 300.000 Rp 350.000

Biaya Administrasi Rp 125.000 Rp 150.000

Laba (Rugi) (Rp 25.000) Rp 200.000

• Variance Report : Macam laporan ini menunjukkan selisih (variance) antara standar yang sudah ditetapkan dengan hasil kenyataannya atau sesungguhnya.

Daerah Penjualan X Penurunan

Pontianak 10,00 X

Kubu Raya 45,00 X

Singkawang 12,50 X

68



Tabel 8. Contoh. Variance Report

LAPORAN KINERJA DEPARTEMEN PEMBELIAN

BULAN DESEMBER 2017

Barang di Beli Unit

di Beli

Harga Sesungguhnya Harga Standar Selisih Harga Total Selisih

IBM PC XT 10 1.200.000 1.050.000 150.000 1.500.000 R

Monitor Color 8 415.000 365.000 50.000 400.000 R

Hard Disk 30 MB 5 595.000 625.000 30.000 150.000 L

Total 170.000 1.750.000 R

• Comparative Report : membandingkan antara satu hal dengan hal yang lainnya. Misalnya pada laporan rugi/laba atau neraca dapat dibandingkan antara nilai- nilai elemen tahun berjalan dengan tahun-tahun sebelumnya.

Tabel 9. Contoh Comparative Report

NERACA

31 DESEMBER 2017

(DALAM RIBUAN RUPIAH)

AKTIVA 31-12-2016 31-12-2017 Selisih

Aktiva lancar 45.000 75.000 30.000 66,67%

Aktiva Tetap 155.000 225.000 70.000 45,16%

Total Aktiva 200.000 300.000 100.000 50,00 %

PASIVA

Hutang Lancar 10.000 15.000 5.000 50,00 %

Hutang Jangka

Panjang 37.500 30.000 (7.500) (20,00%)

Modal Saham 130.000 200.000 70.000 53,85%

Latta ditahan 22.500 55.000 32.500 144,44%

Total Pasiva 200.000 300.000 100.000 50,00%

2. Laporan berbentuk grafik

• Garis Pada bagan garis (line chart), variasi dari data ditunjukkan dengan suatu garis atau kurva

• Batang Nilai-nilai data dalam bagan batang (bar chart ) digambarkan dalam bentuk batang-batang vertikal ataupun batang-batang horisontal.

69



• Pastel Bagan pastel (pie chart) merupakan bagan yang berbentuk lingkaran menyerupai kue pastel (pie). Tiap tiap potong dari pie dapat menunjukkan bagian dari data.

b. Mengatur tata letak isi output :

Cara penggambaran bagan tata letak printer : 1. Bentuk dari literal dapat ditulis apa adanya 2. Nilai suatu data yang berasal dari suatu field atau variabel ditunjukan oleh bentuk

edit-mask 3. Nomor dapat digunakan sebagai acuan nilai data di kamus data output 4. Panah kebawah menunjukan cara penggambaran spasi di bagan tata letak printer,

yaitu :

• Spasi tunggal

• Spasi dua/lebih

• Dengan baris tertentu

• Kombinasi percetakan

Langkah-langkah untuk menyiapkan prototipe output berbasis layar : 1. Menentukan kebutuhan akan laporan tersebut. 2. Menentukan pengguna. 3. Menentukan item-item data yang dimasukan 4. Mengestimasi ukuran laporan secara keseluruhan 5. Judul laporan 6. Nomor halaman 7. Memasukan tanggal persiapan laporan 8. Memberi label setiap kolom data secara tepat. 9. Menentukan data-data varabel 10. Menunjukan tempat baris-baris kosong 11. Mengulas laporan-laporan prototype

Petunjuk untuk merancang layar : 1. Buatlah layar yang sederhana 2. Buatlah presentasi layar tetap konsisten 3. Fasilitasi gerakan pengguna di antara layar 4. Ciptakan suatu layar yang menarik

70



BAB VII PENGUJIAN PERANGKAT LUNAK DAN PEMELIHARAAN SISTEM

7.1 PENGUJIAN PERANGKAT LUNAK

Pengujian perangkat lunak (bahasa Inggris: software testing) merupakan suatu investigasi yang dilakukan untuk mendapatkan informasi mengenai kualitas dari produk atau layanan yang sedang diuji (under test). Pengujian perangkat lunak memberikan pandangan mengenai perangkat lunak secara obyektif dan independen. Pengujian Perangkat Lunak adalah elemen kritis dari jaminan kualitas perangkat lunak dan merepresentasikan kajian pokok dari spesifikasi, desain dan pengkodean. Dasar-dasar Pengujian Perangkat Lunak

Pengembang perangkat lunak sesuai dengan sifatnya dasar mereka adalah manusia pembangun. Pengujian mengharuskan pengembang membuang pemikiran-pemikiran sebelumnya mengenai “kebenaran” perangkat lunak yang baru saja dikembangkan dan mengatasi konflik minat yang terjadi pada saat kesalahan ditemukan. Sasaran Pengujian

1. Pengujian adalah proses eksekusi suatu program dengan maksud menemukan kesalahan.

2. Test case yang baik adalah test case yang memiliki probabilitas tinggi untuk menemukan kesalahan yang belum pernah ditemukan sebelumnya.

3. Pengujian yang sukses adalah pengujian yang mengungkapkan semua kesalahan yang belum pernah ditemukan sebelumnya.

Prinsip Pengujian

1. Semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan. 2. Pengujian harus direncanakan lama sebelum pengujian itu mulai. 3. Prinsip Pareto berlaku untuk pengujian perangkat lunak. 4. Pengujian harus mulai “dari yang kecil” dan berkembang menjadi pengujian

“yang besar” 5. Pengujian yang mendalam tidak mungkin. 6. Untuk menjadi paling efektif, pengujian harus dilakukan oleh pihak ketiga yang

independen. Karakteristik pengujian perangkat lunak :

1. Operabilitas, Semakin baik dia bekerja, semakin efisien dia dapat diuji. 2. Obsaikervabilitas, “Apa yang anda lihat adalah apa yang anda uji”. 3. Kontralabilitas, “Semakin baik kita dapat mengontrol perangkat lunak, semakin

banyak pengujian yang dapat diotomasisasi dan dioptimalkan”. 4. Dekomposabilitas, “Dengan mengontrol ruang lingkup pengujian, kita dapat dengen

lebih cepat mengisolasi masalah dan melakukan pengujian kembali secara lebih halus”.

5. Kesederhaaan, “Semakin sedikit yang kita uji, semakin cepat kita dapat mengujinya 6. Stabilitas, “Semakin sedikit perubahan, semakin sedikit gangguan dalam

pengujian’. 7. Kemampuan untuk dapat dipahami, “Semakin banyak informasi yang kita miliki,

semakin halus pengujian yang akan dilakukan’.

71



Tujuan Pengujian 1. Menemukan kesalahan (fault) sebanyak mungkin dari perangkat lunak yang diuji 2. Membuat perangkat lunak yang diuji, setelah perbaikan dilakukan, menjadi

perangkat lunak yang berkualitas 3. Melakukan pengujian secara efektif dan efisien 4. Mengumpulkan kesalahan yang terjadi dan menggunakannya untuk tindakan

preventif Strategi Pengujian

1. Big Bang Pengujian perangkat lunak secara keseluruhan, setelah seluruh komponen perangkat lunak selesai dibuat

2. Incremental Pengujian secara bertahap

Gambar 39. Strategi Pengujian

1. Unit testing: pengujian komponen individual (modul dipemrograman prosedural atau

class di OOP). 2. Integration testing: pengujian terhadap koleksi dari komponen-komponen yang bekerja

bersamaan. 3. Validation testing: pengujian aplikasi terhadap kebutuhan pengguna. 4. System testing: pengujian aplikasi secara keseluruhan.

Gambar 40. Strategi Incremental

72



Atribut-atribut pengujian yang baik : 1. Pengujian yang baik memiliki probabilitas yang tinggi untuk menemukan kesalahan. 2. Pengujian yang baik tidak redudan. 3. Pengujian yang baik seharusnya “jenis terbaik”, 4. Pengujian yang tidak boleh terlalu sederhana atau terlalu kompleks.

Desain Test Case Desain test case merupakan metode pengujian untuk perangkat lunak untuk memastikan kelengkapan pengujian dan memberikan kemungkinan tertinggi untuk mengungkap kesalahan pada perangkat lunak. Semua produk yang direkayasa dapat diuji dengan satu atau dua cara:

1. Dengan mengetahui fungsi yang ditentukan dimana produk yang dirancang untuk melakukanya, pengujian dapat dilakukan untuk memperlihatkan bahwa masing-masin fungsi beroperasi sepenuhnya, pada waktu yang sama mencari kesalahan pada setiap fungsi.

2. Dengan mengetahui kinerja internal suatu produk, maka pengujian dapat dilakukan untuk memastikan bahwa semua roda gigi berhubungan, yaitu operasi internal bekerja sesuai dengan spesifikasi dan semua komponen internal telah diamati dengan baik.

Metode Pengujian Perangkat Lunak 1. Black-box testing

▪ Mengetahui fungsi tertentu suatu produk yang telah dirancang untuk dijalankan, menguji untuk melihat apakah fungsi sepenuhnya bisa beroperasi dan bebas dari error.

▪ Test dilakukan termasuk interface perangkat lunak ▪ Tidak peduli dengan struktur logis internal dari perangkat lunak

2. White-box testing

▪ Mengetahui kerja internal dari suatu produk, tes yang semua operasi internal dilakukan sesuai dengan spesifikasi dan semua komponen internal telah dieksekusi

▪ Melibatkan test yang berkonsentrasi pada pemeriksaan detail prosedural ▪ Logical patch perangkat lunak diuji ▪ Uji kasus latihan dari kondisi dan loop tertentu

Gambar 41. Metode Pengujian Perangkat Lunak

73



7.2 Pengujian Functional (Black Box) Menurut Sukamto & Shalahuddin (2015:275-276), “Black-box Testing yaitu menguji

perangkat lunak dari segi spesifikasi fungsional tanpa menguji perangkat lunak dari segi spesifikasi fungsional tanpa menguji desain dan kode program”.

1. Fokus pada output yang dihasilkan dengan memberikan input dan kondisi eksekusi 2. Membandingkan kesesuaian output dengan spesifikasi kebutuhan fungsional

Gambar 42. Pengujian Fuctional

3. Melengkapi pengujian white box dengan mengungkap kelas yang berbeda dari kesalahan

4. Berfokus pada persyaratan fungsional dan domain informasi dari perangkat lunak 5. Digunakan selama tahap akhir dari pengujian setelah white box testing telah

dilakukan 6. Tester mengidentifikasi serangkaian kondisi masukan yang sepenuhnya akan

melaksanakan semua persyaratan fungsional untuk program 7. Memenuhi uji kasus berikut:

▪ Mengurangi, dengan jumlah lebih besar dari satu, jumlah uji kasus tambahan harus dirancang untuk mencapai pengujian yang wajar

▪ Mampu memberitahukan tentang keberadaan atau tidak adanya kelas kesalahan, yang terkait hanya dengan tugas tertentu.

8. Salah atau hilang fungsi 9. Kesalahan Interface 10. Kesalahan pada struktur data atau akses database eksternal 11. Perilaku atau kinerja kesalahan 12. Inisialisasi dan terminasi kesalahan

Pengujian blackbox berusaha menemukan :

1. Fungsifungsi yang tidak benar atau hilang 2. Kesalahan interface 3. Kesalahan dalam struktur data atau akses database eksternal. 4. Kesalahan kinerja 5. Inisialisasi dan kesalahan terminasi.

74



Dengan mengaplikasikan teknik blackbox maka kita menarik serangkaian test case yang memenuhi kriteria beirkut:

1. Test case yang mengurangi, dengan harga lebih dari satu, jumlah test case tambahan yang harus didesain untuk mencapai pengujian yang dapat dipertanggung jawabkan

2. Test case yang memberi tahu kita sesuatu mengenai kehadiran atau ketidak hadiran kelas kesalahan, daripada member tahu kesalahan yang berhubungan hanya dengan pengujian spesifik.

Kelebihan Black Box Testing

1. Dapat memilih subset test secara efektif dan efisien 2. Dapat menemukan cacat 3. Memaksimalkan testing investmen

Kelemahan Black Box Testing Tester tidak pernah yakin apakah Perangkat Lunak tersebut benar – benar lulus uji. 7.3 Pengujian Struktural (White Box)

Pengujian White Box adalah metode desain test case yang menggunakan struktur control desain procedural untuk memperoleh test case. Disebut juga pengujian glassbox. Pengujian white box adalah pengujian yang didasarkan pada pengecekan terhadap detil perancangan, menggunakan struktur kontrol dari desain program secara procedural untuk membagi pengujian ke dalam beberapa kasus pengujian Dengan pengujian whitebox, perekayasa dapat melakukan:

1. Memberikan jaminan bahwa semua jalur independen pada suatu modul telah digunakan paling tidak satu kali.

2. Menggunakan semua keputusan logis pada sisi true and false. 3. Mengeksekusi semua loop pada batasan mereka dan pada batas operasional

mereka. 4. Menggunakan struktur data internal untuk menjamin validitasnya.

Kelebihan White Box Testing

1. Kesalahan logika. Digunakan pada sintaks ‘if’ dan pengulangan. Dimana White Box Testing akan mendeteksi kondisi-kondisi yang tidak sesuai dan mendeteksi kapan proses pengulangan akan berhenti.

2. Ketidaksesuaian asumsi. Menampilkan asumsi yang tidak sesuai dengan kenyataan, untuk di analisa dan diperbaiki.

3. Kesalahan ketik. Mendeteksi bahasa pemrograman yang bersifat case sensitive.

Kelemahan White Box Testing Untuk perangkat lunak yang tergolong besar, White Box Testing dianggap sebagai

strategi yang tergolong boros, karena akan melibatkan sumber daya yang besar untuk melakukannya 7.4 Pengujian Basis Path

Pengujian basis path adalah teknik uji coba white box yg diusulkan Tom McCabe. Metode ini memungkinkan perancang test case mendapatkan ukuran kompleks logical dari perancangan prosedural dan menggunakan ukuran ini sebagai petunjuk untuk mendefinisikan himpunan jalur (Basis Set) yang akan diuji. Basis Path menggunakan

75



notasi graph atau flow graph untuk menggambarkan aliran kontrolnya. Test case yang dilakukan untuk menggunakan basis set tersebut dijamin untuk menggunakan setiap statemen di dalam program paling tidak sekali selama pengujian. Notasi yang digunakan untuk menggambarkan jalur eksekusi adalah notasi diagram alir (atau grafik program), yang menggunakan notasi lingkaran (simpul atau node) dan anak panah (link atau edge). Notasi ini menggambarkan aliran control logika yang digunakan dalam suatu bahasa pemrograman. Perangkat yang digunakan :

a) Notasi Diagram Alir

Tabel 10. Notasi Diagram Alir

Untuk menggambarkan pemakaian diagram alir diberikan contoh perancangan prosedural dalam bentuk flowchart

Gambar 43. Diagram Alir

76



Selanjutnya diagram alir diatas dipetakan ke grafik alir

Gambar 44. Grafik Alir b) Cyclomatic Complexity (Kompleksitas Siklomatis)

Cyclomatic complexity adalah metrik PL yang menyediakan ukuran kuantitatif dari kekompleksan logikal program. Apabila digunakan dalam kontek metode uji coba basis path, nilai yang dihitung untuk cyclomatic complexity menentukan jumlah jalur independen dalam basis set suatu program dan memberi batas atas untuk jumlah uji coba yang harus dikerjakan untuk menjamin bahwa seluruh perintah sekurang-kurangnya telah dikerjakan sekali. Pada Basis Path Testing, hasil dari cyclomatic complexity digunakan untuk menentukan banyaknya independent paths. Independent path adalah sebuah kondisi pada program yang menghubungkan node awal dengan node akhir. c) Melakukan Test Case

Metode uji coba basis path juga dapat diterapkan pada perancangan prosedural rinci atau program sumber. Pada bagian ini akan dijelaskan langkah-langkah uji coba basis path. Langkah-Iangkah pembuatan test case:

1. Dengan mempergunakan perancangan prosedural atau program sumber sebagai dasar, digambarkan diagram alirnya.

2. Tentukan cyclomatic complexity untuk diagram alir yang telah dibuat. 3. Tentukan independent path pada flowgraph 4. Buat test case yang akan mengerjakan masing-masing path pada basis set. Data

yang dipilih harus tepat sehingga setiap kondisi dari predicate node dikerjakan semua. d) Graph Metrik Graph metrik merupakan PL yang dikembangkan untuk membantu uji coba basis path atau struktur data. Graph metrik adalah matrik empat persegi yang mempunyai ukuran (sejumlah baris dan kolom) yang sama dengan jumlah node pada flowgraph. Masing-masing baris dan kolom mempunyai hubungan dengan node yang telah ditentukan dan pemasukan data matrik berhubungan dengan hubungan (edge) antanode

77



DAFTAR PUSTAKA

Adhani, M., Abdillah, L. A., & Widayati, Q. (2015). Analisa dan perancangan sistem informasi penerimaan siswa baru dan pembayaran SPP menggunakan Zachman Framework. Seminar Nasional Informatika 2015 (SNIf2015). Universitas Potensi Utama

Akbar, F., Setiaji, S., Ishak, R., Saputra, D., & Masruri, B. (2020). RANCANG BANGUN SISTEM

INFORMASI KARANG TARUNA MENGGUNAKAN METODE WATERFALL. Jurnal Khatulistiwa Informatika, 8(1).

Al Fatta, H. (2007). Analisis dan Perancangan Sistem Informasi untuk keunggulan bersaing

perusahaan dan organisasi modern. Penerbit Andi. Bell, D. (2003). UML basics: An introduction to the Unified Modeling Language. The Rational Edge. Gaol Jimmy, L. (2008). Sistem Informasi Manajemen: Pemahamanan Aplikasi. PT Grasindo. Ibrahim, N., Ibrahim, R., Saringat, M. Z., Mansor, D., & Herawan, T. (2011). Definition of

Consistency Rules between UML Use Case and Activity Diagram. International Conference on Ubiquitous Computing and Multimedia Applications, 498–508. Springer.

Jogiyanto, H. M. (2017). Analisis dan Desain (Sistem Informasi Pendekatan Terstruktur Teori dan

Praktek Aplikasi Bisnis). Penerbit Andi. Kendall, K. E., & Kendall, J. E. (2018). Analisis dan Perancangan sistem. Jakarta: PT INDEKS

Kelompok GRAMEDIA. Li, Q., & Chen, Y.-L. (2009). Entity-relationship diagram. In Modeling and Analysis of Enterprise

and Information Systems (pp. 125–139). Springer. Mulyani, S. (2017). Metode Analisis dan Perancangan Sistem. Abdi Sistematika. Nidhra, S., & Dondeti, J. (2012). Black box and white box testing techniques-a literature review.

International Journal of Embedded Systems and Applications (IJESA), 2(2), 29–50. Quatrani, T., & Evangelist, U. M. L. (2003). Introduction to the Unified modeling language. A

Technical Discussion of UML, 6(11), 3. Raymond Jr, M. (2001). Sistem Informasi Manajemen Studi Sistem Informasi Berbasis Komputer.

Versi Bahasa Indonesia, Edisi Ketujuh Jilid II, PT. Prenhallindo, Jakarta. Saputra, D., Irmayani, W., & Martias, M. (2019). PERANCANGAN SISTEM PELAYANAN

KESEHATAN (SIYANA) PADA PUSKESMAS MENSIKU DESA BINJAI HULU KABUPATEN SINTANG KALIMANTAN BARAT. Jurnal Mantik Penusa, 3(3).

Saputra, D., Irmayani, W., Martias, M., Sidauruk, J., Haryani, H., Jayanti, W. E., Rahman, A.

(2020). Application of Web-Based Competency Test (UKSI) with Framework Code Igniter (CI). International Journal of Advanced Science and Technology, 29(No.4 (2020)), 4500–4520. Retrieved from http://sersc.org/journals/index.php/IJAST/article/view/24856

Sukamto, R. A., & Shalahuddin, M. (2018). Rekayasa Perangkat Lunak (Edisi Revisi). Bandung:

Informatika Bandung. Sutabri, T. (2012). Analisis sistem informasi. Penerbit Andi.

78

ANALISA & PERANCANGAN SISTEM INFORMASI · berkaitan dengan Analisa & Perancangan Sistem Informasi...

Documents

Transcript of ANALISA & PERANCANGAN SISTEM INFORMASI · berkaitan dengan Analisa & Perancangan Sistem Informasi...