Decision Table Testing

Di sini kita memiliki tabel keputusan lengkap karena ada tiga entri tidak peduli yang memberikan aturan pertama hitungan aturan 8 dan 8 terakhir aturan memiliki jumlah aturan 1 masing-masing, sehingga
aturan jumlah total meja adalah 16. Oleh karena itu kita tahu bahwa tabel ini selesai.

Decision Table Testing ialah metode yang digunakan untuk membangun satu set lengkap kasus uji tanpa
menggunakan struktur internal dari program tersebut. Dalam rangka menciptakan uji kasus kita
menggunakan tabel untuk mengandung nilai-nilai input dan output dari sebuah program.
Membuat Tabel Keputusan
Ketika membuat tabel perawatan keputusan harus diambil ketika memilih stub Anda
kondisi, dan juga jenis tabel keputusan yang Anda buat. Limited Entry tabel keputusan lebih mudah untuk membuat dari tabel entri diperpanjang. Berikut adalah beberapa langkah dicara membuat tabel keputusan sederhana menggunakan Soal Segitiga.

Langkah Satu â € “Daftar Semua Kondisi Stub
Dalam contoh ini kita ambil tiga masukan, dan dari input yang kita lakukan bersyarat cek untuk menghitung jika ita € ™ sa segitiga, jika demikian maka apa jenis segitiga itu. Yang pertama kondisi kita menambahkan harus memeriksa apakah semua 3 sisi merupakan segitiga, seperti yang kita dona € ™ t ingin melakukan pemeriksaan lain jika jawabannya adalah palsu.
Kemudian sisa dari kondisi akan memeriksa apakah sisi segitiga adalah sama atau tidak. Seperti hanya ada tiga sisi segitiga berarti bahwa kami memiliki tiga kondisi ketika memeriksa semua sisi.
Jadi Rintisan bertopik kondisi untuk tabel akan menjadi:
a, b, c membentuk segitiga?
a = b?
a = c?
a = c?
Langkah Kedua â € “Hitung Jumlah Kombinasi Kemungkinan (Aturan)
Jadi dalam tabel kami, kami telah 4 stub kondisi dan kami sedang mengembangkan sebuah entri terbatas tabel keputusan sehingga kita gunakan rumus berikut:
Jumlah Aturan = 2Number dari Rintisan Kondisi
Jadi karena itu, Jumlah Aturan = 24 = 16
Jadi kita punya 16 kombinasi yang mungkin dalam tabel keputusan kami.
Langkah Tiga - Tempat semua Kombinasi ke dalam Tabel
Langkah Empat - Periksa Kombinasi Covered
Langkah ini adalah langkah pencegahan untuk memeriksa kesalahan dan berlebihan dan tidak konsisten
aturan. Kami tidak ingin pergi lebih jauh dengan perkembangan dari tabel keputusan jika kami memiliki kesalahan karena hal ini akan memperumit masalah pada langkah berikutnya.
Langkah Lima - Isi Tabel dengan Tindakan
Untuk langkah terakhir untuk menciptakan tabel keputusan kita harus mengisi Stub Action dan Masuk
bagian meja. Tabel keputusan akhir ditunjukkan pada gambar di bawah ini.
Setelah menyelesaikan tabel keputusan dan menambahkan tindakan kita melihat bahwa setiap tindakan
stub dilaksanakan sekali, dan kami juga menambahkan “mungkin” tindakan ke dalam tabel atau menangkap nilai-nilai jahat.

No commentsRead more

Mengukur Kinerja Produksi

Menjadi manajer atau supervisor atau apapun namanya yang  bertanggung jawab atas suatu proses atau aktifitas ada enak dan tidaknya, yah… beginilah dunia. Di antara enaknya, mereka akan mendapat upah jauh lebih besar dari karyawan biasa saat akhir bulan, tapi ada juga tidak enaknya, mereka musti menanggung semua beban dari unit kerja yang menjadi tanggung jawabnya. So, jika sebuah unit kerja tidak perform, maka tak lain yang paling layak digantung duluan adalah mereka para penanggung jawabnya… Nah lho. termasuk diomelin oleh atasannya atau oleh owner, maka ada ujar-ujar, upah manajer lebih tinggi itu sudah dihitung termasuk dengan upah atas kesiapan menerima omelan….he3x.. siapa yang sudah siap diomelin?

Nah, agar setiap aktifitas terukur kinerjanya, maka tentu kita perlu ukuran, termasuk juga pekerjaan kita-kita yang ada di medan juang manufaktur atau bagian produksi. Adalah disebut Overall Equipment Effectiveness (OEE) yang bisa diandalkan menjadi indikator kinerja produksi. Biasanya, OEE ini menjadi key performance indicator (KPI) atas implementasi lean manufacturing. Agar lebih mudah dan bisa dioperasionalkan, maka saya coba share teknis menghitung OEE, yang sejatinya dalam rangka mengukur kinerja produksi.

Misal, data produksi yang kita lakukan sbb.:

• Lama waktu 1 shift             = 8 jam = 480 menit
• Waktu istirahat                    = 1 jam = 60 menit
• Downtime                              = 40 menit
• Target produksi                 = 8.400 kg
• Ideal run rate                        = 20 kg/menit
• Hasil total 1 shift                    = 6.500 kg
• Jumlah scrap/reject             = 47 kg

Maka, terlebih dahulu perlu dihitung variabel-variabel berikut ini:

• Planned Production Time

Planned Production Time = lama waktu kerja 1 shift – waktu istirahat
= 480 – 60
= 420 menit

• Operating Time

Operating Time = planned production time – downtime
= 420 – 40
= 380 menit

• Good Product

Good Product  = hasil total – jumlah reject   
= 6.500 – 47
= 6.453 kg

Berikutnya, kita hitung OEE Factor, yang terdiri atas Availability, Performance, dan Quality:

• Availability

Availability = (Operating Time : Planned Production Time) x 100%
= (380 : 420) x 100%
= 0,9048 x 100%
= 90,48%

• Performance

Performance = ((Hasil Total : Operating Time) : Ideal Run Rate) x 100%
= ((6.500 : 380) : 20) x 100%
=  0,8553 x 100%
= 85,53%

• Quality

Quality  = (Good Product : Hasil Total) x 100%
= (6.453 : 6.500) x 100%
= 0,9928 x 100%
= 99,28%
Jadi, nilai OEE-nya adalah:
OEE  = (Availability x Performance x Quality) x 100%
= (0,9048 x 0,8553 x 0,9928) x 100%
= 0,7683 x 100%
= 76,83%

Sekiranya, kita perlu membanding, maka saya perkenalkan nilai OEE standar World Class Manufacturing sbb.:

• Availability   = 90,0%
• Performance = 95,0%
• Quality      = 99,9%
• OEE           = 85,0%

Selanjutnya, jika kita kembali kepada hasil perhitungan OEE kita di atas, maka nampak bahwa faktor availability sudah baik dan berhasil melampaui standar world class, namun untuk faktor performance dan quality masih di bawah standar sehingga masih perlu diperbaiki dengan mengurangi kerugian pada speed loss dan quality loss.  But, tetap semangat dan istiqamah di medan juang…

Eh, sebentar, Ada catatan yang cukup penting di sini bahwa ukuran-ukuran di atas biasanya hanya enak ‘dikunyah” oleh para manajer atau penanggung jawab unit kerja sedangkan untuk operator seringnya tak ada minat untuk aware pada rumus-rumus dan angka-angka persentase di atas, dalam benak mereka itu semua terlalu abstrak, Bo. Oleh karena itu, saya sarankan gunakan komunikasi yang lebih “nyambung” dengan para operator dalam rangka meningkatkan kinerja produksi. Dengan Apa?   Cukup gunakan saja istilah TAEDD, yakni:

• Target, yaitu jumlah produksi yang ditargetkan pada satu shift produksi, dalam contoh di atas berarti 8.400 kg.
• Actual, yaitu jumlah hasil aktual yang dapat diterima (good product) pada satu shift produksi, dalam contoh di atas berarti 6.453 kg.
• Efficiency, yaitu perbandingan hasil aktual yang dapat diterima (good product) dengan target, dalam contoh di atas berarti 76,82%
• Downtime, yaitu jumlah waktu downtime pada satu shift produksi, dalam contoh di atas berarti 40 menit.
• Defect, yaitu jumlah produk yang cacat (reject), dalam contoh di atas berarti 47 kg.

No commentsRead more

"ISYARAT SELAMA TOURING"

Sore brother semua... udah pada hapal belum isyarat isyarat selama touring?

Mengangkat tangan dan mengayunkan ke arah depan, adalah tanda bahwa Konvoi bergerak lurus. Isyarat ini disampaikan oleh Voorrijder, dan harus diikuti oleh semua peserta Touring.( Gambar 1 )

Mengayunkan tangan ke arah bawah, adalah tanda unuk memperlambat kecepatan dan berhati – hati. Isyarat ini disampaikan oleh Voorrijder, Safety Office serta Sweaper dan harus diikuti oleh peserta Touring.( Gambar 2 )

Mengarahkan Tangan ke arah Kanan atau Kiri, adalah tanda bahwa Konvoi berbelok ke arah Kanan atau Kiri. Isyarat ini disampaikan oleh Voorrijder, dan diikuti oleh peserta Touring ( Gambar 3 )

Mengangkat tangan sambil mengepalkan jari tangan, adalah tanda untuk berhenti. Isyarat ini disampaikan oleh Voorrijder, Safety Officer, Sweaper dan diikuti oleh semua peserta Touring. ( Gambar 4 )

Menurunkan Kaki Kiri atau Kanan, adalah isyarat adanya Hambatan atau Halangan di sisi Kiri atau di sisi Kanan. Seperti : Lubang, Jalan Rusak, Pembatas Jalan yang membahayakan dll. Isyarat ini diawali oleh Voorrijder dan di ikuti oleh para peserta Touring.(Dilara

ng memberi tanda ke arah Pengguna jalan lain yang berada di jalur kanan lalu lintas ) Gambar 5.

