Manajemen Resiko

E-Government, yang di implementasikan dalam Sistem Informasi Manajemen Daerah (SIMDA), adalah salah satu upaya dalam rangka memenuhi kebutuhan informasi secara cepat, tepat, lengkap, akurat dan terpadu untuk menunjang proses administrasi pemerintahan, pelayanan masyarakat, dan memfasilitasi partisipasi dan dialog publik di dalam perumusan kebijakan [1].
Menyusun proposal SIMDA adalah bagian pekerjaan yang penting dan juga kritis bagi pemerintah. Dalam jangka waktu yang relatif singkat, mereka harus me-review banyak hal dan mengambil berbagai keputusan beresiko untuk menentukan besarnya pengeluaran yang dibutuhkan [2]. Untuk itu dibutuhkan suatu manajemen dalam melakukan analisa resiko yang biasa dikenal sebagai manajemen resiko.
Manajemen resiko adalah suatu proses mengidentifikasi, mengukur risiko, serta membentuk strategi untuk mengelolanya melalui sumber daya yang tersedia. Strategi yang dapat digunakan antara lain mentransfer risiko pada pihak lain, menghindari risiko, mengurangi efek buruk dari risiko dan menerima sebagian maupun seluruh konsekuensi dari risiko tertentu [3].

I. Identifikasi Risiko
Proses ini meliputi identifikasi risiko yang mungkin terjadi dalam suatu aktivitas usaha. Identifikasi risiko secara akurat dan komplet sangatlah vital dalam manajemen risiko. Salah satu aspek penting dalam identifikasi risiko adalah mendaftar risiko yang mungkin terjadi sebanyak mungkin.

II. Daftar Resiko
2.1 Resiko estimasi
a. Kesalahan perkiraan LOC
Resiko ini terjadi jika perkiraan LOC pada kenyataan yang ada jauh melebihi LOC perkiraan pada perhitungan COCOMO, yang mengakibatkan berubahnya jadwal pengerjaan dan biaya operasional.

Solusi :
-Melakukan re-scheduling dan melaporkannya kepada badan pengawas pemerintah, dan melakukan penyesuaian jadwal dan biaya.
-Merekrut staff tambahan untuk membantu penyelesaian SIMDA agar sesuai jadwal.

b. Kesalahan perancangan skala database
Resiko ini terjadi karena skala database yang telah dirancang ternyata tidak sesuai pada proses pengembangan software tersebut. Yang dapat berakibat berubahnya waktu penyelesaian pekerjaan.
Solusi :
-Memberitahu seluruh staff yang bersangkutan untuk melakukan meeting sehubungan dengan perancangan ulang skala database.
-Memberitahu teamwork apabila terjadi perubahan waktu penyelesaian pekerjaan.
-Merekrut staff tambahan untuk membantu penyelesaian pekerjaan agar sesuai jadwal.

2.2 Resiko pengaruh organisasi
a. Dokumentasi untuk pemerintah dianggap kurang baik oleh masyarakat
Resiko ini terjadi apabila dokumentasi yang diberikan kepada masyarakat tidak seperti yang diharapkan. Sehingga masyarakat tidak puas dan kemungkinan adanya ketidakpercayaan masyarakat.
Solusi :
-Untuk pencegahannya sejak awal kita harus sudah melakukan riset bagaimana membuat dokumentasi yang baik, dan juga kita perlu untuk menanyakan kepada dinas-dinas yang terkait mengenai dokumentasi seperti apa yang diharapkan oleh masyarakat.
-Jika resiko tersebut sudah terjadi, kita dapat meminta kepada masyarakat untuk memberikan respon maupun review atas dokumentasi tersebut, dan berusaha memperbaikinya.

2.3 Resiko yang berhubungan dengan masyarakat
a. Masyarakat belum/tidak bisa memastikan apa yang dibutuhkannya.
Resiko ini dikarenakan oleh masyarakat yang tidak tahu pasti apa yang dibutuhkannya, mungkin akibat masyarakat belum mempersiapkan diri terhadap perkembangan teknologi yang terbaru.
Solusi :
-Menggali informasi tentang keadaan masyarakat, apa yang dibutuhkan. Sehingga kita bisa membantu memberikan saran tentang apa yang mereka butuhkan.
-Meminta kepada masyarakat untuk mempersiapkan kebutuhannya terlebih dahulu, atau meminta kepada dinas-dinas yang terkait untuk meminta kritik, saran dan masukan terhadap sistem yang akan dibangun.

b. Dinas-dinas kurang berkomunikasi dengan developer untuk saling memberi informasi.
Dinas-dinas kurang berkomunikasi dengan developer untuk memberitahu apa yang masyarakat butuhkan dan apakah progress yang telah dilakukan telah sesuai dengan keinginan masyarakat.
Solusi :
-Mengadakan jejak pendapat melalui beberapa wakil rakyat
-Membuat report dan simulasi yang sesingkat dan sedetil mungkin supaya masyarakat dapat melakukan koreksi.

c. Masyarakat tidak mengerti proses pengembangan software.
Akibat masyarakat tidak mengerti proses pengembangan software, maka persepsi masyarakat tentang jadwal produksi, besar project, sulit tidaknya suatu project kemungkinan salah.
Solusi :
-Memberikan gambaran global tentang proses pengembangan software, dan memberikan keterangan sesederhana dan sedetil mungkin.

2.4 Resiko proses
a. Tidak semua staff bersedia untuk mengikuti proses yang telah ditentukan.
Resiko kemungkinan staff tidak mampu untuk mengikuti prosedur yang telah ditentukan, baik karena alasan skill, waktu, dan lain-lain.
Solusi :
-Menyusun ulang pembagian tugas dari masing-masing staff.
-Mengganti staff tersebut dengan yang lebih mampu

b. Kesulitan pengaturan jadwal untuk melakukan review teknis.
Para staff memiliki jadwal yang berbeda-beda sehingga mereka tidak dapat melakukan koordinasi dengan baik.
Solusi :
-Project Manager harus mengatur jadwal yang tepat untuk masing-masing staff.
-Masing-masing staf sejak awal harus berkomitmen untuk meluangkan waktunya.

c. Metode testing yang ada kurang sesuai.
Metode Pengetesan yang dilakukan ternyata tidak dapat diterapkan pada software tersebut.
Solusi :
-Mencari metode testing yang lebih baik, dengan cara merapatkannya dengan staff, mencari metode testing yang lebih efektif.

2.5 Resiko teknologi
a. Tidak semua staff menguasai/telah mengenal tools yang akan digunakan.
Para staff memiliki kemampuan yang berbeda-beda sehingga tools yang mereka kuasai juga tidak sama.
Solusi :
-Memilih staff yang telah mengenal tools tersebut.
-Mengadakan training singkat untuk staff yang belum menguasainya.

b. Project membutuhkan inovasi oleh developer.
Solusi :
-Mengumpulkan bahan-bahan yang diperlukan dan melakukan riset untuk persiapan project tersebut.

2.6 Resiko peralatan pengembangan
a. Software project/proses manajemen tidak tersedia.
Solusi :
-Mencari software tersebut terlebih dahulu.
-Tidak tersedianya software development untuk yang dibutuhkan.
-Mencari alternatif software yang dapat menggantikannya.

b. Tidak tersedianya referensi yang cukup untuk peralatan yang digunakan.
Solusi :
-Mencari referensi dari buku, internet, majalah, dan sebagainya.

c. Staf belum terlatih untuk menggunakan tools yang ada.
Solusi :
-Mengadakan training singkat mengenai tools tersebut.
-Memberikan buku panduan yang harus dipelajari sendiri oleh staff tersebut.

2.7 Resiko yang berhubungan dengan jumlah staf dan pengalaman.
a. Tidak tersedianya kombinasi staff dengan kemampuan yang tepat.
Solusi :
-Menyusun ulang pembagian tugas antar staf.
-Merekrut staf baru yang memiliki kemampuan seperti yang dibutuhkan.

b. Jumlah staff tidak memadai.
Solusi :
-Merekrut staf baru.
-Mengefektifkan kerja para staf.
-Menambah jumlah jam kerja setiap staf.

c. Staf mengundurkan diri.
Solusi :
-Merekrut staff baru.
-Mengefektifkan kerja para staf.
-Menambah jumlah jam kerja setiap staf.

2.8 Resiko komponen dan pengendali.
a. Performa sistem tidak seperti yang diharapkan.
Solusi :
-Melakukan kompilasi ulang dengan mengoptimalkan dan memperbaiki software.

