• Tidak ada hasil yang ditemukan

Setelah 3NF, semua masalah normalisasi hanya melibatkan tabel yang mempunyai tiga kolom atau lebih dan semua kolom adalah kunci. Banyak praktisi berpendapat bahwa menempatkan entitas pada 3NF sudah cukup karena sangat jarang entitas yang berada pada 3NF bukan merupakan 4NF dan 5NF.

25 5. Bentuk Normal Tahap Keempat dan Kelima

Sebuah table relasional berada pada bentuk normal keempat (4NF) jika didalam BCNF dan semua ketergantungan multivalue merupakan ketergantungan fungsional. Bentuk normal keempat (4NF) didasarkan pada konsep ketergantungan multivalue (MVD). Sebuah table berada pada bentuk normal kelima (5NF) jika ia tidak dapat mempunyai dekomposisi loss less menjadi sejumlah table lebih kecil. Empat bentuk normal pertama berdasarkan pada konsep ketergantungan fungsional, sedangkan bentuk normal kelima berdasarkan pada konsep ketergantungan gabungan (join dependence) (Janner Simarmata ; 2010 : 76). 23 2.10.2. UML (Unified Modeling Language)

Menurut Windu Gata (2013:4) Hasil pemodelan pada OOAD terdokumentasikan dalam bentuk Unified Modeling Language(UML). UML adalah bahasa spesifikasi standar yang dipergunakan untuk mendokumentasikan, menspesifikasikan dan membangun perangkat lunak.

UML merupakan metodologi dalam mengembangkan sistem berorientasi objek dan juga merupakan alat untuk mendukung pengembangan sistem.UML saat ini sangat banyak dipergunakan dalam dunia industri yang merupakan standar bahasa pemodelan umum dalam industri perangkat lunak dan pengembangan sistem. Alat bantu yang digunakan dalam perancangan berorientasi objek berbasiskan UML adalah sebagai berikut :

1. Use case Diagram

Use case diagram merupakan pemodelan untuk kelakukan (behavior) sistem informasi yang akan dibuat. Use case mendeskripsikan sebuah interaksi

26 antara satu atau lebih aktor dengan sistem informasi yang akan dibuat. Dapat dikatakan use case digunakan untuk mengetahui fungsi apa saja yang ada di dalam sistem informasi dan siapa saja yang berhak menggunakan fungsi-fungsi tersebut. Adapun Simbol-simbol yang digunakan dalam usecase diagram, yaitu :

Tabel 2.1 Simbol-simbol Use Case

Simbol Keterangan

Use case menggambarkan

fungsionalitas yang disediakan sistem sebagai unit yang bertukan pesan antar unit dengan aktor, biasanya dinyatakan dengan menggunakan kata kerja di awal nama usecase

Aktor adalah abstractiondari orang atau sistem yang lain yang mengaktifkan fungsi dari target sistem. Untuk mengidentifikasikan aktor, harus ditentukan pembagian tenaga kerja dan tugas-tugas yang berkaitan dengan peran pada konteks target sistem. Orang atau sistem bisa muncul dalam

27 beberapa peran. Perlu dicatat bahwa aktor berinteraksi dengan usecase, tetapi tidak memiliki control terhadap use case.

Asosiasi antara aktor dan use case, digambarkan dengan garis tanpa panah yang mengindikasikan siapa atau apa yang meminta interaksi secara langsung dan bukannya mengidikasikan aliran data.

Asosiasi antara aktor dan use case yang menggunakan panah terbuka untuk mengidinkasikan bila aktor berinteraksi secara pasif dengan system

Include, merupakan di dalam usecase lain (required) atau pemanggilan use case oleh usecase lain, contohnya adalah pemanggilan sebuah fungsi program.

Extend, merupakan perluasan dari use case lain jika kondisi atau syarat terpenuhi.

28 (Sumber : Windu Gata ; 2013 : 4)

2. Diagram Aktivitas (Activity Diagram)

Activity Diagram menggambarkan workflow (aliran kerja) atau aktivitas dari sebuah sistem atau proses bisnis. Adapun simbol-simbol yang digunakan dalam activity diagram, yaitu :

Tabel 2.2 Simbol Activity Diagram

Simbol Keterangan

Start point, diletakkan pada pojok kiri atas dan merupakan awal aktifitas.

Endpoint, akhir aktifitas.

Activites, menggambarkan suatu proses/kegiatan bisnis.

Join (penggabungan) atau rake, digunakan untuk menunjukkan adanya dekomposisi.

Fork(Percabangan), digunakan untuk menunjukkan kegiatan yang dilakukan secara parallel atau untuk menggabungkan dua kegiatan pararel

29 menjadi satu.

