ERD dan Normalisasi

ERD merupakan alat bantu untuk visualisasi pemodelan data. ERD berperan penting dalam melakukan pemodelan data logis. Seperti kita kita bersama, pemodelan data logis sangat penting dalam proses perancangan basis data. ERD juga sangat membantu dalam melakukan normalisasi data.

Pemodelan logic data dikembangkan dalam beberapa tahapan sebagai berikut:

1) Context ERD atau Model Data Konteks

Model data ini digunakan untuk menentukan lingkup proyek yang tidak terlalu detail dalam membahas entitas dan aturan bisnis. Banyak hubungan  tersebut mungkin non- spesifik.

Berikut adalah sebuah contoh Context ERD yang menjelaskan mengenai sebuah proses bisnis yang melibatkan entitas-entitas seperti customer, customer order, customer transaction, product dan product_type.

2) Model Data Key-Based

Pada model data key-based, kita telah mulai menyertakan attribute data yang memiliki primary key, foreign key dan entitas asosiatif yang ada. 

Apabila terdapat 2 buah tabel yang mempunyai hubungan many-to-many, maka kedua tabel ini harus dipisahkan dengan cara menambah sebuah tabel diantaranya. Kemudian berikan relevan key di setiap tabelnya dan jangan lupa untuk mengganti notasi kardinalitas pada ketiga tabel tersebut.

Lihat pada contoh gambar diatas. 

Tabel ‘member_order’ and ‘product’ mempunyai hubungan many-to-many. Kedua tabel ini harus dipisahkan dengan menambahkan sebuah tabel dan namakan tabel tersebut ‘member_ordered_product’. Tabel baru ini berisi 2 primary keys yaitu  member_order_id (table member_order) dan product_id (table product). 

Jika ingin memudahkan pengkodean, anda dapat menambahkan sebuah primary key lainnya dan namakan key tersebut ‘member_ordered_product_id (pk)’ di mana key ini mempunyai fungsi yang sama dengan member_order_id (pk) and product_id (pk). Akan tetapi, bila hal ini dilakukan, anda harus mengganti ‘member_ordered_product_id (pk)’ menjadi ‘member_ordered_product_id (fk) dan ‘product_id (pk)’ menjadi ‘product_id (fk)’.

3) Model Data Fully-Attributed

Model data fully-attributed adalah model data logic yang menyertakan semua atribut deskriptif secara menyeluruh.

Lihat pada Gambar dibawah

4) Normalized Data Model

Normalised data model adalah model data logis yang telah melalui proses normalisasi. Pada dasarnya normalisasi adalah suatu teknik pengorganisasian data ke dalam tabel-tabel untuk memenuhi kebutuhan pengguna. Tujuannya untuk mernghilangkan kerangkapan data, mengurangi kompleksitas data dan mempermudah modifikasi data.

Secara singkat tahapan Normalisasi adalah sebagai berikut:

1. Bentuk Normal Tahap Pertama (1st Normal Form)

Pada bentuk ini, semua elemen yang berulang pada suatu entitas      dihapuskan. Dalam 1st Normal Form tidak ada elemen data yang muncul beberapa kali untuk satu entitas tertentu.

2. Bentuk Normal Tahap Kedua (2nd Normal Form)

Dalam bentuk ini pastikan bahwa atribut descriptor bergantung pada seluruh composite key untuk identifikasi.

3. Bentuk Normal Tahap Ketiga (3rd Normal Form)

Dipastikan bahwa nilai atribut tidak bergantung pada nilai atribut lain dalam entitas yang sama.

Pada contoh gambar kita sebelumnya, semua atribut yang ada pada table-tabel di atas sudah normal, maka dari itu tidak perlu dilakukan normalisasi. Jika dalam situasi yang berbeda di mana harus dilakukan normalisasi terhadap tabel-tabel tertentu, pergunakanlah aturan normalisasi dengan benar. Setelah dilakukan normalisasi, maka gabungkan kembali tabel yang sudah dinormalisasi dengan tabel lainnya. 