b. Harga hardware dan software di luar perkiraan.
Solusi :
-Melakukan pencegahan dengan menyediakan dana cadangan dalam estimasi.

c. Software tidak bisa dikoreksi/diubah.
Solusi :
-Melakukan kompilasi software dari awal dengan terlebih dahulu memperbaikinya.

d. Project di luar jadwal yang ditentukan.
Solusi :
-Melakukan pencegahan dengan menambahkan waktu pada estimasi.

III. Analisa Risiko
Setelah melakukan identifikasi risiko, maka tahap berikutnya adalah pengukuran risiko dengan cara melihat potensial terjadinya seberapa besar severity (kerusakan) dan probabilitas terjadinya risiko tersebut. Penentuan probabilitas terjadinya suatu event sangatlah subyektif dan lebih berdasarkan nalar dan pengalaman. Beberapa risiko memang mudah untuk diukur, namun sangatlah sulit untuk memastikan probabilitas suatu kejadian yang sangat jarang terjadi. Sehingga, pada tahap ini sangatlah penting untuk menentukan dugaan yang terbaik supaya nantinya kita dapat memprioritaskan dengan baik dalam implementasi perencanaan manajemen risiko.
Kesulitan dalam pengukuran risiko adalah menentukan kemungkinan terjadi suatu risiko karena informasi statistik tidak selalu tersedia untuk beberapa risiko tertentu. Selain itu, mengevaluasi dampak severity (kerusakan) seringkali cukup sulit untuk asset immateriil.

Tujuan dari Analisis Risiko
Tujuan utama tentang melakukan Analisis Risiko adalah untuk mengukur dampak dari ancaman-ancaman yang berpotensi untuk berdampak terhadap sistem, serta untuk menafsir kebutuhan atau nilai terhadap kemampuan organisasi yang hilang akibat ancaman-ancaman tersebut.
Kedua hasil utama dari suatu analisis resiko adalah identifikasi dari resiko-resiko dan pertimbangan kerugian / keuntungan dari pengantisipasian ancaman-ancaman tersebut - merupakan hal yang sangat penting pada saat pembuatan suatu strategi peringanan resiko.
Selain itu, juga mempengaruhi proses pengambilan keputusan yang bersangkutan dengan konfigurasi perangkat keras dan desain sistem perangkat lunak. Dan juga dapat mempengaruhi keputusan-keputusan konstruksi dan perencanaan.

Bahaya yg Beresiko Tinggi
Didasarkan pada dua penilaian ancaman yaitu:
- Probabilitas atau kemungkinan terjadinya peristiwa dan
- Dampak, kerugian atau kerusakan yang ditimbulkan
Hasil penelitian kemudian di plot ke dalam matriks pemilihan resiko

Probabilitas Kejadian
Skala Probabilitas:
5 Sangat Pasti (hampir dipastikan 100% terjadi tahun depan, atau terjadi setiap tahun).
4 Hampir Pasti (75 –100% terjadi tahun depan, atau sekali dalam 5 tahun mendatang)
3 Mungkin (50 -75 % terjadi tahun depan, atau sekali dalam 10 tahun)
2 Kemungkinan Kecil (20-50 % terjadi tahun depan atau sekali dalam 25 tahun)
1 Tidak Pasti (1 –20 % terjadi tahun depan atau sekali dalam lebih dari 50 tahun)

Dampak Kejadian
Dampak Kerugian yang ditimbulkan:
5 Sangat Parah (hampir dipastikan SIMDA tidak dapat dilaksanakan 100%)
4 Parah (SIMDA dapat terlaksana 50-75%)
3 Cukup Parah (SIMDA dapat terlaksana 10-50 %)
2 Ringan (SIMDA dapat terlaksana kurang 10%)
1 Tidak Parah (dampak terkecil)

Penilaian Bahaya

P= Probabilitas (skala 1-5)
D= Dampak (skala 1-5)

MATRIKS RESIKO



Dari gambar matriks resiko, bisa dibuat prioritas dari kemungkinan resiko yang telah dibuat dimana:

1. Prioritas utama, yaitu resiko estimasi
   
2. Prioritas menengah, yaitu resiko yang berhubungan dengan masyarakat (eksternal) dan resiko peralatan pengembangan
   
3. Prioritas kecil , yaitu resiko pengaruh organisasi (internal), resiko proses, resiko teknologi, resiko yang berhubungan dengan jumlah staf dan pengalaman dan resiko komponen dan pengendali.

Bisa dibaca pada artikel manajemenresikonia_811.pdf
Sumber:
waspada-pmk.pdf
proses_manajemen_risiko.pdf
perancangan_software_sistem_informasi_akademik_ftui.pdf
manajemen-bencana-materi-2-penentuan-resiko.pdf
introduction.pdf
121p-01-final10-security_management_practice.pdf
project_mgtproposal_tender.pdf

Read More..

Sistem Informasi Daerah

Tulisan ini bisa didapatkan pada estimasnia-811.pdf

Perhitungan COCOMO bisa digunakan untuk mengetahui jenis proyek, menghitung Person Month (perbandingan antara waktu dan tenaga yang dibutuhkan), Durasi (waktu yang dibutuhkan untuk menyelesaikan proyek), tim size (tenaga yang dibutuhkan). Metode Function Point pertama kali diusulkan oleh Albrecht dan Gaffney. Pada metode ini, ukuran proyek dapat dihitung oleh tiga komponen yaitu ukuran proses informasi (Unadjusted Function Points-UFP), faktor penyesuaian kompleksitas dan Function Points. Komponen tersebut dianalisa sebagai berikut:

Unadjusted Function Points - UFP
Fitur ini disebut juga sebagai ukuran proses informasi. Ukuran ditentukan oleh identifikasi komponen eksternal sistem atau logical input, output, pemeriksaan (inquiry), external interface ke sistem lain dan logical internal file. Komponen ini memiliki kategori "mudah", "menengah" atau "komplek" tergantung pada karakteristik yang dimiliki. Lalu jumlah dari semua komponen disebut Unadjusted Function Points (UFP). Kategori yang dimiliki digambarkan pada tabel 1 dibawah [Symons,88]. Dengan catatan jumlah keseluruhan didapatkan dengan mengalikan kategori yang dipilih (mudah, menengah atau komplek).

Sesuai dengan kategori yang dimiliki SIMDA, maka perhitungan UFP adalah:

• Eksternal input mudah 3 x3 = 9
• Eksternal output mudah 4 x4 = 16
• User menengah 4 x4 = 16
• File komplek 15 x15 = 225
• Eksternal interface menengah 7 x7 = 49

sehingga bisa didapatkan UFP = 9+16+16+225+49
UFP = 315

Perhitungan Kompleksitas Teknis
Perhitungan ini dihasilkan dari perhitungan technical complexity factor (TCF). TCF dihitung dengan melakukan penilaian 14 pertanyaan yang ditunjukkan pada table 2 [Pressman,87] dari 0 sampai 5 dimana



Sesuai dengan kategori yang dimiliki SIMDA, maka perhitungan TCF adalah:

1. Backup dan recovery dapat dipercaya 5
2. Komunikasi data 4
3. Fungsi distribusi 4
4. Performansi 4
5. Lingkungan operasional 4
6. Data entry on-line 5
7. Layar interaktir untuk input 3
8. Online update 4
9. Kompleksitas interface 3
10. Bisa digunakan kembali (reusability) 3
11. Kompleksitas proses 3
12. Kemudahan dalam install 3
13. Memiliki banyak site 3
14. Mudah digunakan 4

sehingga bisa didapatkan TCF = 5+4+4+4+4+5+3+4+3+3+3+3+3+4

TCF = 52

Perhitungan Function Point
Sesuai dengan SIMDA, maka perhitungan Function point dihitung dengan menggunakan rumus:



Sehingga didapatkan FP = 315 x (0.65 + 0.01 * 52)
FP = 368,55

Konversi FP-ke-NCSS
Setelah function point dihitung, sesuai dengan table 3 digunakan untuk konversi ke NCSS yang diusulkan oleh Albrecht dan Gaffney [83].



Karena SIMDA menggunakan bahasa C, maka didapatkan perhitungan konversi dimana konversi NCSS = FP * NCSS
konversi NCSS = 368,55 * 70
konversi NCSS = 25798,5