DecisionPoints, menggambarkan pilihan untuk pengambilan keputusan, true, false

Swimlane, pembagian activity diagram untuk menunjukkan siapa melakukan apa.

Tabel 2.2 Simbol Activity Diagram (Sumber : Windu Gata ; 2013 : 6) 3. Diagram Urutan (Sequence Diagram)

Sequence diagram menggambarkan kelakuan objek pada use case dengan mendeskripsikan waktu hidup objek dan pesan yang dikirimkan dan diterima antar

objek. Adapun simbol-simbol yang digunakan dalam sequence diagram, yaitu : Tabel 2.3 Simbol Sequence Diagram

Simbol Keterangan

EntityClass, merupakan bagian dari sistem yang berisi kumpulan kelas berupa entitas-entitas yang membentuk gambaran awal sistem dan menjadi landasan untuk menyusun basis data.

30 Boundary Class, berisi kumpulan kelas yang menjadi interface atau interaksi antara satu atau lebih aktor dengan sistem, seperti tampilan formentry dan form cetak.

Control class, suatu objek yang berisi logika aplikasi yang tidak memiliki tanggung jawab kepada entitas, contohnya adalah kalkulasi dan aturan bisnis yang melibatkan berbagai objek Message, simbol mengirim pesan antar class.

Recursive, menggambarkan pengiriman pesan yang dikirim untuk dirinya sendiri.

Activation, activationmewakili sebuah eksekusi operasi dari objek, panjang kotak ini berbanding lurus dengan durasi aktivitas sebuah operasi.

31 Lifeline, garis titik-titik yang terhubung dengan objek, sepanjang lifelineterdapat activation.

Tabel 2.3 Simbol Sequence Diagram (Sumber : Windu Gata ; 2013 : 7)

4. Class Diagram (Diagram Kelas)

Merupakan hubungan antar kelas dan penjelasan detail tiap-tiap kelas di dalam model desain dari suatu sistem, juga memperlihatkan aturan-aturan dan tanggng jawab entitas yang menentukan perilaku sistem. Class diagram juga menunjukkan atribut-atribut dan operasi-operasi dari sebuah kelas dan constraint yang berhubungan dengan objek yang dikoneksikan. Class diagram secara khas meliputi: Kelas (Class), Relasi, Associations, Generalization dan Aggregation, Atribut (Attributes), Operasi (Operations/Method), Visibility, tingkat akses objek eksternal kepada suatu 27 operasi atau atribut. Hubungan antar kelas mempunyai keterangan yang disebut dengan multiplicity atau kardinaliti.

Tabel 2.4 Multiplicity Class Diagram

Multiplicity Penjelasan

1 Satu dan hanya satu

0..* Boleh tidak ada atau satu atau lebih

32 0..1 Boleh tidak ada, maksimal 1

n..n

Batasan antara. Contoh 2..4 mempunyai arti minimal 2 maksimum 4

Tabel 2.4 Multiplicity Class Diagram (Sumber : Windu Gata ; 2013 : 9)

33 2.11 DFD ( Data Flow Diagram )

Data Flow Diagram (DFD) adalah suatu diagram yang menggunakan notasi-notasi untuk menggambarkan arus dari data sistem, yang penggunaannya sangat membantu untuk memahami sistem secara logika, tersruktur dan jelas. DFD merupakan alat bantu dalam menggambarkan atau menjelaskan sistem yang sedang berjalan logis.

2.11.1 Kesatuan Luar

Merupakan kesatuan lingkungan di luar sistem yang dapat berupa orang, organisasi atau sistem lainnya yang berada di lingkungan luarnya yang akan memberikan input atau menerima output dari sistem.

2.11.2 Arus Data

Arus data ini mengalir diantara proses, simpanan data dan kesatuan luar. Arus data ini menunjukkan arus dari data yang dapat berupa masukan untuk sistem atau hasil dari proses sistem. Arus data ini ditunjukkan dengan simbol panah. Proses Suatu proses adalah kegiatan atau kerja yang dilakukan oleh orang, mesin atau komputer dari hasil suatu arus data yang masuk ke dalam proses untuk menghasilkan arus data yang akan keluar dari proses.

2.11.3 Simpan Data

Simpanan data merupakan simpanan dari data yang dapat berupa: a. Suatu file atau database di sistem komputer

b. Suatu arsip atau catatan manual

c. Suatu kotak tempat data di meja seseorang d. Suatu tabel acuan manual

34

e. Suatu agenda atau buku

2.11.4 Diagram Konteks