5) Physical Database Schema

Untuk menggambarkan bagian ini, maka harus mengambil gabungan tabel yang sudah dinormalisasi sebelumnya. Kemudian tambahkan data type dan data length pada setiap atribut yang ada pada tabel-tabel tersebut. Apabila ada batasan-batasan yang harus diketahui, maka hal ini harus dideskripsikan secara singkat pada skema basis.
Lihat contohnya pada Gambar dibawah ini:

Semua Gambar diambil dari buku teks System Analysis and Design for the Global Enterprise - Bentley & Whitten, 7th ed, 2007

Data Flow Diagram

Pemodelan sistem informasi sering dilakukan dengan menggunakan DFD (Data Flow Diagram). Sebelum berkembang pemodelan berorientasi obyek yang menggunakan UML, maka tools DFD sangat sering digunakan. Dalam hubungan dengan metodologi pengembangan sistem informasi maka DFD sering digunakan pada metode Waterfall.
O’brien (1999) menjelaskan bahwa DFD merupakan diagram yang mendemonstrasikan cara data diproses oleh system . Bocij, Chaffey, Greasley, dan Hickie (2003) menjelaskan  diagram konteks merupakan pola penggambaran yang berfungsi untuk memperlihatkan interaksi sistem informasi tersebut dan lingkungan di mana sistem tersebut ditempatkan.
Simbol-simbol yang digunakan dalam DFD menurut DeMarco dan Yourdon, adalah sebagai berikut:

Gambar Simbol-Simbol DFD

Sumber:  Bentley & Whitten, System Analysis and Design for the Global Enterprise 7th ed, 2007

Penjelasan simbol-simbol tersebut dikutip dari McLeod (2001):
1) Arus Data (Data Flow) merupakan kumpulan elemen-elemn data, yang berhubungan secara logis yang bergerak dari satu titik atau process ke titik atau proses lain. Tanda panah menyatakan arah hubungan antar elemen data tersebut
2) Entitas Eksternal (External Entity(, yakni entitas yang berada diluar sistem, tetapi bisa memberikan masukan bagi sistem dan menerima keluaran dari sistem.
3) Proses (Process), adalah sesuatu yang mengubah masukan menjadi keluaran. Tiap proses memiliki satu atau lebih data masukan dan menghasilkan satu atau lebih data keluaran.
4) Penyimpanan Data (Data Storage). Dalam istilah DFD, data store adalah merupakan suatu tempat penyimpanan data.

Berikut adalah aturan mengenai penggambaran Diagram Konteks dan DFD level-n:
Aturan Diagram Konteks:
1. Gunakan satu simbol proses
2. Berikan nama atau label pada simbol proses tersebut untuk menggambarkan seluruh sistem.
3. Tidak menomori simbol proses tersebut.
4. Menyertakan semua extenal entity dari sistem.
5. Menunujukkan semua data flow antara teminator dan sistem.

Aturan Diagram Gambar-n
Diagram gambar-n mendokumentasikan satu proses DFD secara lebih tinggi. Huruf n menggambarkan jumlah proses pada tingkat selanjutnya yang lebih tinggi yang sedang didokumentasikan.
Tahapan Pembuatan DFD
1. Beri label tiap arus data (data flow) dengan nama yang unik.
2. Jaga agar nama arus data tetap dari satu tingkat ke tingkat lain.
3. Tunjukkan penempatan yang tepat bagi catatan-catatan yang dihapuskan dari penyimpanan data.
4. Saat mendokumentasikan program komputer jangan menyertakan proses membaca dan menulis.
5. Hindari proses membaca saja (read-only process).
6. Proses membaca saja diijinkan jika waktu berfungsi sebagai pemicu

Aturan Penggambaran DFD