Menurut ide dasar COCOMO, proyek dibagi menjadi dua kategori yaitu poyek kecil dan proyek besar, dimana masing-masing proyek tersebut memiliki ciri-ciri sebagai berikut:

Proyek Kecil

• Tim memiliki anggota sedikit (2-3 orang)
• Mudah dimodelkan
• Memiliki penyelesaian tidak terlalu rumit
• Perhitungan EFFORT = a * SIZE + b
  

Proyek Besar

• Semakin banyak tim yang dimiliki, semakin komplek proyek yang akan dikerjakan
• Perhitungan EFFORT = a * SIZE b

Dimana a dan b adalah faktor penskalaan

Selain itu COCOMO memiliki kriteria tipe proyek, yaitu organik, semi detached dan embedded dimana masing-masing kriteria memiliki ciri-ciri sebagai berikut:

Organik

• Merupakan proyek rutinitas
• Proyek yang dikerjakan mudah dipelajari
• Tim work bekerja scara efisien
• Proyek yang dikerjakan memiliki sedikit hambatan
• Umumnya sistem kecil

Semi-Detached

• Pada pertengahan antara organic dan embedded
• Memiliki sistem yang kompleks, tetapi proyek bukanlah sesuatu yang baru
• Tim bisa terdiri dari tenaga yang berpengalaman dan belum berpengalaman

Embedded

• Memiliki tingkat kesulitan lebih bila dibandingkan organik dan semi detached
• Proyek yang dikerjakan cukup besar (software untuk kontrol nuklir, atau pesawat luar angkasa)
• Tim sebagian besar terdiri dari tenaga yang berpengalaman
• Proyek yang dikerjakan merupakan sesuatu yang baru
• Biasanya memiliki hambatan yang cukup besar

Berdasarkan kriteria kategori proyek COCOMO, SIMDA merupakan proyek besar, sehingga memiliki Perhitungan EFFORT = a * SIZE b. Selain itu SIMDA merupakan tipe proyek Semi detached sehingga sesuai dengan table 4, SIMDA memiliki nilai a dan b masing-masing yaitu a = 3.0 dan b = 1.12.

Perhitungan Unadjusted function Point – UFP digunakan untuk mengetahui SIZE yang dimiliki SIMDA. Sehigga bisa diketahui SIZE yang dimiliki SIMDA adalah 315.Untuk mengetahui berapa banyak usaha (Effort) untuk menyelesaikan SIMDA, maka digunakan rumus



EAF adalah Effort Adjustment Factor sesuai dengan table 5




Berdasarkan table 5, EAF yang dimiliki SIMDA, memiliki detail:

• Required software reliability high 1.15
• Database size high 1.08
• Main storage high 1.06
• Programmer capability low 1.17
• Programming language experience low 1.07
• Use of software tools low 1.10
• Required development schedule low 1.08

Sehingga bisa ditentukan Person Month (PM), yaitu:
PM = EAF * a * SIZE b
PM = (1.15 * 1.08 * 1.06 * 1.17 * 1.07 * 1.10 * 1.08) * 3.0 * (315) 1.12
PM = 1,958 * 3.0 * 628,214
PM = 3690,138
3690 PM yang dibutuhkan untuk menyelesaikan proyek SIMDA

Berdasarkan table 6, bisa ditentukan waktu yang dibutuhkan untuk menyelesaikan SIMDA

Duration = 2.5 * Effort 0.35
Duration = 2.5 * (3690) 0.35
Duration = 44,300
Waktu yang dibutuhkan sebanyak 44 bulan

Orang yang dibutuhkan untuk menyelesaikan proyek SIMDA
3690,138 / 44,300 = 83,298

Sehingga untuk menyelesaikan proyek SIMDA dibutuhkan 83 orang

Perhitungan COCOMO disini berdasarkan proposal Sistem Informasi Daerah (SIMDA), bisa didapatkan pada
simda_proposal.pdf
tgsproposalnia-811.ppt

Sumber perhitungan COCOMO bisa didapatkan pada
tutorial-oct25.pdf

Read More..

Perbandingan Microsoft Word (Windows) dan OpenOffice (Linux)

Perbandingan Windows dan Linux (dua sistem operasi komputer) telah menjadi topik sebagai bahan diskusi diantara para pengguna. Windows merupakan sistem operasi yang banyak dikenal orang dan merupakan software legal (memiliki license), sedangkan Linux merupakan sistem operasi yang bisa didapatkan secara bebas (tanpa license). Dua sistem operasi ini bersaing untuk penggunaan personal computer market sebagai server market, dan digunakan pada kantor pemerintahan, sekolah, kantor, rumah, intranet dan internet servers [1].

Standard Linux Solution vs. Microsoft Solution [2]
Perbedaan antara Windows dan Linux dari keuntungan yang bisa didapat pada:
Hardware dan infrastruktur yang telah digunakan sampai saat iniPembelian hardware dan infrastruktur baru

Bila dilihat dari table, didapatkan kesimpulan bahwa Microsoft memiliki keuntungan lebih banyak daripada Linux Standard. Dimana Microsoft mendapatkan keuntungan sebesar 36% sedangkan Linux sebesar 26%
Perbedaan antara Windows dan Linux dari keuntungan yang bisa didapat pada perbendiangan harga produk.

Bisa disimpulkan bahwa apabila kita menginginkan produk OpenOffice dari Linux, maka kita bisa mendapatkannya secara gratis. Sedangkan bila kita menginginkan produk Microsoft Office Standard, maka kita perlu mengeluarkan biaya sebesar $399,00.

Daftar Hardware, Software dan Biaya Operasional

Pada daftar hardware antara Windows dan Linux (standard), tidak ada perbedaan biaya. Sedangkan untuk software, Windows membutuhkan biaya yang lebih besar bila dibandingkan dengan Linux (standard).
Pada biaya operasional, Linux (standard), beberapa bagian diperlukan biaya yang lebih tinggi bila dibandingkan dengan Windows. Diantaranya: Gaji staff, biaya konsultan.


Penggunaan Microsoft Word dan OpenOffice.org Writer memiliki perbedaan, diantaranya [3]:

Kesimpulan [4]:
Hampir sebagian software Linux bisa konsumen dapatkan secara bebas di internet. Hal ini dilakukan karena kemampuan daya beli konsumen masih kurang. Bisa dilihat bahwa bila konsumen menginginkan software Windows, maka konsumen diharuskan membayar software yang dibutuhkan tersebut. Tetapi di sisi lain, konsumen lebih familiar menggunakan Windows daripada Linux. Alasan inilah mengapa Windows masih dapat mempertahankan pangsa pasar yang dimiliki.

Sumber:

1nop-pengantar_singkat_migrasi_windows_linux-rev0.pdf
2linux_vs_windows_tco_comparison.pdf
3openoffice.pdf
4komputer_berbasis_gnulinux_dan_peluang_bisnisnya.pdf

Read More..

Software Proyek Manajemen Organizing

Aktifitas dalam software proyek manajemen meliputi beberapa proses, diantaranya organizing yang bertujuan agar perusahaan dapat mengatur suatu kegiatan yang berada pada sebuah kelompok
Project FileAmigo 7 merupakan salah satu software digunakan untuk organizing pada manajemen proyek, yang bisa di-download pada situs www.fileamigo.com/Home.htm

atau bisa dibaca User Guide menggunakan software FileAmigo 7

userguide-fileamigo7.doc

Dengan project FileAmigo 7 kita dapat memilih jenis file yang kita inginkan
Keuntungan yang bisa didapatkan menggunakan FileAmigo 7 adalah telah tersedianya beberapa template sesuai dengan kebutuhan pengguna. Selain itu pengguna dapat melakukan customize terhadap template yang dibutuhkan. FileAmigo 7 mirip dengan Microsoft Access, hanya saja dikemas sedimkian rupa sehingga pengguna yang belum familiar dengan Microsoft Access dapat menjalankan FileAmigo dengan mudah

hanya saja Software FileAmigo 7 tidak dijual bebas, dengan kata lain, pengguna hanya bisa mendapatkan software berupa trial selama 30 hari
Hasil report menggunakan FileAmigo 7 bisa di download pada

reportaddressbookfileamigo.doc

Read More..

Perbedaan antara Software Project dan Software Proses

Software Project memiliki kesepakatan waktu, resource, mendapatkan keuntungan

Sumber daya: management, analyse, designer

Hasil: jadwal / planning, anggaran, proposal, laporan pengembangan proyek