Menggambarkan satu lingkaran besar yang dapat mewakili seluruh proses yang terdapat di dalam suatu sistem. Merupakan tingkatan tertinggi dalam DFD dan biasanya diberi nomor 0 (nol). Semua entitas eksternal yang ditunjukkan pada diagram konteks berikut aliran-aliran data utama menuju dan dari sistem. Diagram ini sama sekali tidak memuat penyimpanan data dan tampak sederhana untuk diciptakan.

2.11.5 Diagram Nol (diagram level-1)

Merupakan satu lingkaran besar yang mewakili lingkaran-lingkaran kecil yang ada di dalamnya. Merupakan pemecahan dari diagram Konteks ke diagram Nol. di dalam diagram ini memuat penyimpanan data.

2.11.6. Diagram Rinci

Merupakan diagram yang menguraikan proses apa yang ada dalam diagram Nol.

2.11.7 Fungsi DFD

Data Flow Diagram (DFD) adalah alat pembuatan model yang memungkinkan profesional sistem untuk menggambarkan sistem sebagai suatu jaringan proses fungsional yang dihubungkan satu sama lain dengan alur data, baik secara manual maupun komputerisasi.

DFD ini adalah salah satu alat pembuatan model yang sering digunakan, khususnya bila fungsi-fungsi sistem merupakan bagian yang lebih penting dan kompleks dari pada data yang dimanipulasi oleh sistem. Dengan kata lain, DFD

35

adalah alat pembuatan model yang memberikan penekanan hanya pada fungsi sistem.

DFD ini merupakan alat perancangan sistem yang berorientasi pada alur data dengan konsep dekomposisi dapat digunakan untuk penggambaran analisa maupun rancangan sistem yang mudah dikomunikasikan oleh profesional sistem kepada pemakai maupun pembuat program.

2.11.8 DFD Logis

Adalah representasi grafik dari sebuah sistem yang menunjukkan proses-proses dalam sistem tersebut dan aliran-aliran data ke dalam dan ke luar dari proses-proses tersebut. Kita menggunakan DFD logis untuk membuat dokumentasi sebuah sistem informasi karena DFD logis dapat mewakili logika tersebut, yaitu apa yang dilakukan oleh sistem tersebut, tanpa perlu menspesifikasi dimana, bagaimana, dan oleh siapa proses-proses dalam sistem tersebut dilakukan. Keuntungan dari DFD logis dibandingkan dengan DFD fisik adalah dapat memusatkan perhatian pada fungsi-funsi yang dilakukan sistem. Perlu diperhatikan di dalam pemberian Keterangan/ Label; Lingkaran-lingkaran (simbol proses) menjelaskan apa yang dilakukan sistem. Misal : Menerima Pembayaran,

Mencatat Penjualan, Membandingkan kas dan Daftar Penerimaan,

36 2.12 Waterfall

Waterfall adalah suatu proses pengembangan perangkat lunak berurutan, di mana kemajuan dipandangsebagai terus mengalir ke bawah (seperti air terjun) melewati fase-fase perencanaan, pemodelan, implementasi(konstruksi), dan pengujian. Waterfall model pertama kali diperkenalkanoleh Winston Royce tahun 1970. Waterfall Model merupakan model klasik yang sederhana dengan aliran sistem yang linier. Output dari setiap tahap merupakan input bagi tahap berikutnya.

Model ini telah diperoleh dari proses rekayasa lainnya dan menawarkan cara pembuatan rekayasa perangkat lunak secara lebih nyata.

2.12.1 Tahapan Metode Waterfall

Dalam pengembangannya metode waterfall memiliki beberapa tahapan yang runtut: requirement, design,implementation, verification dan maintenance.

1. Tahap requirement atau spesifikasi kebutuhan sistem adalah analisa kebutuhan sistem yang dibuat dalam bentuk yang dapat dimengerti oleh klien dan staf pengembang. Dalam tahap ini klien atau pengguna menjelaskan segala kendala dan tujuan serta mendefinisikan apa yang diinginkan dari sistem. Setelah dokumen spesifikasi disetujui maka dokumen tersebut menjadi kontrak kerja antara klien dan pihak pengembang.

37 2. Tahap selanjutnya adalah desain, dalam tahap ini pengembang akan menghasilkan sebuah arsitektur sistem secara keseluruhan, dalam tahap ini menentukan alur perangkat lunak hingga pada tahapalgoritma yang detil. 3. Selanjutnya tahap implementasi, yaitu tahapan dimana keseluruhan desain

diubah menjadi kode-kode program. kode program yang dihasilkan masih berupa modul-modul yang selanjutnya akan di integrasikanmenjadi sistem yang lengkap untuk meyakinkan bahwa persyaratan perangkat lunak telah dipenuhi.

4. Tahap selanjutnya adalah verifikasi oleh klien, klien menguji apakah sistem tersebut telah sesuai dengan kontrak yang telah disetujui.