Berikut saya berikan contoh langkah-langkah untuk menggambar DFD:
1) Menggambar Functional decomposition diagram (FDD)
2) Menggambar Context DFD (Level 0)
3) Menggambar DFD Level 1
4) Menggambar DFD Level 2 … Level n (Event diagrams)
Contoh kasus adalah sebuh Proses Sales Processing!

Gambar FDD

Gambar Context Diagram

Gambar DFD Level 1

Gambar DFD Level 2

Sebuah contoh lainnya tentag Pemodelan menggunakan DFD dapat dilihat disini ....

Eliminasi Gauss

Praktikum Metode Numerik
Modul 5 Metode Eliminasu Gauss
BAB I
TUJUAN DAN DASAR TEORI

I.1. Tujuan
1) Menguasai metode eliminasi gauss yang digunakan dalam komputasi numerik
2) Memahami algoritma pemrograman untuk merancang program metode eliminasi gauss yang ada dalam komputasi numerik
3) Menerapkan algoritma untuk perancangan dan pembuatan program metode eliminasi gauss.

II.2. Dasar Teori
Berikut ini dipaparkan metode 2 langkah dalam menyelesaikan persamaan dengan Gaussian Eliminasi.

Langkah ke-1:
Melakukan proses triangulasi = mengubah matriks A menjadi matriks segitiga (hal ini akan mengubah matriks B)

Langkah ke-2:
Melakukan substitusi mundur, yaitu: menghitung x mengikuti urutan terbalik, dari yang terakhir (Xn ) sampai yang pertama (X1 )

Modul selengkapnya dapat diunduh disini

Metodologi RAD - Rapid Application Development

Metodologi RAD merupakan salah satu metodologi pengembangan perangkat lunak yang "cepat". RAD merupakan hasil adaptasi dari Waterfall yang dirasakan cukup lama. Saya pernah membimbing seorang mahasiswa KP/TA dengan menggunakan metodologi RAD dalam mengembangkan aplikasi berbasis web. 

Berikut adalah catatan saya mengenali langkah-langkah metodologi RAD. Dalam metode RAD terdapat langkah-langkah yang dibagi dalam empat fase. Langkah-langkah metode RAD adalah sebagai berikut:
 

3.1 Fase Analisis Persyaratan
Fase ini memiliki tujuan untuk mengidentifikasi layanan, batasan, dan obyektifitas dari sistem dari pengumpulan data yang dilakukan terhadap stakeholders. Selain itu analisis persyaratan juga bertujuan untuk mendefinisikan persyaratan user dan sistem. Hasil akhir dari analisis persyaratan yaitu spesifikasi awal dari persyaratan user dan sistem. Adapun Fase 1 ini terdiri dari 5 langkah  yaitu sebagai berikut:
a.    Langkah 1.1:  Komunikasi dan Perencanaan Proyek
Tujuan dari langkah komunikasi dan perencanaan proyek adalah untuk mengidentifikasi kegiatan, patokan, dan apa yang harus dihasilkan oleh proyek. Langkah 1.1 ini menghasilkan perencanaan proyek, manajemen perubahan persyaratan dan manajemen resiko.
b.    Langkah 1.2:  Studi kelayakan
Tujuan dari studi kelayakan adalah untuk menentukan apakah proyek dapat dilanjutkan. Jika proyek dapat diteruskan, studi kelayakan akan menghasilkan rencana proyek dan estimasi biaya untuk tahap pengembangan selanjutnya. 

Ada 4 macam studi kelayakan yang dapat dilakukan yaitu:

i.  Teknis: Kelayakan teknis digunakan untuk menentukan penggunaan solusi teknis tertentu dalam sistem/proyek, dan ketersediaan sumber daya dan keahlian teknis.

ii.  Operasional: Kelayakan operasional adalah ukuran seberapa baik solusi akan berhasil dalam organisasi. Studi kelayakan ini juga mengukur persepsi orang akan sistem/proyek.