Aktifitas: Planning, Organizing, Action & Controlling

Software Proses untuk memenuhi kebutuhan unsur: weaknes, protability yang bertujuan untuk mendapatkan software yang baik (good product)

Sumber daya: human capital, modal, tool & waktu

Tool digunakan untuk schedulling, acoounting, programming

Hasil: source code, data, desain, SRS

Aktifitas: model proses, misalnya waterfall à requirement analysis, prototipe

Read More..

Pendahuluan Manajemen Proyek Perangkat Lunak (MPPL)

MPPL singkatan dari Manajemen Proyek Perangkat Lunak.
Fungsi mempelajari MPPL adalah transparasi, performa, integrasi antar software& optimasi.
Sebelum mengenal lebih jauh MPPL, kita perlu mengetahui arti dari setiap kata

bisa didownload pada haripertamamppl.doc

Read More..

Manajemen Resiko

Manajemen Resiko

Microsoft Solutions Framework

1. Abstrak

Manajemen resiko adalah suatu pengetahuan dasar mengenai Microsoft Solution Framework (MSF). MSF mengenali adanya perubahan dan yang berkaitan dengan ketidak-pastian dimana perubahan tersebut tidak bisa dipisahkan dari kegiatan Information Technology.

MSF Manajemen resiko merupakan suatu disiplin ilmu yang mendasari suatu pendekatan proaktif yang berhubungan dengan ketidak-pastian, menaksir resiko secara terus-menerus, dan menggunakan resiko untuk mempengaruhi pengambilan keputusan dalam jangka waktu yang panjang. Disiplin ilmu ini menguraikan prinsip, konsep, dan bimbingan bersama-sama melalui five-step untuk mencapai kesuksesan manajemen resiko, dimana setiap langkahnya saling berhububungan, diantaranya adalah: mengidentifikasi resiko, meneliti resiko, strategi peringanan dan ketidaktentuan rencana, mengendalikan status resiko, dan belajar dari hasil resiko.

2. Dasar Resiko

Suatu aspek manajemen proyek yang penting adalah mengendalikan permasalahan yang selalu berhubungan dengan resiko dari suatu proyek. Resiko dibangun dari ketidak-pastian yang meliputi, merancang hasil dan keputusan. Kebanyakan individu selalu berhubungan antara konsep resiko dengan potensi kerugian pada suatu nilai, kendali, kemampuan, mutu, atau ketepatan waktu penyelesaian dari suatu proyek. Bagaimanapun, merancang hasil boleh jadi mengakibatkan kegagalan, untuk memaksimalkan keuntungan pada kesempatan dan ketidak-pastian dalam pengambilan keputusan yang terarah, jika mendahului hasil ini dapat juga dikatakan melibatkan suatu unsur resiko. Di dalam MSF, suatu resiko dari suatu proyek dapat digambarkan sebagai kondisi atau peristiwa yang mempunyai dampak positif atau negatif pada hasil dari suatu proyek. Konsep ini bersifat untung-untungan dan dapat digunakan oleh industri keuangan di mana keputusan mengenai ketidak-pastian berhububgan dengan potensi untuk keuntungan seperti halnya kerugian, sebagai lawan konsep dari resiko murni yang digunakan oleh industri asuransi di mana ketidak-pastian dihubungkan dengan kerugian potensi masa depan.

3. Konsep Utama

3.1 Resiko yang tidak dapat dipisahkan pada setiap Proyek atau Proses

Walaupun setiap proyek memiliki kemungkinan resiko yang berbeda, tidak ada proyek yang sepenuhnya bebas dari resiko. Proyek dijalankan oleh suatu organisasi dalam mencapai tujuan yang menyertakan nilai sebagai dukungan tujuan organisasi. Selalu ada ketidak-pastian melingkupi proyek dan lingkungan yang dapat mempengaruhi kesuksesan dalam menuju keberhasilan tujuan. Dengan selalu mengingat resiko yang tidak bisa dipisahkan, MSF mencari jalan dalam membuat kebenaran keputusan antara kesempatan dan resiko dan tidak membuat kebenaran tersebut menjadi prioritas apabila resiko diminimalkan.

3.2 Manajemen Resiko Proaktif adalah Manajemen Resiko yang Paling Efektif

MSF mengadopsi suatu pendekatan proaktif untuk mengidentifikasi, meneliti, dan mengarahkan resiko dengan memusatkan pada:

§ Mengantisipasi permasalahan bukannya hanya bereaksi terhadap resiko manakala resiko terjadi.

§ Menunjukan sebab utama sebagai ganti tidak hanya berhadapan dengan gejala.

§ Sudah merencanakan resolusi masalah sebelum suatu masalah terjadi.

§ Menggunakan suatu proses dikenal, tersusun, dapat diulang untuk resolusi masalah.

§ Menggunakan ukuran pencegah kapan saja dimungkinkan.

3.3 Perlakukan Identifikasi Resiko sebagai suatu Hal yang Positif

Manajemen resiko efektif tergantung pada pemahaman yang menyeluruh dan menyangkut resiko yang diahadapi oleh tim proyek. Ketika variasi tantangan dan besarnya kerugian menjadi jelas, aktivitas resiko dapat menjadi suatu aktivitas yang menakutkan bagi tim proyek. Beberapa anggota tim boleh mengambil pandangan mengenai resiko dalam mengidentifikasi untuk mencari pertimbangan yang bisa menjadi penghambat kesuksesan proyek. MSF mengadopsi proses perspektif yang mengidentifikasi resiko dan mengijinkan tim untuk mengatur resiko lebih secara efektif dengan membuat penyelesaian resiko bersifat terbuka, sehingga meningkatkan prospek kesuksesan tim, diskusi resiko terbuka, yang didokumentasikan membebaskan anggota tim untuk berkonsentrasi pada pekerjaan mereka dengan menyediakan klarifikasi peran secara tegas (eksplisit), tanggung-jawab, dan merencanakan untuk aktivitas sebagai pencegah dan ukuran mengoreksi untuk permasalahan.

3.4 Penilaian Berlanjut

Banyak teknologi informasi para profesional manajemen resiko, paling baik, diperlukan tetapi merupakan tugas yang membosankan pada awal proses, karena hal ini suatu proyek yang baru..

3.5 Maintain Open Communications

Walaupun resiko biasanya dikenal oleh beberapa anggota tim, informasi ini kurang dikomunikasikan. Mungkin komunikasi bisa berjalan lancar pada level yang sama, tetapi belum tentu komunikasi berjalan pada level yang lebih tinggi. Pada tiap level, orang ingin memahami tentang resiko dari tingkat yang lebih rendah tetapi adalah perlu diperhatikan untuk berkomunikasi informasi pada level yang lebih tinggi. Arus informasi yang terbatas mengenai resiko adalah suatu pendukung kuat untuk merancang resiko yang menyebabkan pemaksaan dalam pengambilan keputusan tentang resiko bahkan lebih sedikit informasi. Di dalam organisasi yang hirarkis, para manajer harus mendorong dan memperlihatkan komunikasi terbuka tentang mengambil resiko dan memastikan bahwa resiko dan rencana resiko sungguh dipahami oleh semua orang.

3.6 Tetapkan, kemudian Mengatur

Manajemen resiko mempunyai kaitan dengan pengambilan keputusan pada ketidak-pastian. Statemen resiko yang umum memuaskan ketidak-pastian dan mendorong penafsiran yang berbeda mengenai resiko. Perjelas statemen resiko dalam tim proyek:

§ Memastikan bahwa semua anggota tim mempunyai pemahaman sama dari resiko.

§ Pemahaman penyebab atau penyebab dari resiko dan hubungan kepada permasalahan yang boleh muncul.

§ Menyediakan dasar usaha perencanaan dan analisa kuantitatif, bersifat formal.

§ Membangun kepercayaan oleh stakeholders dan mensponsori kemampuan tim proyek untuk mengatur resiko.

3.7 Jangan Menilai Situasi dari Banyaknya Resiko

Walaupun anggota tim proyek dan stakeholders sering merasa materi resiko sebagai hal negatif, adalah penting tidak untuk menilai suatu proyek atau proses operasional pada banyaknya resiko dikomunikasikan. Resiko, betapapun, adalah kemungkinan, yang bukan kepastian dari suatu kerugian atau suboptimal hasil. MSF mendukung proses manajemen resiko dalam penggunaan proses analisa dan identifikasi resiko tersusun untuk menyediakan pembuat keputusan dengan tidak hanya informasi pada kehadiran resiko hanyalah arti penting resiko itu juga.

