belajar dulu, baru lulus..

Data Flow Diagram

Data Flow Diagram adalah perangkat-perangkat analisis & perancangan yang terstruktur, sehingga memudahkan penganalis sistem dalam memahami sistem & sub sistem secara visual sebagai suatu rangkaian aliran data yang saling berkaitan.

Beberapa unsur yang ada pada DFD :
- Entitas
Dibagi menjadi 2 jenis, antara lain :
1. Entitas Eksternal
- Entitas eksternal (bagian lain, perusahaan, seseorang atau mesin) yang dapat mengirim data atau menerima data dari sistem.
- Sumber atau tujuan data yang dianggap eksternal terhadap sistem yang sedang digambarkan.
- Entitas-entitas harus diberi nama dengan suatu kata benda.
- Entitas yang sama dapat digunakan lebih dari 1 kali atas suatu DFD tententu untuk menghindari persilangan antara jalur-jalur aliran data.

2. Entitas Internal
- Merupakan pemilik sistem, jadi tidak digambarkan dalam diagram.

- Aliran data
• Perpindahan data dari satu titik ke titik yang lain, dengan kepala tanda panah mengarah ke tujuan data
• Digambarkan dengan kata benda.

- Proses
• Menunjukkan adanya proses transformasi
• Proses-proses selalu menunjukkan suatu perubahan data, jadi aliran data yang meninggalkan proses selalu diberi label yang berbeda.
• Diberi nama dengan kata kerja.

- Data Store
• Diberi nama dengan kata benda yang sesuai data apa yang simpan di data store, misalnya Data Konsumen, Transaksi Penjualan, dan lain sebagainya.
• Penyimpanan data sementara, seperti kertas catatan atau sebuah file komputer sementara tidak dimasukkan ke dalam DFD.


Membuat context diagram :
- Harus berupa suatu pandangan.
- Tingkatan tertinggi & hanya memuat satu proses. (menunjukkan sistem secara keseluruhan)
- Context diagram diberi nomor 0.
- Tidak memuat data store.

Diagram level 0:
- Masukan dan keluaran yang ditetapkan dalam diagram yang pertama tetap konstan.
- Mencakup maksimal 9 proses yang digambarkan.
- Menampilkan seluruh data store yang digunakan dalam sistem, karena setelah di decompose tidak boleh menambah data store yang belum ditampilkan.

Perbedaan Context Diagram dengan Level 0 :
Context Diagram : merupakan semesta.
Level 0 : berada atau merupakan bagian di dalam semesta.

Pertemuan 4

Lines of Code
Pengukuran sederhana : menghitung jumlah baris kode dalam program dan menggunakan perhitungan ini untuk mengukur kompleksitas.

Halsteads Metric
- Pengukuran yang berdasarkan pada penggunaan operator-operator & operan-operan yang ada dalam suatu program.

Panjang Program :
H = n1 log2 n1 + n2 log2 n2
n1 : jumlah operator yang unik (distinct) dalam program.
n2 : jumlah operan yang unik (distinct) dalam program.

Prediksi Bug :
B = (N1 + N2) log2 (n1 + n2) / 3000
N1 : perhitungan jumlah keseluruhan operator program.
N2 : perhitungan jumlah keseluruhan operan program.


Black Box Testing
Black box testing dilakukan tanpa pengetahuan detil struktur internal dari sistem atau komponen yang ditest. Juga disebut sebagai behavioral testing, specification based testing, I/O testing atau functional testing.
Berfokus pada kebutuhab fungsional pada software, berdasarkan pada spesifikasi pada software.

Kategori Error yang akan diketahui melalui Black Box Testing :
- Fungsi yang hilang atau tidak benar.
- Error dari antar muka.
- Error dari struktur data atau akses eksternal database.
- Error dari kinerja atau tingkah laku.
- Error dari inisialisasi dan terminasi.

Jenis teknik test yang dapat dipilih berdasarkan pada tipe testing yang akan digunakan :
- Equivalence Class Partitioning
- Boundary Value Analysis
- State Transition Testing
- Cause Effect Graphing