iii.  Ekonomi: Kelayakan ekonomi digunakan untuk mengukur biaya yang mempengaruhi proyek/solusi. 

iv.  Penjadwalan: Kelayakan penjadwalan digunakan untuk mengukur timeline proyek. 

c.   Langkah 1.3:  Spesifikasi pengguna

Tujuan dari spesifikasi pengguna yaitu untuk mengidentifikasi dan menetapkan kebutuhan user mengenai apa yang akan dicapai oleh proyek ini. Hasil dari daftar pengguna beserta tugas dan tanggung jawabnya, problem statement matrix, dan daftar prioritas kebutuhan pengguna.
d.    Langkah 1.4:  Spesifikasi sistem

Tujuan dari spesifikasi sistem adalah menjelaskan kebutuhan dan keinginan akan adanya sistem informasi. Dapat memberikan deskripsi mengenai fungsi-fungsi, fitur-fitur (atribut) dan batasan-batasan yang dibutuhkan sistem. Langkah ini menghasilkan pernyataan yang jelas mengenai tujuan dibangunnya sistem, fitur-fitur aplikasi dan batasan-batasannya.
Semua hasil dari langkah-langkah yang terdapat dalam fase 1 ada pada dokumen fase 1.
 

3.2 Fase Analisis Modeling
Tujuan dari fase analisis modeling adalah menganalisis semua kegiatan dalam arsitektur sistem secara keseluruhan dengan melibatkan identifikasi dan deskripsi abstraksi sistem perangkat lunak yang mendasar dan hubungan-hubungannya. Selain itu, analisis modeling juga bertujuan untuk meningkatkan pemahaman terhadap permasalahan tanpa mempertimbangkan solusi teknis. Hasil akhir dari analisis modeling yaitu diagram model logis dari sistem yang sedang berjalan, diantaranya use case diagrams, class diagram, dan sequence diagrams. Fase 2 ini terdiri dari:
a.    Langkah 2.1:  Mengidentifikasi pelaku bisnis
Tujuan dari langkah ini yaiut untuk mengidentifikasi user yang terlibat dalam bisnis proses beserta dengan peranan/tanggung jawab mereka dalam penggunaan sistem. Hasilnya adalah daftar aktor beserta tugas dan tanggung jawabnya.
b.    Langkah  2.2:  Menganalisis proses dan kinerja sistem

Tujuannya yaitu untuk memperoleh deskripsi secara jelas mengenai dukungan fungsional dan non-fungsional yang menjadi kebutuhan terhadap sistem yang dikembangkan dengan menggunakan model diagram use case. Hasil dari langkah ini yaitu use case diagram.
c.    Langkah 2.3: Mengidentifikasi struktur obyek dan relasinya

Tujuan dari langkah ini yaitu untuk mengidentifikasi dan pemodelan kelas objek dalam sistem yang akan dikembangkan, yang menggambarkan struktur obyek dalam sistem.
i.    Menemukan objek yang potensial

Tujuannya yaitu untuk menemukan kata benda yang berhubungan dengan entitas bisnis. Hasilnya yaitu daftar objek yang berpotensi.
ii.    Mendokumentasikan bisnis obyek dan relasinya
Tujuannya untuk mengatur obyek-obyek yang telah diidentifikasi dan mendokumentasikan hubungan konseptual utama antara obyek-obyek tersebut. Hasilnya adalah class diagram (yang dikenal juga sebagai object association diagrams).
iii.    Analisis perubahan keadaan obyek
Tujuannya adalah untuk mengidentifikasi dan memodelkan obyek yang mengalami perubahan keadaan. Hasil dari analisis perubahan keadaan obyek yaitu activity diagrams.
 