4. Proses Manajemen Resiko

Gambar 1. Proses Manajemen Resiko

Identifikasi Resiko mengijinkan individu mengambil resiko sehingga tim menjadi sadar akan suatu potensi masalah. Ketika masukan kepada manajemen resiko memproses, mengambil identifikasi resiko harus dikerjakan pertma kali lalu kemudian dapat diulangi selama sepanjang proyek dijalankan.

Analisis risiko mengubah bentuk data atau perkiraan tentang proyek mengambil resiko spesifik yang dikembangkan selama identifikasi resiko ke dalam suatu format dimana tim dapat menggunakan untuk membuat keputusan menjadi prioritas. Resiko membuat daftar prioritas memungkinkan tim untuk merancang sumber daya dalam mengatur resiko yang paling utama.

Perencanaan Resiko mengambil informasi dari analisis risiko dan penggunaannya digunakan untuk merumuskan strategi, rencana, dan tindakan. Resiko yang terjadwal memastikan bahwa rencana ini disetujui kemudian menyatukan dengan manajemen proyek proses dan infrastruktur standard untuk memastikan bahwa manajemen resiko dilaksanakan sebagai bagian dari aktivitas sehari-hari oleh tim. Resiko penjadwalan dengan tegas menghubungkan perencanaan resiko dengan perencanaan proyek.

Pelacakan Resiko mengikuti jalannya dalam memonitor status mengenai resiko yang spesifik dan kemajuan di dalam rencana tindakan masing-masing resiko. Mengambil resiko perkerjaan mengikuti jalan meliputi monitoring kemungkinan, dampak, penjabaran, dan ukuran resiko untuk perubahan yang bisa mengubah prioritas atau merencanakan resiko dan sumber daya proyek atau jadwal. Perkerjaan mengikuti jalan resiko memungkinkan proses manajemen resiko di dalam proyek dari perspektif tingkatan resiko sebagai lawan perspektif penyelesaian tugas dari manajemen proyek proses operasional standard.

Dokumentasi Resiko yang melaporkan dan memastikan bahwa tim proyek, sponsor, dan stakeholders menyadari status proyek dalam mengambil resiko dan rencana untuk mengatur resiko.

Kendali Resiko adalah proses pelaksanaan mengambil rencana tindakan resiko dan status yang dihubungkan dengan dokumentasi. Kendali resiko meliputi inisiasi kendali perubahan proyek meminta apabila ada perubahan di dalam status resiko atau mengambil resiko rencana yang bisa mengakibatkan perubahan di dalam sumber daya proyek atau jadwal.

Pembelajaran Resiko dimana belajar menyusun dan mempelajari relevan dalam merancang bentuk dan tool dan menangkap pengetahuan di dalam daftar yang telah terdokumentasi untuk penggunaan kembali di dalam tim proyek dan oleh perusahaan.

5. Identifikasi Resiko

Gambar 2. Identifikasi Resiko

5.1 Klasifikasi Resiko

Mengambil klasifikasi resiko, kadang-kadang memiliki taksonomi resiko, melayani berbagai tujuan untuk suatu tim proyek. Selama identifikasi resiko yang dapat digunakan untuk merangsang berpikir tentang resiko yang timbul di dalam lingkup proyek yang berbeda. Selama pengungkapan pendapat klasifikasi resiko dapat juga menenangkan kompleksitas dalam bekerjasama dengan sejumlah besar resiko dengan menyediakan suatu cara menyenangkan untuk pengelompokan resiko. Mengambil klasifikasi resiko juga memungkinkan digunakan untuk menyediakan suatu istilah umum bagi tim untuk menggunakan dalam memonitor dan melaporkan status resiko sepanjang pengerjaan proyek. Akhirnya, mengambil klasifikasi resiko merupakan hal yang kritis untuk penetapan berjalannya perusahaan dan industri mengambil resiko merupakan dasar pengetahuan sebab mereka menyediakan dasar untuk pengurutan (indexing) kontribusi yang baru dan mencari dan mendapat kembali pekerjaan ada.

5.2 Mengambil Statemen Resiko

Suatu statemen resiko adalah suatu ungkapan bahasa alami yang menyatakan hubungan sebab akibat antara kondisi proyek riil, yang ada atau atribut, dan potensial, yang tidak direalisir, kondisi atau atribut.

Gambar 3. Mengambil Statemen Resiko

6. Analisa dan Prioritas Resiko

Gambar 4. Analisa dan Prioritas Resiko

6.1 Aktifitas Analisis risiko

Banyak teknik secara kuantitatif dan kualitatif untuk memenuhi prioritisas dari suatu daftar resiko. Satu teknik mudah untuk analisis risiko akan menggunakan perkiraan tim konsensus dua komponen resiko yang diterima, kemungkinan, dan dampak. Jumlah ini kemudian bisa dikalikan bersama-sama untuk mengkalkulasi ekspose resiko disebut metrik tunggal.

6.2 Mengambil Kemungkinan Resiko

Kemungkinan resiko adalah suatu ukuran menyangkut kemungkinan yang menguraikan kondisi di dalam konsekuensi resiko dalam membagi statemen resiko akan benar-benar terjadi. Penggunaan suatu nilai kuantitatif untuk kemungkinan resiko adalah diinginkan untuk mengatur resiko.

6.3 Dampak Resiko

Dampak resiko adalah suatu perkiraan menyangkut efek dari kurang baiknya, atau besarnya kerugian, atau biaya yang memerlukan kesempatan potensi suatu resiko di dalam suatu proyek. Haruslah suatu ukuran yang langsung menyangkut konsekuensi resiko seperti dirumuskan dalam statemen resiko. Kejadian itu diukur di dalam terminologi keuangan atau dengan suatu skala pengukuran hubungan

6.4 Mengambil Penjabaran Resiko

Mengambil penjabaran resiko berguna untuk mengukur keseluruhan ancaman dari resiko, mengkombinasikan informasi menyatakan kemungkinan dari kerugian nyata dengan informasi menyatakan besarnya kerugian dalam klasifikasi tunggal kemudian bisa menggunakan besarnya penjabaran resiko untuk digolongkan menjadi suatu resiko. Di dalam format yang yang paling sederhana dari analisis risiko kuantitatif, penjabaran resiko dihitung dengan perkalian kemungkinan resiko dan dampak.

7. Resiko Perencanaan dan Penjadwalan

Gambar 5. Resiko Perencanaan dan Penjadwalan

Tujuan

Tujuan Utama dari perencanaan dan penjadwalan langkah resiko akan mengembangkan rencana terperinci untuk mengendalikan resiko puncak yang dikenali selama analisis risiko dan untuk mengintegrasikan resiko dengan manajemen proyek proses standard untuk memastikan bahwa resiko bisa diselesaikan.

8. Resiko Pelacakan dan Dokumentasi

Gambar 6. Resiko Pelacakan dan Dokumentasi

Tujuan

Tujuan dari perkerjaan ini adalah memonitor status dari rencana tindakan resiko atau kemajuan ke arah penyelesaian rencana peringanan dan ketidaktentuan, untuk memonitor ilmu tentang banyaknya proyek yang telah dihubungkan dengan suatu pemicu rencana darurat, dan menyediakan pemberitahuan kepada regu proyek dimana pemicu rencana darurat telah terlewati sehingga suatu rencana darurat dapat diaktifkan.

9. Kendali Resiko

Gambar 7. Kendali Resiko

Tujuan

Tujuan dari langkah kendali resiko adalah pelaksanaan yang sukses menyangkut rencana darurat dimana tim proyek telah menciptakan kondisi untuk resiko puncak.

10. Identifikasi dan Manajemen Strategi Resiko

Tabel 1. Identifikasi dan Manajemen Strategi Resiko

11. Pendekatan Top Down pada Pembuatan Model Resiko Kuantitatif

Gambar 8. Pendekatan Top Down pada Pembuatan Model Resiko Kuantitatif

Melalui ilustrasi, pendekatan berikut digunakan untuk membangun suatu model analisis risiko pada jadwal yang ditawarkan sebagai metoda menggunakan pendekatan top-down untuk menetapkan resiko dan ketidak-pastian, melalui.

1. Identifikasi daftar antara empat dan sepuluh kunci dalam merancang batas waktu (banyaknya batas waktu mencerminkan kompleksitas dari proyek). Batas waktu ini harus dipilih pada