Pertemuan 3

Test Case
Test Case adalah suatu test yang dilakukan berdasarkan suatu inisialisasi masukan, kondisi, ataupun hasil yang telah ditentukan sebelumnya.

Pendekatan test untuk rekayasa produk :
• Produk rekayasa ditest dalam 2 cara :
- Dengan berdasarkan pada fungsi yang dispesifikasikan dari produk.
- Operasi internal dari produk.

White Box Testing
- Metode ini digunakan untuk memecah struktur program sehingga mengetahui desain prosedural program.
- Diasosiasikan dengan pengukuran cakupan test yang mengukur prosentase jalur-jalur tipe yang dipilih untuk dieksekusi oleh test case.
- Menguji semua struktur debug program.


Alur logika yang akan menunjukkan bagaimana jalur program tersebut.

Pertemuan 2

Obyektifitas Testing :
- Meningkatkan kepercayaan bahwa sistem dapat digunakan dengan tingkat resiko yang dapat diterima.
- Menyediakan informasi yang dapat mencegah terulangnya error yang pernah terjadi.
- Menyediakan informasi yang dapat membantu untuk mendeteksi error secara dini.
- Mencari error dan kelemahan atau keterbatasan sistem.
- Mencari sejauh mana kemampuan dari sebuah sistem (benchmark).
- Menyediakan informasi untuk kualitas dari produk software.

Misi dari tim testing :
- Misi dari tim testing tidak hanya untuk melakukan testing, tetapi juga untuk membantu meminimalkan resiko kegagalan proyek.
- Tester tidak melakukan pembenahan atau pembedahan kode, tidak mempermalukan atau melakukan komplain pada suatu individu atau tim. Tetapi hanya memberikan informasi tentang apa yang terjadi dengan sistem yang ditesting.
- Tester adalah individu yang memberikan hasil pengukuran dari kualitas produk.

Tester harus memahami beberapa hal, yaitu :
- Software Quality
- Cara komunikasi (dengan template tertentu).

Pertemuan 1

Error / kesalahan => ketidaksesuaian yang terjadi terhadap spesifikasi. Atau apa yang terjadi tidak sesuai dengan apa yang sudah diharapkan.

Catatan :
• Dalam requirement specification kita juga perlu melakukan cek apakah sudah sesuai dengan kebutuhan konsumen.
• Pada saat menentukan desain program, kita juga melakukan pengecekan. Apakah desain yang kita buat sudah sesuai dengan requirement specification.
• Pada saat implementasi, kita juga melakukan testing. Apakah program yang kita buat sudah sesuai dengan desain dan requirement specification.

Tujuan Testing :
- Membuat kualitas dapat dilihat secara obyektif, karena testing merupakan pengukuran dari kualitas software.
- 2V 1D : Verifikasi, Validasi, Deteksi.

Fungsionalitas :
- Kebenaran
- Reliabilitas
- Kegunaan
- Integritas

Rekayasa :
- Efisiensi
- Testabilitas
- Dokumentasi
- Struktur

Adaptabilitas :
- Fleksibilitas
- Reusabilitas
- Maintainbilitas

Biasanya dalam melakukan testing itu diterapkan best practice, atau metode yang paling sering digunakan kalangan tester dalam melakukan testing.

Pertemuan 1

Desain Sistem dibagi menjadi dua bagian :
1. Desain Sistem Scr. Umum / General Systems Design, atau disebut conceptual design.
2. Desain Sistem Terinci, atau disebut physical design.

Arti Desain :
 Tahap setelah analisis dari siklus pengembangan sistem
 Pendefinisian dari kebutuhan fungsional.
 Persiapan untuk rancang bangun implementasi
 Menggambarkan bagaimana suatu sistem dibentuk.
 Dapat berupa penggambaran, perencanaan & pembuatan sketsa/pengaturan dari beberapa elemen yang terpisah ke dalam satu kesatuan yang utuh & berfungsi.
 Termasuk menyangkut mengkonfirmasi komponen-komponen perangkat lunak & perangkat keras dari suatu sistem.