3.3 Fase Desain Modeling
Tujuan dari fase desain modeling yaitu melakukan perancangan sistem berdasarkan analisis yang telah dilakukan sebelumnya. Tahap analisis dan desain mengalami perulangan hingga diperoleh rancangan sistem yang benar-benar memenuhi kebutuhan. Selain itu, fase 3 ini juga bertujuan untuk memberikan spesifikasi yang jelas dan lengkap kepada programmer dan teknisi. Hasil akhir dari fase ini yaitu basis data, antarmuka, dan spesifikasi desain. Fase 3 ini terdiri dari:
a.    Langkah 3.1:  Memodelkan kembali diagram use case untuk  merefleksikan  lingkungan  implementasi
Tujuanya adalah untuk memperlihatkan perubahan dari analisis use case menjadi desain use case dan memperbaharui model diagram use case dengan menambahkan lebih banyak fakta dari proses pengembangan dan dokumentasi untuk memperlihatkan use case yang baru. Hasil dari langkah 3.1 adalah design use cases (physical.)
b.    Langkah 3.2:  Memodelkan interaksi obyek dan behaviours
Tujuannya adalah untk mengidentifikasi dan mengelompokkan perancangan obyek dan atribut-atribut yang dibutuhkan secara fungsional yang telah dispesifikkan sebelumnya lewat setiap use case dan mengidentifikasi object interactions. Hasilnya yaitu daftar interface, control, dan entity untuk setiap obyek., use case diagram, activity diagram, sequence diagram.
c.    Langkah 3.3:  Desain antarmuka
Tujuannya adalah untuk menyediakan detail elemen multimedia yang akan digunakan, message yang akan disampaikan, presentasi isi, map navigasi, contoh halaman, dan storyboard. Hasil dari tahap 3.3 yaitu storyboard.
d.    Langkah 3.4:  Membuat algoritma
Tujuannya yaitu untuk merepresentasikan prosedur logic dari fungsi yang dibuat dalam aplikasi. Hasilnya adalah flowchart.
 

3.4 Fase 4: Konstruksi
Tujuan dari fase konstruksi adalah untuk menunjukkan platform, hardware dan software yang digunakan serta batasan dalam implementasi, serta menguji performansi prototipe perangkat lunak yang telah dibangun agar dapat diketahui apakah prototipe tersebut telah sesuai dengan spesifikasi analisis dan perancangan yang telah diidentifikasi sebelumnya. Hasil akhir dari fase konstruksi adalah platform, hardware dan software yang digunakan, serta daftar batasan implementasi, dan rencana pengujian. Fase 4 ini terdiri dari:
a.    Langkah 4.1: Lingkungan implementasi
Tujuannya yaitu menfasilitasi pengembangan sistem dengan menggunakan perangkat keras dan perangkat lunak yang sudah disediakan. Hasilnya adalah daftar perangkat keras dan perangkat lunak.
b.    Langkah 4.2: Implementasi basis data
Tujuannya yaitu membangun basis data berdasarkan pemodelan kelas objek. Hasilnya adalah basis data sistem.
c.    Langkah 4.3: Melakukan pemrograman
Tujuannya yaitu membuat pengkodean sistem berdasarkan model algoritma dan diagram objek yang telah dirancang.Hasilnya adalah kode program.
d.    Langkah 4.4: Implementasi antarmuka
Tujuannya adalah untuk membangun antarmuka pengguna. Hasilnya adalah kode program lengkap dengan antarmuka pengguna.
e.    Langkah 4.5: Pengujian
i. Identifikasi tujuan pengujian sistem.
Tujuannya untuk emperoleh tujuan pengujian sistem agar dapat digunakan sesuai dengan kebutuhan. Hasilnya daftar tujuan pengujian sistem.
ii. Buat kriteria pengujian sistem
Tujuannya untuk mengidentifikasi kriteria pengujian sistem sehingga menjadi tolak ukur dalam analisis hasil pengujian. Hasilnya daftar kriteria pengujian sistem pakar.
iii. Buat kasus untuk pengujian
Tujuannya untuk menentukan skenario yang akan dilaksanakan dalam pengujian sehinga pengujian dapat dilakukan secara terarah. Hasilnya daftar kasus untuk pengujian.
iv. Lakukan Pengujian Sistem
Tujuannya melaksanakan serangkaian kegiatan pengujian berdasarkan tujuan dan kasus uji. Hasilnya test plan.   