a) adanya nilai di mana alur yang berbeda di dalam jadwal proyek ,

b) dapat dihubungkan dengan peristiwa atau produk dirumuskan dengan baik

c) tersebar secara relatif datar ke seberang waktu dan

d) dari minat penting kepada para manajer senior dan stakeholders.

2. Bekerjasama dengan definisi aktivitas yang lebih tinggi, menetapkan suatu first-pass untuk menunjukkan bagaimana batas waktu bisa dijalankan oleh aspek menyangkut penyerahan proyek yang berpotensi time-critical.
3. Mengidentifikasi area yang akan bermanfaat bagi dari suatu derajat tingkat detil aktivitas lebih besar. Detil yang ditingkatkan mungkin dibenarkan jika

a) area tertentu menyangkut jadwal menjadi minat sebab mereka sangat berperan dalam mengambil resiko, atau

b) menghasilkan definisi ketergantungan atau aktivitas yang lebih tepat yang akan meningkatkan, memodelkan peristiwa resiko, integritas dari menaksir resiko atau kebenaran dari analisa jadwal.

Pertimbangan seperti area jadwal yang berhadapan dengan kemungkinan resiko didasarkan pada suatu analisa Monte Carlo pada pemeriksaan dan/atau first pass dari daftar resiko.

4. Bandingkan versi deterministic dari jadwal dalam mengambil resiko dengan rencana proyek yang menggunakan resiko utama dan aktivitas. Kesalahan yang memungkinkan adalah deteksi dan koreksi pada langkah ini. Para manajer dan stakeholders lebih mungkin dibujuk menyangkut analisis risiko integritas jika versi deterministic dari model dapat dibariskan dengan baseline rencana tingkat tinggi. Bagaimanapun, hal itu perlu juga dihargai bahwa suatu keuntungan dalam mengembangkan suatu model resiko jadwal mandiri dengan menyediakan suatu pemeriksaan kebenaran integritas dari proyek.
5. Membuat perkiraan ketidak-pastian janga waktu untuk masing-masing aktivitas. Perkiraan ini harus dibuat melalui suatu metoda tersusun yang memastikan bahwa semua sumber umum juga dipertimbangkan.
6. Mengambil relevan dalam mengambil resiko dari daftar resiko dengan penyebab resiko ke dalam jaringan aktivitas sebagai peristiwa yang akan menambahkan waktu tambahan kepada aktivitas yang perlu dilibatkan apabila resiko terjadi. Resiko bisa dihubungkan dengan sumber sistematik resiko, yang diperhitungkan di dalam janga waktu perkiraan aktivitas, harus tidak diimport ketika akan menghasilkan hitungan ganda. Dengan cara yang sama, ketergantungan resiko yang telah tersembunyi kepada struktur dari jaringan perlu juga dikeluarkan.
7. Memperkenalkan ketergantungan statistik untuk model perilaku kelompok aktivitas dan/atau resiko yang memiliki kemungkinan akan dihubungkan oleh faktor dasar umum. Mata rantai menyebabkan antara resiko dan aktivitas memerlukan korelasi kuat, tetapi kebanyakan, jika tidak semua resiko dan aktivitas akan dihubungkan kepada keseluruhan capaian proyek, seandainya oleh karena pengaruh tentang lingkungan nya. Suatu identifikasi top-down dari sistematik resiko dan strategis membantu ke arah mengidentifikasi di mana adanya korelasi.
8. Menjalankan model jadwal resiko dengan tujuan

a) pembuatan peramalan berdasarkan resiko yang menyangkut batas waktu yang utama terpilih di dalam langkah yang pertama dan

b) mengidentifikasi area menyangkut proyek yang memiliki kemungkinan menjadi penyebab paling utama tidak terlaksanya jadwal.

Read More..

Pendahuluan Manajemen Resiko

1. Pendahuluan

Setiap organisasi mempunyai suatu misi. Pada era digital seperti saat ini, sebagai organisasi menggunakan sistem otomasi teknologi informasi untuk proses informasi sebagai pendukung yang lebih baik, manajemen resiko sebagai peran pengatur asset informasi organisasi, dan misi, dari resiko yang terkait dengan IT
Proses manajemen resiko yang efektif merupakan komponen yang sangat penting dari keberhasilan program keamanan IT. Tujuan prinsip proses manajemen resiko pada sebuah perusahaan harus dijaga oleh suatu organisasi dan kemampuan untuk performansi misi mereka, tidak hanya asset IT. Oleh karena itu, proses manajemen resiko merupakan hal yang sangat penting sebagaimana fungsi teknis yang dibawa oleh keluaran (outcome) IT dalam hasil dan mengatur system IT.

2. Tujuan

Resiko adalah dampak negatif dari suatu kejadian yang terjadi dalam suatu proses, dengan mempertimbangkan beberapa kemungkinan dan dampak dari kejadian tersebut. Manajemen resiko adalah proses identifikasi resiko, memperkirakan resiko, dan mengambil langkah untuk mengurangi resiko pada level yang dapat diterima. Artikel ini berfungsi sebagai dasar untuk mengembangkan program resiko manajemen yang efektif, berisi definisi dan petunjuk praktis yang dibutuhkan untuk menaksir dan mengurangi resiko yang di identifikasi oleh sistem IT. Tujuan terakhir untuk membantu organisasi untuk mengatur IT yang lebih baik-berhubungan dengan misi resiko.
Sebagai tambahan, artikel ini menyediakan informasi tentang pemilihan biaya yang efektif. Sistem ini untuk mengurangi resiko sebagai proteksi yang lebih baik pada misi-informasi dan sistem IT yang diproses, disimpan dan untuk disajikan.
Suatu organisasi bisa memilih untuk menjabarkan atau menyingkat proses keseluruhan dan langkah yang disarankan untuk memperbaiki lingkungan pada pengaturan IT-berhubungan dengan misi resiko.

3. Sasaran

Sasaran manajemen resiko adalah untuk memungkinkan organisasi untuk memenuhi misi
pengamanan sistem IT yang lebih baik dalam menyimpan, memproses atau mem-publish informasi suatu organisasi
untuk membantu manajemen dalam membuat keputusan yang bersifat umum / subyektif dalam mengatur pembelanjaan yang menjadi bagian dari suatu anggaran IT
membantu manajemen dalam memberi hak / mengakui sistem IT atas dasar pendukung dokumentasi sebagai hasil capaian manajemen resiko
Catatan:
Sistem IT adalah sistem pendukung umum (misal : mainframe komputer, Local Area Network) atau aplikasi umum yang bekerja pada sistem pendukung umum dan menggunakan sumber informasi untuk memenuhi kebutuhan user

4. Pengertian manajemen Resiko

Manajemen resiko adalah bagian penting dari strategi manajemen semua perusahaan. Proses dimana suatu organisasi yang sesuai metodenya dapat menunjukkan resiko yang terjadi pada suatu aktifitas menuju keberhasilan di dalam masing-masing aktifitas dari semua aktifitas

Fokus dari manajemen resiko yang baik adalah identifikasi dan cara mengatasi resiko. Sasarannya untuk menambah nilai maksimum kesinambungan (sustainable) organisasi. Tujuan utama untuk memahami potensi upside dan downside dari semua faktor yang dapat memberikan dampak bagi organisasi. Manajemen resiko meningkatkan kemungkinan sukses, mengurangi kemungkinan kegagalan dan ketidakpastian dalam memimpin keseluruhan sasaran organisasi.

Manajemen resiko seharusnya bersifat kontinyu dan mengembangkan proses yang bekerja dalam keseluruhan strategi organisasi dan strategi dalam mengimplementasikan. Manajemen resiko seharusnya ditujukan untuk menanggulangi suatu permasalahan sesuai dengan metode yang digunakan dalam melaksanakan aktifitas dalam suatu organisasi di masa lampau, masa kini dan masa depan
Manajemen resiko harus di-integrasikan dalam budaya organisasi dengan kebijaksanaan yang efektif dan diprogram untuk dipimpin beberapa manajemen senior. Manajemen resiko harus di terjemahkan sebagai suatu strategi dalam teknis dan sasaran operasional, pemberian tugas dan tanggung jawab serta kemampuan merespon secara menyeluruh pada suatu organisasi, dimana setiap manajer dan pekerja memandang manajemen resiko sebagai bagian dari deskripsi kerja. Manajemen resiko mendukung accountability, performansi pengukuran dan reward, mempromosikan efisiensi operasional dari semua level.