Tujuan Desain :
1. Untuk memenuhi kebutuhan pemakai sistem
2. Untuk memberikan gambaran yang jelas & rancang bangun yang lengkap kepada pemrogram komputer & ahli-ahli teknik yg lain, yang terlibat.

Agar tujuan tercapai, maka seorang sistem analis harus mencapai beberapa sasaran berikut :
1. Desain Sistem harus berguna, mudah dipahami & nantinya mudah digunakan.
2. Desain Sistem harus dapat mendukung tujuan utama perusahaan, sesuai dengan yg telah didefinisikan pd tahap perencanaan sistem.
3. Desain Sistem harus efisien & efektif utk dapat mendukung pengolahan transaksi, pelaporan manajemen & mendukung keputusan yg dilakukan manajemen.
4. Desain Sistem harus dpt mempersiapkan rancang bangun yg terinci, yg terdiri antara lain: data, informasi, file, metode-metode, prosedur, SDM, H/W, S/W.

Personil yang terlibat :
Pekerjaan desain sistem dilakukan oleh analis sistem, & personil teknik lain, seperti: spesialis pengendalian, personil penjamin kualitas, spesialis komunikasi data, dan lain-lain.

Pentingnya peranan user :
User harus dilibatkan dalam tahap desain, karena dapat mengkaji ulang komponen sistem yg didesain. Contohnya: laporan & bentuk tampilan dari sistem.

Pertemuan 2

Tujuan Testing:
Secara Umum untuk melakukan verifikasi, validasi, deteksi error dan di gunakan untuk menemukan masalah yang muncul pada saat melakukan testing sistem.

Misi dari tim Tester:
· Meminimalkan kegagalan proyek
· Tidak melakukan pembenahan hanya memberikan informasi tentang kesalahan yang terjadi pada sistem tersebut
· Memberikan pengukuran dari kualitas software

Menjadi seorang tester yang baik hendaknya harus paham tentang kualitas dari software yang akan dilakukan dalam pembuatan sistem, serta memahi arti dari komunikasi yang dilakukan dengan client

Psikologi Testing :
· Seorang pengembang bertugas untuk membanagun
· Tester mengahancurkan program

Prinsip –prinsip testing:
· Testing tidak mungkin Komplit
· Testing merupakan Pekerjaankreatif dan sulit
· Testing harus di rencanakan
· Testing membutuhkan independence

• Menyediakan gambaran informasi terpadu dari sebuah perusahaan
• Menjadikan informasi mutakhir dan informasi historis perusahaan gampang diakses untuk keperluan pengambilan keputusan stategis perusahaan
• Menjadikan sistem pengambilan keputusan terrealisasi dengan memanfaatkan data operasional perusahaan sudah yang ada
• Menyajikan informasi yang konsisten
• Menyajikan informasi yang fleksibel dan interaktif

Pertemuan 1

Testing membuat kualitas dapat dilihat secara obyektif, karena testing merupakan pengukuran dari kualitas software. Dengan kata lain testing berarti pengendalian kualitas (Quality Control - QC), dan QC mengukur kualitas produk, sedangkan jaminan kualitas (Quality Assurance – QA) mengukur kualitas proses yang digunakan untuk membuat produk berkualitas.
Dalam sebuah proses pembuatan sebuah program pastinya akan melewati beberapa tahapan yaitu : Requirment,
analysis, desain ,implementation, testing and deploy.

Dalam tahap requirment diperlukan sebuah standart umum sedangkan untuk memenuhi sebuah kualitas yang baik hendaknya QA (Quality Assurance).
QA senfiri digunakan untuk mengukur kualitas dari proses yang di gunakan untuk membuat sebbuah produk tersebut.
Berikut contoh yang mengilustrasikan beberapa faktor-faktor komponen yang sering
digunakan:
Fungsionalitas (Kualitas Luar)