Metodologi AUP

Metodologi AUP atau Agile - Unified Process merupakan suatu metodologi pengembangan perangkat lunak yang mulai marak digunakan. Menurut hemat saya, metodologi ini paling cocok digunakan oleh mahasiswa dalam menyelesaikan tugas proyek mata kuliah ataupun mengerjakan laporan Kerja Praktek (dan Tugas Akhir)

Gambar 1 menunjukkan menunjukkan Tahapan Proses dan Aktivitas Metodologi AUP

Gambar 2 menunjukkan urutan akvitas pada masing-masing fase AUP

Tahapan pemecahan masalah dengan metodologi AUP, mengikuti langkah-langkah yang dikeluarkan oleh Pusilkom Universitas Indonesia. Panduan Agile UP ini mengacu pada metodologi yang dibuat oleh Ambysoft Inc (lihat Gambar 1 dan Gambar 2). Garis besar tahapan analisa dan perancangan yang dilakukan adalah sebagai berikut:
1)    Inception, 

dengan aktivitas mendefinisikan project scope, mengestimasi biaya dan penjadwalan, mendefinisikan resiko, membuat kelayakan proyek dan mempersiapkan lingkungan pengerjaan proyek (tim, tempat kerja, instalasi, dan sebagainya). Proses iterasi dilakukan satu kali. Artifak yang dihasilkan diantaranya adalah dokumen Vision, dokumen Supplementary Specification, dokumen Glossary, Gantt Chart dan Iteration Plan.

2) Elaboration, 

dengan aktivitas mengidentifikasi dan validasi arsitektur aplikasi. Proses iterasi dapat dilakukan satu sampai dua kali. Artifak yang dihasilkan adalah UML Use Case, Model Arsitektur (update dan snapshot), Architecture Prototype Code, Scenario Test Plan, dokumen Business Rule, dokumen Supplementary dan Glossary yang telah diupdate.
 

3) Construction, 

dengan aktivitas memodelkan, membangun dan menguji sistem aplikasi (unit testing) serta membuat dokumentasi pendukung. Proses iterasi dapat dilakukan dua hingga delapan kali. Artifak yang dihasilkan adalah Use Case (yang telah diupdate), dokumen Supplementary dan Glossary (yang telah diupdate), Domain Model (snapshot), UML Activity Diagram (snapshot), UML Class Diagram (snapshot), CRC Card, UML Sequence Diagram (snapshot), Source Code, Code Documentation, Regression Test Suite, Acceptance Test dan Bugs Report.

4) Transition, 

dengan aktivitas menguji sistem (integration sistem dan user testing), mereview kembali sistem aplikasi dan menginstalasi sistem aplikasi. Proses iterasi dapat dilakukan satu hingga dua kali. Artifak yang dihasilkan adalah Dokumen System Requirement Specification, Dokumen System Technical Specification, Panduan Instalasi dan Panduan Pengguna, Dokumen Pelatihan, Regression Test Suite, User Acceptance Test dan Bugs Report (yang sudah final). 

Panduan Agile UP dari Pusilkom UI juga memberikan best practice dalam melakukan setiap aktivitas di setiap fase. Panduan ini juga membedakan artifak dokumen yang dihasilkan, sebagai artifak utama, artifak pendukung dan artifak input dan artifak output. Panduan ini juga memberikan LCO (Lifecycle Obejctive) berupa dokumen dan presentasi dari setiap fase, sebagai target yang harus dicapai sebelum melanjutkan ke fase yang selanjutnya. Untuk kepentingan penulisan paper ini, maka penulis akan membatasi artifak yang akan ditampilkan.