Read More..

Why do we read Qur’an

Why do we read Qur’an, even if we can't understand a single Arabic word????This is a beautiful story An old American Muslim lived on a farm in the mountains of eastern Kentucky with his young grandson. Each morning Grandpa wakeup early sitting at the kitchen table reading his Qur’an. His grandson wanted to be just like him and tried to imitate him in every way he could. One day the grandson asked,"Grandpa! I try to read the Qur'an just like you but I don't understand it,and what I do understand I forget as soon as I close the book. What good does reading the Qur'an do?" The Grandfather quietly turned from putting coal in the stove and replied, "Take this coal basket down to the river and bring me back a basket of water." The boy did as he was told, but all the water leaked out before he got back to the house. The grandfather laughed and said, "You'll have to move a little faster next time," and sent him back to the river with the basket to try again. This time the boy ran faster, but again the basket was empty before he returned home. Out of breath, he told his grandfather that it was impossible to carry water in a basket, and he went to get a bucket instead. The old man said, "I don't want a bucket of water; I want a basket of water. You're just not trying hard enough," and he went out the door to watch the boy try again. At this point, the boy knew it was impossible, but he wanted to show his grandfather that even if he ran as fast as he could, the water would Leak out before he got back to the house.

The boy again dipped the basket into river and ran hard, but when he reached his grandfather the basket was again empty. Out of breathe, he said, "See Grandpa, it's useless!" "So you think it is useless?" The old man said, "Look at the basket." The boy looked at the basket and for the first time realized that the basket was different. It had been transformed from a dirty old coal basket and was now clean, inside and out. "Son, that's what happens when you read the Qur'an. You might not understand or remember everything, but when you read it, you will be changed, inside and out. That is the work of Allah in our lives. Read More..

Pembuatan Software Pembuka Program Aplikasi Komputer Berbasis Pengenalan Suara

Nia Saurina-5106201811

Abstrak
Teknologi wicara adalah salah satu teknologi aplikasi yang telah ditemukan beberapa tahun lalu. Salah satunya adalah speaker recognition yang merupakan suatu proses yang sering disebut dengan verifikasi pengucap. Yang berarti mengenali suara dengan cara membandingkan dengan suara standar. Dengan mekanisme kerja pangambilan contoh-contoh suara. Contoh-contoh suara pada speaker verification akan diproses dengan menggunakan metode window hamming dan fast fourier transform (fft). Kemudian setelah itu diproses pada filter bank. Contoh-contoh suara yang telah diproses tersebut akan mengisi data base dari feature-feature program aplikasi. Pada saat ada suara lain yang masuk, akan dicocokkan dengan contoh-contoh suara yang telah ada pada data base dan akan dicari nilai error terkecilnya. Hasil perbandingan suara baru dengan suara contoh dengan nilai error terkecil diasumsikan sama.
Banyak sekali teknologi saat ini yang memanfaatkan teknologi dalam bidang suara, salah satunya adalah robot. Dimana gerakan-gerakan robot diatur dengan suara manusia. Namun banyak persoalan yang terjadi ketika suara dimanfaatkan oleh sebuah sistem karena setiap orang memiliki ciri suara yang berbeda-beda. Suara merupakan modal utama yang dimiliki manusia untuk berkomunikasi dengan orang lain.
Dengan suara manusia dapat memberikan informasi maupun perintah. Salah satu teknologi yang memanfaatkan suara adalah proses login atau password. Dimana mengatasi hal tersebut digunakan proses pengenalan suara yang dikeluarkan oleh manusia.
Pada penelitian yang telah dilakukan oleh Yesika Eka Kartikasari, dibuat sebuah sistem atau software yang memanfaatkan teknologi pengenalan suara (speech Recognition). Sistem ini diharapkan akan mengenali dari speaker dan kemudian hasil dari pengenalan suara tersebut digunakan sebagai perintah untuk membuka aplikasi komputer.
Masalah
Dalam software ini memiliki kesulitan dalam pengambilan data input yang merupakan sinyal suara dengan menggunakan software tcl/tk dan menjadikannya sebagai data standart dalam database. Selain itu bagaimana proses matching sinyal yang masuk dengan sinyal yang ada pada database sehingga sinyal independent bisa dikenali sebagai perintah untuk membuka program aplikasi

Kebutuhan
1. Bahasa pemrograman yang digunakan adalah bahasa C/Tcl/Snack2.2 pada Windows
2. Sistem hanya bisa diakses oleh orang-orang dengan dialek yang umum (dalam hal ini adalah

Jawa)
3. Objek perekam berusia antara 20 thn – 21 thn.
4. Software yang bisa dihubungkan dengan software ini adalah software yang bisa diakses

hanya yang tersimpan dalam database, dalam hal ini adalah microsoft word, excel, explorer,

power point, dan notepad.

Pemodelan Dalam Rekayasa Perangkat Lunak
Pemodelan dalam suatu rekayasa perangkat lunak merupakan suatu hal yang dilakukan di tahapan awal. Di dalam suatu rekayasa dalam perangkat lunak sebenarnya masih memungkinkan tanpa melakukan suatu pemodelan. Hal itu tidak dapat lagi dilakukan dalam suatu industri perangkat lunak. Pemodelan delam perangkat lunak merupakan suatu yang harus dikerjakan di bagian awal dari rekayasa, dan pemodelan ini akan mempengaruhi perkerjaan-pekerjaan dalam rekayasa perangkat lunak tersebut.

1. Proses
Proses memiliki atribut dan karakteristik seperti :

· Understandability, yaitu sejauh mana proses secara eksplisit ditentukan dan bagaimana kemudahan definisi proses itu dimengerti. Dengan menggunakan software ini, maka suara yang digunakan sebagai masukan dapat memberikan instruksi pada komputer.

· Visibility, apakah aktivitas-aktivitas proses mencapai titik akhir dalam hasil yang jelas sehingga kemajuan dari proses tersebut dapat terlihat nyata/jelas. Pengoperasian aplikasi komputer dapat dilakukan dengan menggunakan perintah suara. Keberhasilan sistem dapat ditunjukkan keberhasilan dalam memasukkan perintah suara mengeksekusi aplikasi program pada komputer.

· Supportability, yaitu sejauh mana aktivitas proses dapat didukung oleh suatu tool. Dalam proses pembuatan software, beberapa macam software diperlukan, diantaranya yaitu:

1. Perekaman Suara
Pada proses perekaman suara, digunakan software perekaman suara buatan sendiri yang berbasis pada Snack dan Tcl/tk.

2. Proses Front End
Sinyal yang masuk dari hasil perekaman merupakan sinyal yang masih terhubung dengan noise dan masih memiliki tail baik di awal sinyal maupun akhir sinyal dan merupakan sinyal yang bersifat variant time. Pada proses front end ini, sinyal tail-tail dan sinyal-sinyal noise dipotong dan diambil sinyal murninya saja.

3. Proses Frame Blocking
Pada proses ini dilakukan pemotongan sinyal dalam slot-slot tertentu agar dianggap invariant. Pada proyek akhir ini sinyal suara dipotong sepanjang 20 milidetik di setiap pergeseran 10 milidetik. Setiap potongan tersebut disebut frame. Jadi dalam satu frame terdapat 240 sampel dari 12000 sampel yang ada.

4. Proses Windowing
Setelah proses frame blocking, sinyal diproses windowing untuk mengurangi efek diskontinuitas ketika sinyal ditransformasikan ke domain frekuensi. Proses windowing dilakukan tiap-tiap subband yang terdiri 240 data sample dan digeser setiap setengah subband yaitu 120 sample. Karena adanya pergeseran inilah kemungkinan puncak-puncak yang mestinya terambil menjadi terpotong dapat terjadi.

5. FFT (Fast Fourier Tramsform)
Pada proses ini sinyal yang sebelumnya berada dalam domain waktu akan dirubah dalam domain frekuensi. Setiap sinyal yang berasal dari alam merupakan sinyal analog yang bila diolah harus dirubah dalam bentuk sinyal digital. Dan pengolahan dalam digital merupakan pengolahan dalam bentuk diskrit. Pada proyek akhir ini sinyal dalam domain waktu akan dirubah dalam domain frekuensi dengan 512 titik. Karena hasil yang diperoleh berupa hasil dari fungsi konvolusi maka hanya akan diambil 256 titik saja yang akan diolah dalam proses selanjutnya. Sedangkan 256 sisanya tidak dipergunakan karena berupa pencerminan saja.