• Kebenaran (Correctness)
• Reliabilitas (Reliability)
• Kegunaan (Usability)
• Integritas (Integrity)

Rekayasa (Kualitas Dalam)

• Efisiensi (Efficiency)
• Testabilitas (Testability)
• Dokumentasi (Documentation)
• Struktur (Structure)

Adaptabilitas (Kualitas ke Depan)

• Fleksibilitas (Flexibility)
• Reusabilitas (Reusability)
• Maintainabilitas (Maintainability)

(Romeo S.T, 2003)

BEBERAPA FAKTOR PENTING DALAM TUNING DATABASE ORACLE

Ada beberapa hal yang harus diperhatikan apabila kita akan melakukan performance tuning terhadap suatu database, hal-hal tersebut antara lain:

1. Buat kesepakatan dengan user, sampai sejauh mana user akan menerima hasil dari proses tuning yang kita lakukan terhadap suatu database. Hal ini perlu untuk kita, sebagai executor, dalam pelaksaan proses tuning dalam database. Mengapa demikian? Apabila kita melaksanakan proses tuning pada database, tentunya harapannya adalah adanya peningkatan performance dari database tersebut. Untuk itulah maka perlu adanya satu batasan berupa kesepakatan dengan user database, jangan sampai suatu proses tuning database tidak di accept oleh user karena user merasa performance database yang telah kita lakukan tuning tidak significant perubahannya.
2. Identifikasi terlebih dahulu area-area mana saja pada database yang paling critical, apabila kita tidak segera melakukan tuning terhadap database tersebut, atau dengan kata lain prioritaskan proses tuning pada area-area yang dianggap paling critical.
3. Identifikasi bottleneck yang ada dalam sebuah atau beberapa query. Biasanya hanya karena sebuah query yang jelek menyebabkan performance menjadi turun secara keseluruhan.
4. Jika memungkinkan, review terlebih dahulu design dari database yang akan kita tuning, apakah sudah bagus, sebelum kita melakukan tuning pada query-query terhadap database tersebut, karena apabila kita melakukan query tuning tetapi dari sisi design database kurang bagus, maka tuning pada query akan tidak optimal, bahkan mungkin tidak ada impact sama sekali.
5. Pelajari strategi index yang sudah berjalan pada database yang akan kita tuning, dan lakukan improvement terlebih dulu pada area index ini.
6. Jika kita rasakan index yang ada sudah optimal, lakukan identifikasi fragmentation level dari index yang ada, dan pastikan index statistic selalu up-to-date.
7. Pelajari bagaimana cara kerja query optimizer, pelajari dan test beberapa bentuk tipe JOIN.
8. Hindari penggunaan sub-query (select in select).
9. Selalu gunakan UNION ALL daripada UNION, apabila memang ada operasi yang membutuhkan UNION
10. Evaluasi penggunaan trigger yang berdampak pada performance.
11. Hindari penggunaan SELECT ...... INTO sampai dengan kita yakin bahwa user yang terhubung ke database hanya kita sendiri atau proses yang kita lakukan hanya memerlukan waktu yang tidak lama. Jika sangat terpaksa gunakan INSERT .......SELECT.
12. Gunakan SET NOCOUNT ON dalam semua modular code kita (Stored Procedure), untuk mengurangi informasi yang diberikan server ke client dan untuk mengurangi beban network.
13. Jika memungkinkan, gantu semua query yang merupakan inline query menjadi stored procedure yang berparameter
14. Jika memungkinkan, gunakan temporary table untuk mengurangi jumlah record pada saat query. Jika temporary table tersebut di join dengan permanent table, buat index di dalam temporary table tersebut.
15. Optimalkan penggunaan loop, pindahkan semua proses yang tidak memerlukan pengulangan keluar loop.
16. Jangan gunakan cursor jika memang tidak sangat terpaksa, TSQL tidak dioptimalkan untuk memproses 1 record dalam satu waktu

DATA CONECTIVITY