5. Tahap akhir adalah pemeliharaan yang termasuk diantaranya instalasi dan proses perbaikan sistem sesuai kesepakatan.

2.12.2 Manfaat Metode Waterfall

Keunggulan model pendekatan pengembangan software dengan metode waterfall adalah pencerminan kepraktisanrekayasa, yang membuat kualitas software tetap terjaga karena pengembangannya yang terstruktur dan terawasi.Disisi lain model ini merupakan jenis model yang bersifat dokumen lengkap, sehingga proses pemeliharaan dapatdilakukan dengan mudah. Akan tetapi dikarenakan dokumentasi yang lengkap dan sangat teknis, membuat pihak klien sulit membaca dokumen yang berujung pada sulitnya komunikasi antar pengembang dan klien. Dokumentasi kode program yang lengkap juga secara tak langsung menghapus ketergantungan pengembang terhadap pemrogram yang keluar dari tim pengembang. Hal ini sangat menguntungkan bagi pihak

38 pengembang dikarenakan proses pengembangan perangkat lunak tetap dapat dilanjutkan tanpa bergantung pada pemrogram tertentu.

2.12.3 Kelemahan Metode Waterfall

Kelemahan pengembangan software dengan metode waterfall yang utama adalah lambatnya prosespengembangan perangkat lunak. Dikarenakan prosesnya yang satu persatu dan tidak bisa diloncat-loncatmenjadikan model klasik ini sangat memakan waktu dalam pengembangannya. Disisi lain, pihak klien tidak dapatmencoba sistem sebelum sistem benar-benar selesai pembuatannya. Kelemahan yang lain adalah kinerja personil yang tidak optimal dan efisien karena terdapat proses menunggu suatu tahapan selesai terlebih dahulu.Secara keseluruhan model pendekatan pengembangan software dengan metode waterfall cocok untuk pengembangan software / perangkat lunak dengan tingkat resiko yang kecil, dan memiliki ukuran yang kecil serta waktu pengembangan yang cukup panjang. Model ini tidak disarankan untuk ukuran perangkat lunak yang besar dantingkat resiko yang besar.

2.13 Black box testing

Black box testing adalah pengujian yang dilakukan hanya mengamati hasil eksekusi melalui data uji dan memeriksa fungsional dari perangkat lunak. Jadi dianalogikan seperti kita melihat suatu koatak hitam, kit hanya bisa melihat penampilan luarnya saja, tanpa tau ada apa dibalik bungkus hitam nya.

Input Output

Executable Program

39 Gambar 2.5 Bentuk simbol Black box testing

Metode ini dinamai demikian karena program perangkat lunak, di mata penguji, seperti kotak hitam; di dalam yang orang tidak bisa melihat. Metode ini mencoba menemukan kesalahan dalam kategori berikut:

Fungsi salah atau tidak ada

Kesalahan antarmuka

Kesalahan dalam struktur data atau akses database eksternal

Kesalahan perilaku atau kinerja

Inisialisasi dan terminasi kesalahan.

2.14 Metode Pengembangan Sistem

Pada tahap ini dilakukan pengembangan sistem dengan menggunakan model waterfall. Model yang mengusulkan sebuah pendekatan perangkat lunak yang sistematik dan sekuensial yang dimulai pada tingkat dan kemajuan sistem pada seluruh analisis, desain, kode, pengujian, dan pemeliharaan. Pengembangan sistem bisa disebut juga SDLC ( Software Development Life Cycle ) adalah proses pengembangan atau mengubah suatu sistem perangkat lunak dengan menggunakan model-model dan metodologi yang digunakan orang untuk megembangkan sistem-sistem perangkat lunak sebelumnya. SDLC memiliki beberapa model dalam penerapan tahapan prosesnya, salah satunya adalah Model metode waterfall yang sering disebut metode air terjun, sering juga disebut model sekuensial linier ( Sequential linier ) atau alur hidup klasik ( classic 36 life cycle ).

40 Model air terjun ini ( waterfall ) menyediakan pendekatan alur hidup perangkat lunak secara sekuensial atau terurut dimulai dari analisis kebutuhan, desain sistem, penulisan kode program,pengujian program dan tahap penerapan program dan pemeliharaan. Model air terjun ini merupakan struktur tahap pengembangan sistem jelas, dokumentasi dihasilkan di setiap tahap pengembangan, dan sebuah tahap dijalankan setelah tahap sebelumnya selesai dijalankan. Model waterfall ini adalah model SDLC yang paling sederhana, model ini hanya cocok untuk pengembangan perangkat lunak dengan spesifikasi tidak berubah-ubah.

41 BAB III

Dokumen terkait