6. Liftering
Pengujian selanjutnya setelah proses FFT adalah liftering. Sebelum proses liftering dilakukan hasil dari FFT di invers terlebih dahulu. Hasil dari IFFT (Invers Fast Fourier Transform) diliftering dengan cara memprosesnya kembali dengan Fast Fourier Transform (FFT) yang bertujuan untuk mendapatkan hasil yang sebenarnya. Pada liftering ini data yang diambil adalah 16 data saja tiap framenya yang bisa mewakili semua data yang telah terolah dalam FFT.

7. Cepstrum
Cepstrum pada dasarnya sama dengan FFT, hanya saja hasil dari cepstrum harus melewati beberapa proses, seperti yang telah dijelaskan di atas yaitu dari hasil FFT harus di invers dulu untuk mendapatkan nilai lifternya dan untuk mendapatkan nilai cepstrum maka nilai lifter tersebut harus diproses dengan FFT kembali, hasil dari proses FFT kedua inilah yang disebut sebagai nilai cepstrum.

8. Dynamic Time Warping
Pengujian terakhir dari proses pengolahan sinyal wicara adalah membandingkan sinyal hasil cepstrum antara data input dan data standarnya.

· Acceptability, apakah proses yang telah ditentukan dapat diterima dan mampu bertanggung jawab selama pembuatan produk perangkat lunak hal ini bisa diwujudkan pada tahap pemrosesan sinyal suara untuk mendapatkan ciri atau parameter, sehingga didapatkan algoritma sistem yang lebih baik. Selain itu pengambilan sample yang lebih banyak lagi untuk tiap dependent speaker agar bisa didapatkan hasil yang lebih akurat.

· Reliability, apakah proses didesain sedemikian rupa sehingga kesalahan proses dapat dihindari sebelum terjadi kesalahan pada produk. Seperti yang telah dijelaskan sebelumnya, dalam proses perekaman suara digunakan beberapa macam metoda, hal ini digunakan agar perhitungan yang didapatkan akurat sehingga setiap orang memiliki frekuensi sinyal yang berbeda.

· Robustness, dapatkah proses terus berjalan walaupun terjadi masalah yang tak diduga. Dalam proses perekaman suara, dibutuhkan beberapa sample suara yang digunakan sebagai percobaan. Apabila dalam pelaksanannya orang yang hendak diambil sample suara tersebut sedang sakit, maka diharapkan suara tersebut masih dapat memberikan instruksi pada komputer.

· Maintainability, dapatkah proses berkembang untuk mengikuti kebutuhan atau perbaikan. Untuk saat ini software baru bisa mengenali beberapa macam instruksi, diharapkan pengembangan software dapat mengenali lebih banyak instruksi yang disimpan dalam database.

· Rapidity, bagaimana kecepatan proses pengiriman sistem dapat secara lengkap memenuhi spesifikasi. Diharapkan komputer dapat merespon dengan cepat dalam memproses suara yang diberikan.

2. Aktor
1. Pengguna: kustomer yang hendak menggunakan suara untuk memberikan instruksi pada komputer.
2. Pelanggan : perusahaan yang akan menggunakan software.
3. Analisi Pasar : tim yang bertugas mensurvey kebutuhan pasar
4. Regulasi : manajer yang berhak mengatur kegiatan pembuatan software
5. Rekayasa Software : tim yang berhak mengambil keuntungan dalam pembuatan software, termasuk menggunakan ulang beberapa komponen untuk produk lain.

3. Model Spiral Boehm
Model proses nyata waterfall yang berorientasi dokumen telah diambil sebagai standar umum oleh banyak agen pemerintah dan pembuat perangkat lunak. Jadi, tidak mudah melupakan model tersebut walaupun masih terdapat masalah-masalah yang ditimbulkan dalam model tersebut. Kita membutuhkan sebuah proses yang lebih baik untuk manajemen yang dapat menggunakan semua model umum seperti yang telah kita bicarakan sebelumnya. Model perbaikan tersebut juga harus memenuhi kebutuhan-kebutuhan pembuat perangkat lunak. Pendekatan alternatif diusulkan oleh Boehm (1988). Boehm mengusulkan sebuah model yang secara eksplisit menjelaskan bahwa resiko yang disadari mungkin membentuk dasar model proses umum. Model Boehm berbentuk spiral. Setiap loop mewakili sebuah tahap dari proses perangkat lunak.
Tidak ada tahap yang tetap dalam model ini. Manajemen harus memutuskan bagaimana membentuk proyek kedalam tahap-tahap. Perusahaan biasanya bekerja dengan beberapa model umum dengan tahap tambahan untuk proyek khusus atau ketika masala-masalah ditemukan selama pembuatan proyek.

Setiap loop dibagi dalam 4 sektor
1. Pembuatan tujuan
Tujuan, hambatan dalam proses ataupun produk serta resiko-resiko proyek ditentukan. Rencan rinci manajemen juga ditulis lengkap. Pembuatan strategi-strategi alternatif direncanakan sesuai dengan resiko yang ada.

2. Perkiraan dan pengurangan resiko

Untuk setiap resiko yang telah diidentifikasi, akan dibuat analisis rincinya. Kemudian diambil langkah-langkah untuk mengurangi resiko. contohnya, jika ada resiko bahwa persyaratan-persyaratan tidak tepat maka sebuah model contoh mungkin dapat dikembangkan.

3. Pengembangan dan validasi
Setelah evaluasi resiko, sebuah model pengembangan untuk sistem dipilih. Misalnya, jika resiko interface pengguna yang dominan maka model pengembangan yang tepat mungkin pengembangan evolusioner dengan menggunakan model contoh (prototipe)
Jika resiko keselamatan yang diutamakan, model pengembangan yang sesuai adalah transformasi formal dan seterusnya. Model waterfall mungkin tepat digunakan jika resiko yang diutamakan adalah integrasi sistem.

4. Perencanaan
Jika diputuskan untuk melanjutkan pada loop spiral berikutnya maka proyek dibicarakan kembali dan rencana dibuat untuk tahap selanjutnya. Tidak perlu untuk menggunakan satu model tunggal pada setiap loop spiral bahkan dalam keseluruhan sisten perangkat lunak. Model spiral encompasses model lainnya. Pemodelan digunakan pada salah satu psiral untuk memecahkan masalah kebutuhan. Kemudian dapat diikuti oleh model konvensional, waterfall. Transformasi formal digunakan untuk mengembangkan bagian-bagian sistem yang memiliki persyaratan keselamatan yang tinggi dan pendekatan reuse digunakan untuk pengimplementasian bagian-bagian lain dari sistem data manajemen.Pada implementasinya, model spiral ini juga banyak digunakan, tetapi biasanya dikombinasikan dengan model yang lain. Pemodelan waterfall, yang sangat bagus dalam menentukan millestones dan pemodelan spiral, yang sangat bagus dengan menggunakan prototyping, merupakan kombinasi yang sering dipakai di dalam kontrak-kontrak untuk perangkat lunak dewasa ini.

4 Testing
1. Perekaman Suara Sebagai Sample
Perekaman suara dari 20 orang dengan jenis kelamin yang berbeda yaitu 10 orang wanita dan 10 orang laki-laki dengan kata yang sama. Perekaman tersebut dilakukan secara berulang-ulang dengan kata yang berbeda dari perekaman sebelumnya. Kata-kata yang direkam merupakan feature yang ada pada komputer, dalam hal ini antara lain: Microsoft Word, Excel, Explorer, Power Point, dan Notepad.

2. Pembuatan Database
Pembuatan database dari sinyal-sinyal suara yang telah disimpan sebagai sinyal standart dari software yang akan digunakan yaitu Microsoft Word, Excel, Explorer, Power Point, dan Notepad.

3. Proses Penyesuaian suara (matching voice)
Proses Penyesuaian suara dan pengambilan rata-rata dari masing-masing user pada database sehingga pada saat ada sinyal independent (sinyal baru) yang masuk dapat dicari nilai errornya. Data dengan nilai error terkecil diasumsikan mempunyai tipikal suara yang sama dengan sinyal suara standart dan akan diijinkan untuk melakukan akses pada komputer untuk membuka suatu program aplikasi.

Diambil Dari Tugas Akhir: Yesika Eka Kartikasari – Politeknik Elektronika Negeri Surabaya, DIII Telekomunikasi, 2006

Read More..