Menurunkan kedua Kaki Kiri dan Kanan adalah isyarat adanya Hambatan atau Halangan. Seperti : Lubang, Jalan Rusak, Polisi Tidur, Perbatasan Jembatan, Rel Kereta Api, dll.( Gambar 6 )

No commentsRead more

SPESIFIKASI PROSES (PROCESS SPECIFICATION)

Ada berbagai macam tools yang dapat kita gunakan untuk menghasilkan suatu spesifikasi
proses: tabel keputusan, Bahasa Inggris terstruktur, pre/post condition, flowcharts, diagram Nassishneiderman,
dan lain sebagainya. Sedangkan kebanyakan analisis sistem mengarah ke Bahasa
Inggris terstruktur, anda harus ingat bahwa setiap metode dapat digunakan, selama hal tersebut
memuaskan dua keadaan penting:
1. Spesifikasi proses harus ditampilkan dalam suatu bentuk/form yang dapat diverifikasi oleh
user dan sistem analis. Kondisi ini tepat untuk alasan ini, dimana kita mengurangi paparan
Bahasa Inggris sebagai sebuah alat spesifikasi: hal ini dikenal sebagai ambigu, khususnya
apabila menggambarkan tindakan (keputusan) alternatif dan tindakan berulang (loops). Secara
alami, hal tersebut juga cenderung menyebabkan kebingungan yang sangat ketika
mengekspresikan bagian-bagian kondisi Boolean (misalkan kombinasi dari operator Boolean
AND, OR dan NOT).
2. Spesifikasi proses harus ditampilkan dalam suatu bentuk/form yang dapat
mengkomunikasikan secara efektif berbagagai keterlibatan berbagai latar belakang pendengar.
Sedangkan hal tersebut akan menjadi tipe dari analis sistem yang menuliskan spesifikasi
proses, hal tersaebut biasanya menjadi bermacam-mcam pendengar dari para pengguna,
manager, auditor, personil quality assurance, dan lainnya yang membaca spesifikasi proses.
Suatu proses spesifikasi diharapkan dapat ditampilkan dalam perhitungan yang dapat
diprediksi, atau dalam pascal, atau dalam pendekatan format diagram seperti software use-it;
tetapi jika komunitas user menolak untuk melihat pada beberapa spesifikasi, mereka adalah
tidak berharga.
77
Spesifikasi Proses berfungsi mendeskripsikan tahapan yang dilakukan untuk
mentransformasikan input menjadi output. Bentuk penyajian spesifikasi proses adalah sebagai
berikut :
No Proses : menyatakan nomor proses
Nama Proses : menyatakan nama proses
Deskripsi : penjelasan tujuan proses
Source Data
(menyatakan sumber data input menuju
proses)
(menyatakan isi data yang masuk ke proses)
Destination Data
(menyatakan tujuan data output dari
proses)
(menyatakan isi data yang keluar dari proses)
Logika proses
(menyatakan algoritma dari proses)
Structured english (SE) merupakan alat yang cukup efisien untuk menggambarkan suatu
algoritma. Pseudoode merupakan alternatif dari structured English. SE mirip dengan pseudocode,
karena kemiripan ini, maka SE dan psedocode sering dianggap sama.
Pseudo berarti imitasi/mirip atau menyerupai dan code menunjukkan kode dari program, berarti
pseudocode adalah kode yang mirip dengan instruksi kode program yang sebenarnya. Pseudocode
akan memudahkan programmer untuk memahami dan menggunakannya, karena mirip dengan
kode-kode program sebenarnya. Pseudocode lebh terinci dibandingkan dengan SE, seperti
menjelaskan juga tentang pemberian nilai awal dari suatu variabel, membuka dan menutup file,
subscript atau tipe-tipe data yang digunakan (misalnya real, integer, Boolean) yang tidak
disebutkan di SE.
Tidak ada satu alatpun yang sempurna untuk semua situasi. Demikian juga dengan SE dan
pseudocode yang kurang baik untuk menggambarkan algoritma yang banyak mengandung
penyeleksian kondisi atau keputusan (decision). Bagan alir (flowchart), tabel keputusan (decision
table) dan pohon keputusan (decision tree) merupakan alat yang lebih baik untuk menggambarkan
keputusan yang kompleks. Akan tetapi dalam beberapa proses yang harus didokumentasikan
sebaliknya haruslah tidak terdiri dari proses-proses yang kompleks, cukup terdiri dari operasioperasi
keputusan dan perulangan yang sederhana. Hal ini tidaklah mengherankan, karena proses
secaara logika yang digambarkan secara terstruktur haruslah mudah dipahami dan dibentuk dengan
bentuk struktur yang macamnya sedikit. Sedikitnya struktur ini menyediakan basis untuk
pemrograman terstruktur, yang akan memberikan efektivitas dalam hal kesederhanaan dan
standardisasi.

No commentsRead more