Jumat, 31 Agustus 2012

Arash feat Helena – Broken Angel

I’m so lonely broken angel
I’m so lonely listen to my heart
man dooset daram:
I love you
be cheshme man gerye nade:
Don’t bring tears to my eyes
na, nemitoonam:
No, i can’t
bedoone to halam bade:
Without you i’m depressed
I’m so lonely broken angel
I’m so lonely listen to my heart
On n’ lonley, broken angel
Come n’ save me before i fall apart
to harja ke bashi kenaretam:
Wherever you may be, i will be by your side
ta akharesh divoonatam:
till the end, i’ll be crazy about you
to , to nemidooni , ke joonami , bargard pisham :
you , you don’t know , that you are my life , return by my side
la la leyli , la la leyli , la laaa :
it (life) has no purporse (without you)

Jumat, 27 Juli 2012

HUKUM BAGI PENGUMPAT DAN YANG SUKA MENGAIBKAN ORANG

Dari Aisyah RA, katanya: Hindon Binti Ubah, isteri Abu Soyan masuk menemui Rasulullah SAW.lalu bertanya: Ya Rasulallah, sesungguhnya Abu Sofyan adalah lelaki yang sanqat kedekut (bakhil), dia tidak memberi nafkah yang cukup untukku dan untuk anak-anakku, kecuali jika aku ambil saja hartanya (duitnya) tanpa pengetahuannya. Adakah aku berdosa kerana berbuat demikian? Maka jawab baginda Rasul SAW.: Ambillah hartanya (duitnya) itu dengan baik yang boleh mencukupi keperluanmu dan keperluan anak anakmu.
(Hadis Sahih Riwayat Bukhari dan Muslim)
SYARAH AL HADIS:
Para ulama mengambil banyak pengajaran dari Al Hadis diatas antaranya:
Orang yang ingin mendapat fatwa dan orang yang teraniaya dibolehkan untuk menceritakan keburukan tentang orang lain yang ada kaitannya dengan perkara yang diminta fatwa atau penganiayaan itu. Perkara ini tidak termasuk ke dalam bab larangan mengumpat (Al Ghibah). Tetapi hal ini termasuk kedalam salah satu jenis mengumpat yang dikecualikan.
Nafkah isteri adalah tanggungjawab atau kewajiban suami. Adapun kadar nafkah ialah secukupnya. Ini sebagaimana yang diisyaratkan oleh Nabi: Ambillah dengan baik yang dapat mencukupkan keperluanmu dan keperluan anak anakmu.
Kadar kecukupan yang dimaksudkan ialah berdasarkan adat dan keadaan manusia, berbeza-beza kadarnya disebabkan kerana perbezaan masa dan tempat, apakah dia orang yang hidup senangkah atau dia orang yang hidupnya susah.
Jika orang yang wajib mengeluarkan nafkah tersebut enggan memberinya kepada pihak yang berhak menerimanya atau bersifat sangat kedekut, maka orang yang berhak menerimanya atau orang yany mengatur perbelanjaan anak-anaknya itu dibolehkan mengambil harta (duit) orang tersebut walaupun tanpa pengetahuannya. Ini kerana sebabnya nyata dan zahir. Dan ini bukan kes khianat, dan ini tidak termasuk kedalam larangan Nabi saw. : ” Jangan kamu khianat kepada orang yang mengkhianati kamu “.
Nafkah anak adalah kewajiban dan tanggungjawab ayahnya. Bukan tanggungjawab ibu dan bukan pula tanggungjawab orang-orang lain seperti datuknya, pamannya dan lain-lain.
Bahawa orang yang diserahkan tanggungjawab mengatur sesuatu urusan perbelanjaan dan kewangan, dapat diterima ketentuannya tentang jumlah kadar yang diperlukan ini kerana dia adalah orang yang memikul amanah, dan dia memiliki kuasa dalam hal itu.
Bahawa orang yang meminta sesuatu fatwa yang ada kaitannya dengan orang lain, jika orang yany ditanya (mufti) dapat menerima kebenaran perkara yang diajukan itu maka tidak perlulah dimaklumkan perkara tersebut kepada orang lain itu. Lebih lebih lagi jika perkara tersebut dapat mendatangkan mudarat (bahaya) sebagaimana persoalan yang terkandung dalam Al Hadis diatas. Barangkali akan rusak rumahtangga Hindon jika aduan itu dimaklumkan kepada Abu Sofyan.
JENIS-JENIS MENGUMPAT YANG DIBOLEHKAN :
Sebagaiamana kita sama maklum bahawa hukum mengumpat adalah haram. Mengumpat ialah menceritakan tentang aib atau keburukan seseorang yang apabila orang tersebut mendengarnya maka ia akan marah dan benci.
Dalam hal ini Imam An Nawawy dalam kitabnya Riyadhus Salihin berkata: Ketahuilah bahawa mengumpat adalah dibolehkan atas sebab-sebab tertentu dan mengikuti lunas-lunas syara’ (agama), jika sesuatu yang penting tidak mungkin tercapai kecuali dengannya. Mengumpat yang diperbolehkan-oleh agama itu ada enam jenis:
(1) KES PENGANIAYAAN.
Dibolehkan kepada orang yang dianiaya untuk mengadu kepada pihak berkuasa seperti Sultan, Qadhi atau lain-lain pihak yang mempunyai kuasa untuk memberi keinsafan dan kesedaran kepada orang yang menganiaya itu. Umpamanya: Si Polan itu telah menganiaya saya begini dan begitu.
(2) MOHON BANTUAN MENCEGAH KEMUNGKARAN.
Umpamanya seseorang berkata kepada pihak polis atau bahagian pencegah maksiat: Si Polan itu telah berbuat perkara sumbang, tolong tuan cegah perkara tersebut. Maksud orang itu ialah menjadikan pihak berkuasa sebagai orang tengah untuk mencegah kemungkaran. Tetapi jika tidak dengan maksud itu maka hukumnya adalah haram.
(3) MINTA FATWA.
Umpamanya ia berkata kepada mufti atau orang yang dipercayai boleh memberi fatwa: Ayah saya atau saudara saya atau suami saya telah menganiaya saya, adakah dia boleh berbuat demikian terhadap saya, bagaimana cara supaya saya dapat terhindar dari penganiayaannya. Perkara ini dibolehkan kerana hajat. Tetapi adalah lebih baik sekiranya dengan cara sindiran sudah tercapai tujuannya. Namun demikian menyebut nama orang yang menzalimi adalah dibolehkan sebagaimana dalam kisah Hindon diatas.
(4) MENGAJAK MUSLIMIN AGAR BERSIKAP BERHATI-HATI.
Umpamanya: Kita menyebut tentang keaiban periwayat hadis seperti si polan pendusta, tidak amanah, kurang kuat ingatannya dan lain-lain. Perkara ini dibolehkan kerana tujuan kita berbuat demikian semata mata ingin menjaga keaslian hadis Rasulullah saw. Sebab tanpa berbuat demikian maka akan terdedahlah hadis Rasul saw dengan pemalsuan. Atau paling kurang supaya orang ramai jangan sampai menyangka hadis hadis tersebut sebagai hadis yang sahih. Apalagi jika orang berkenaan sememangnya orang yang suka memalsukan hadis. Dan menyatakan keaiban orang lain ini juga boleh jika kita diminta pandangan tentang peribadi seseorang yang akan menjadi rakan kongsi perniagaan , atau menitipkan amanah , atau urusan perkahwinan , demikian juga tentang berjiran dan sebagai.
(5) JIKA MELAKUKAN MAKSIAT DAN BID’AH SECARA TERANG.
Umpamanya: Minum arak secara terang terangan atau seorang guru agama yang mengajar ajaran-ajaran sesat seperti syirik dan bid’ah atau bomoh dan dukun yang menggunakan amalan amalan syirik. Kita diperbolehkan menyebut keburukan atau keaiban orang orang berkenaan supaya muslimin yang lain dapat sentiasa waspada dan tidak terpedaya oleh mereka. Tetapi dalam hal ini kita tidak boleh menceritakan cela mereka yang lain kecuali ada sebab-sebab lain yang membolehkannya sebagaimana tersebut diatas.
(6) SEBAGAI TANDA PENGENALAN.
Andaikata seseorang dikenal dengan gelaran tertentu. Umpamanya: Mamat Pincang, Jali Sumbing, Enon Gendut dan lain-lain maka dibolehkan kita menyebut sifat-sifat tersebut tetapi dengan syarat tidak dengan nada atau tujuan menghina dan merendah rendahkan. Andaikata orang tersebut sudah dapat dikenal tanpa menggunakan gelaran-gelaran diatas maka itu adalah lebih baik.
—————————–
Satu Lahi Hadis dan kupasan..
Di dalam kitabnya yang berjudul ‘Nuzhatul Muttaqin’ syarah kepada kitab hadis yang masyhur ‘Riyadhus Sholihin’ mengenai siapa yang diharuskan mengumpat, pada asalnya mengumpat adalah haram akan tetapi diharuskan dalam keadaan keadaan tertentu. Dinyatakan oleh beliau diharuskan kepada enam golongan iaitu:
1. Mengadu kezaliman: Diharuskan kepada orang yang dizalimi mengadu kezaliman kepada qadi atau seumpamanya iaitu orang yang mempunyai kekuatan untuk menangani kes tersebut. Contohnya mengadu kepada hakim bahawa dia telah dizalimi oleh polan bin polan.
2. Meminta pertolongan untuk mencegah kemungkaran: Mengadu kepada orang yang mampu untuk mencegah kemungkaran tersebut.contohnya mengadu kepada bapa atau keluarga pelaku maksiat agar keluarganya dapat menasihati serta mencecahnya dari terus melakukannya.
3. Meminta fatwa: Diharuskan bagi orang yang ingin menanyakan fatwa mnceritakan apa yang berlaku bagi membolehkan mufti mengeluarkan hukum yang bertepatan dengan apa yang dikehendakinya.
4. Memberi peringatan kepada Muslimin serta menasihati mereka.
5. Orang yang terang terang melakukan maksiat: Dibolehkan mengumpat ke atas mereka ini bagi menyedarkan kesalahan mereka. Sebagai contoh mereka berjudi atau minum arak di jalanan, dibolehkan mengumpat atau mengata mengenai hal mereka.
6. Pengenalan kepada seseorang insan yang mana tidak dikenali orang tersebut kecuali dengan gelaran: Contohnya polan bin polan tidak dikenali di tempat asalnya kecuali dengan gelaran tertentu, maka dibolehkan.
Disediakan oleh:
Ust Muhamad Farhan bin Ismail
Jabatan Feqh Wa Usul
Universiti Mu’tah
Jordan.

Sumber : http://taraknamav2.wordpress.com/2007/08/11/hukum-mengumpat-dan-mengaibkan-orang/

PENGERTIAN PUASA

Pengertian Puasa menurut bahasa adalah menahan diri dari sesuatu. misalnya seseorangdari berbicara maka ia tidak baerbicara dan apabila seseorang menahan makan berarti iatidak makan. ALLAH SWT berfirman dalam Surat Maryam : 26
“ maka makan, minum dan bersenang hatilah kamu. Jika kamu melihat seorang manusia,maka katakanlah: "Sesungguhnya aku telah bernazar berpuasa untuk Tuhan Yang MahaPemurah, maka aku tidak akan berbicara dengan seorang manusiapun pada hari ini."adapun pengertian puasa menurut istilah syariat Islam adalah menahan diri dari makan danminum serta sesuatu yang membatalkan selama satu hari penuh mulai dari terbit fajar hingga terbenamnya Matahari dengan beberapa syarat tertentu.ALLOH SWT berfirman dalam Surat Al- Baqarah : 187

Dihalalkan bagi kamu pada malam hari bulan puasa bercampur dengan isteri-isteri kamu;mereka adalah pakaian bagimu, dan kamupun adalah pakaian bagi mereka. Allahmengetahui bahwasanya kamu tidak dapat menahan nafsumu, karena itu Allahmengampuni kamu dan memberi ma'af kepadamu. Maka sekarang campurilah mereka danikutilah apa yang telah ditetapkan Allah untukmu, dan makan minumlah hingga terang bagimu benang putih dari benang hitam, yaitu fajar. Kemudian sempurnakanlah puasa itusampai (datang) malam, (tetapi) janganlah kamu campuri mereka itu, sedang kamu beri'tikaf dalam mesjid. Itulah larangan Allah, maka janganlah kamu mendekatinya.Demikianlah Allah menerangkan ayat-ayat-Nya kepada manusia, supaya mereka bertakwa.Perintah berpuasa tidak hanya di wajibkan kepada umat Nabi Muhammad SAW terhadapumat terdahulupun sudah di wajibkan sebagaimana diterangkan dalam firman ALLOHSWT dalam Surat Al-Baqarah : 183

Hai orang-orang yang beriman,diwajibkan atas kamu berpuasa sebagaimana diwajibkan atas orang-orang sebelum kamu   agar kamu bertakwa, (Qs Al-Baqarah : 183).

Sumber : http://www.scribd.com/doc/40550940/Puasa 

Senin, 28 Mei 2012

Software Pengujian Perangkat Lunak

Software pengujian merupakan investigasi dilakukan untuk memberikan stakeholder dengan informasi tentang kualitas produk atau jasa sedang diuji. Software pengujian juga menyediakan independen, objektif perangkat lunak untuk memungkinkan bisnis untuk menghargai dan memahami risiko pada pelaksanaan perangkat lunak. teknik uji meliputi, tetapi tidak terbatas, proses eksekusi sebuah program atau aplikasi dengan tujuan menemukan bug perangkat lunak .
Software pengujian juga dapat dinyatakan sebagai proses untuk memvalidasi dan memverifikasi bahwa program software / aplikasi / produk:
1. memenuhi persyaratan bisnis dan teknis bahwa desain yang dibimbing dan pengembangan;
2. bekerja seperti yang diharapkan, dan
3. dapat diimplementasikan dengan karakteristik yang sama.

Software pengujian, tergantung pada metode pengujian yang digunakan, dapat diterapkan pada setiap saat dalam proses pembangunan. Namun, sebagian besar upaya uji terjadi setelah persyaratan yang telah dibuat dan proses pengkodean telah selesai. Dengan demikian, metodologi tes diatur oleh metodologi pengembangan perangkat lunak diadopsi.
model pengembangan perangkat lunak yang berbeda-beda akan memfokuskan upaya uji pada titik-titik yang berbeda dalam proses pembangunan. model-model pembangunan yang lebih baru, seperti Agile , sering menggunakan didorong pengembangan tes dan menempatkan porsi peningkatan pengujian di tangan pengembang, sebelum mencapai sebuah tim penguji formal. Dalam model yang lebih tradisional, sebagian besar terjadi setelah pelaksanaan tes persyaratan yang telah dibuat dan proses pengkodean telah selesai.
Sejarah
Pemisahan debugging dari pengujian pada awalnya diperkenalkan oleh Glenford J. Myers pada tahun 1979. Meskipun perhatiannya adalah pada pengujian kerusakan (“tes yang sukses adalah salah satu yang menemukan bug”) itu diilustrasikan keinginan komunitas rekayasa perangkat lunak untuk memisahkan kegiatan pembangunan mendasar, seperti debug, dari verifikasi. Dave Gelperin dan William C. Hetzel diklasifikasikan pada tahun 1988 tahapan dan tujuan dalam pengujian perangkat lunak dalam tahap berikut:
* Sampai 1956 – Debugging berorientasi
*1957-1978 – Peragaan berorientasi
*1979-1982 – Pemusnahan berorientasi
*1983-1987 – Evaluasi berorientasi
* 1988-2000 – Pencegahan berorientasi
Software Pengujian Topik
Ruang Lingkup
Tujuan utama pengujian adalah untuk mendeteksi kegagalan perangkat lunak sehingga cacat dapat ditemukan dan diperbaiki. Pengujian tidak dapat menetapkan bahwa fungsi produk dengan benar dalam semua kondisi namun hanya dapat menetapkan bahwa hal itu tidak berfungsi sebagaimana mestinya dalam kondisi tertentu. Ruang lingkup pengujian perangkat lunak sering kali berisi pemeriksaan kode serta pelaksanaan kode dalam berbagai lingkungan dan kondisi serta memeriksa aspek kode: melakukannya melakukan apa yang seharusnya dilakukan dan melakukan apa yang perlu dilakukan. Dalam budaya saat ini pengembangan perangkat lunak, sebuah organisasi pengujian mungkin terpisah dari tim pengembangan. Ada berbagai peran untuk menguji anggota tim. Informasi yang diperoleh dari pengujian perangkat lunak yang dapat digunakan untuk memperbaiki proses dimana perangkat lunak dikembangkan.
Fungsional vs non-fungsional pengujian
pengujian Fungsional mengacu pada tes yang memverifikasi tindakan spesifik atau fungsi dari kode. Ini biasanya ditemukan dalam dokumentasi kode persyaratan, meskipun beberapa metodologi pengembangan kerja dari kasus penggunaan atau cerita-cerita pengguna. tes Fungsional cenderung menjawab pertanyaan “bisa pengguna melakukan ini” atau “apakah ini bekerja fitur tertentu”.
Pengujian non-fungsional mengacu pada aspek perangkat lunak yang mungkin tidak terkait dengan fungsi tertentu atau tindakan pengguna, seperti skalabilitas atau keamanan . pengujian non-fungsional cenderung untuk menjawab pertanyaan seperti “berapa banyak orang bisa login sekaligus”, atau “bagaimana mudah adalah untuk hack software ini”.
Cacat dan Kegagalan
Tidak semua cacat software disebabkan oleh kesalahan coding Salah satu sumber umum dari cacat mahal disebabkan oleh kesenjangan kebutuhan, misalnya, persyaratan yang belum diakui, yang mengakibatkan kesalahan dari kelalaian oleh perancang program. Sebuah sumber umum persyaratan kesenjangan adalah persyaratan non-fungsional seperti testability , skalabilitas , rawatan , kegunaan , kinerja , dan keamanan .
Software kesalahan terjadi melalui proses berikut. Seorang pemrogram membuat kesalahan (kesalahan), yang menghasilkan cacat (salah, bug) dalam perangkat lunak kode sumber . Jika cacat ini dijalankan, dalam situasi tertentu sistem akan menghasilkan hasil yang salah, menyebabkan kegagalan . Tidak semua cacat tentu akan menghasilkan kegagalan. Misalnya, cacat kode mati tidak akan mengakibatkan kegagalan. cacat A dapat berubah menjadi kegagalan ketika lingkungan berubah. Contoh dari perubahan lingkungan termasuk perangkat lunak yang berjalan di sebuah baru hardware platform, perubahan dalam sumber data atau berinteraksi dengan perangkat lunak yang berbeda.Sebuah cacat tunggal dapat mengakibatkan berbagai gejala kegagalan.
Kesalahan Pencarian Awal
Hal ini umumnya percaya bahwa cacat sebelumnya ditemukan lebih murah itu adalah untuk memperbaikinya. Tabel berikut menunjukkan biaya memperbaiki cacat tergantung di atas panggung itu ditemukan. Sebagai contoh, jika masalah di persyaratan hanya ditemukan pasca-release, maka akan biaya 1-10 kali lebih untuk memperbaiki daripada jika itu sudah ditemukan oleh review persyaratan.
Kompatibilitas
Penyebab umum kegagalan perangkat lunak (nyata atau dianggap) adalah kurangnya kompatibilitas dengan lain perangkat lunak aplikasi , sistem operasi (atau sistem operasi versi , lama atau baru), atau lingkungan target yang berbeda jauh dari aslinya (seperti terminal atau GUI aplikasi ditujukan untuk berjalan di desktop sekarang sedang dibutuhkan untuk menjadi aplikasi web , yang harus membuat dalam browser web ). Misalnya, dalam kasus kurangnya kompatibilitas ke belakang , ini dapat terjadi karena programmer mengembangkan dan menguji perangkat lunak hanya pada versi terbaru dari lingkungan target, yang tidak semua pengguna dapat berjalan. Hal ini menghasilkan konsekuensi yang tidak diinginkan bahwa pekerjaan terbaru mungkin tidak berfungsi pada versi sebelumnya dari lingkungan target, atau pada perangkat keras lama bahwa versi sebelumnya dari lingkungan target mampu menggunakan. Kadang-kadang isu-isu tersebut dapat diperbaiki dengan proaktif abstrak fungsi sistem operasi ke dalam program yang terpisah modul atau perpustakaan .
Input kombinasi dan Prasyarat
Sebuah masalah yang sangat mendasar dengan pengujian perangkat lunak adalah bahwa pengujian di bawah semua kombinasi input dan prasyarat (keadaan awal) tidak layak, bahkan dengan produk yang sederhana. Ini berarti bahwa jumlah cacat pada produk perangkat lunak dapat sangat besar dan cacat yang jarang terjadi sulit ditemukan dalam pengujian. Lebih penting lagi, fungsional non- dimensi kualitas (bagaimana seharusnya versus apa yang seharusnya dilakukan) – kegunaan , skalabilitas , kinerja , kompatibilitas , reliabilitas -bisa sangat subjektif, sesuatu yang merupakan nilai yang cukup untuk satu orang mungkin tak tertahankan lain.
Pengujian Statis VS Dinamis
Ada banyak pendekatan untuk pengujian perangkat lunak. Ulasan , penelusuran , atau inspeksi dianggap sebagai pengujian statis , sedangkan benar-benar melaksanakan kode diprogram dengan himpunan uji kasus disebut sebagai pengujian dinamis . Pengujian statis dapat (dan sayangnya dalam praktek sering) diabaikan. pengujian dinamis terjadi ketika program itu sendiri digunakan untuk kali pertama (yang umumnya dianggap sebagai awal tahap pengujian). pengujian dinamis dapat dimulai sebelum program 100% selesai untuk menguji bagian tertentu dari kode (modul atau diskrit fungsi ). Khas teknik untuk hal ini adalah baik menggunakan Rintisan bertopik / driver atau eksekusi dari sebuah debugger lingkungan. Sebagai contoh, spreadsheet program ini, dengan sifatnya, diuji untuk sebagian besar interaktif (” on the fly “), dengan hasil yang ditampilkan segera setelah setiap perhitungan atau manipulasi teks.
Perangkat Lunak Verifikasi dan Validasi
Software pengujian yang digunakan dalam hubungan dengan verifikasi dan validasi :
* Apakah kita membangun perangkat lunak yang tepat? (Yaitu, bukan sesuai spesifikasi).
* Validasi: Apakah kita membangun perangkat lunak yang tepat? (Yakni, apakah ini yang diinginkan oleh pelanggan).
Istilah verifikasi dan validasi yang umum digunakan bergantian dalam industri, melainkan juga umum untuk melihat kedua istilah ini tidak benar didefinisikan. Menurut Standar IEEE Istilah Istilah Rekayasa Perangkat Lunak:
Verifikasi adalah proses mengevaluasi suatu sistem atau komponen untuk menentukan apakah produk dari tahap pengembangan yang diberikan memenuhi kondisi yang dikenakan pada awal fase itu.
Validasi adalah proses mengevaluasi suatu sistem atau komponen selama atau pada akhir proses pembangunan untuk menentukan apakah memenuhi persyaratan yang ditentukan.
Tim Pengujian perangkat lunak
Software pengujian dapat dilakukan oleh perangkat lunak penguji . Sampai tahun 1980-an istilah “software tester” digunakan secara umum, tetapi kemudian juga dilihat sebagai profesi yang terpisah. Mengenai periode dan tujuan yang berbeda dalam pengujian perangkat lunak, peran yang berbeda telah ditetapkan: manajer, memimpin, uji desainer, tester, pengembang otomasi, dan pengawas tes.
Software Quality Assurance (SQA)
Meskipun kontroversial, pengujian perangkat lunak dapat dilihat sebagai bagian penting dari jaminan kualitas perangkat lunak (SQA) proses. Dalam SQA, spesialis proses software dan auditor mengambil pandangan yang lebih luas pada perangkat lunak dan pengembangannya. Mereka memeriksa dan mengubah proses rekayasa perangkat lunak itu sendiri untuk mengurangi jumlah kesalahan yang berakhir di perangkat lunak yang dikirimkan: cacat yang disebut tingkat-begitu.
Apa yang merupakan tingkat kecacatan “diterima” tergantung pada sifat dari perangkat lunak. Sebagai contoh, sebuah video game arcade dirancang untuk mensimulasikan pesawat terbang mungkin akan memiliki toleransi lebih tinggi banyak cacat daripada misi kritis perangkat lunak seperti yang digunakan untuk mengontrol fungsi sebuah pesawat itu benar-benar terbang!
Meskipun ada hubungan yang erat dengan SQA, pengujian departemen sering ada secara independen, dan mungkin tidak ada fungsi SQA di beberapa perusahaan.
Software pengujian adalah tugas dimaksudkan untuk mendeteksi cacat pada piranti lunak oleh kontras hasil program komputer yang diharapkan dengan hasil aktual untuk satu set input. Sebaliknya, QA (jaminan mutu) adalah implementasi kebijakan dan prosedur yang dimaksudkan untuk mencegah kerusakan dari yang terjadi di tempat pertama. 


Sumber : http://bagusalfiyanto.blogspot.com/2010/06/software-pengujian-perangkat-lunak.html

Kamis, 03 Mei 2012

Armada - Hargai Aku

Sering kali kau merendahkanku
Melihat dengan sebelah matamu
Aku bukan siapa-siapa

Selalu saja kau anggap ku lemah
Merasa hebat dengan yang kau punya
Kau sombongkan itu semua

Coba kau lihat dirimu dahulu
Sebelum kau nilai kurangnya diriku
Apa salahnya hargai diriku
Sebelum kau nilai siapa diriku

Sering kali kau merendahkanku
Melihat dengan sebelah matamu
Aku bukan siapa-siapa

Coba kau lihat dirimu dahulu
Sebelum kau nilai kurangnya diriku
Apa salahnya hargai diriku
Sebelum kau nilai siapa diriku

Coba kau lihat dirimu dahulu
Sebelum kau nilai kurangnya diriku
Apa salahnya hargai diriku
Sebelum kau nilai siapa diriku
Sebelum kau nilai siapa diriku

Jumat, 13 April 2012

Kriteria Manager Proyek yang baik

Yang dimaksud dengan manager adalah orang atau seseorang yang harus mampu membuat orang-orang dalam organisasi yang berbagai karakteristik, latar belakang budaya, akan tetapi memiliki ciri yang sesuai dengan tujuan (goals) dan teknologi (technology).

Dan tugas seorang manager adalah bagaimana mengintegrasikan berbagai macam variabel (karakteristik, budaya, pendidikan dan lain sebagainya) kedalam suatu tujuan organisasi yang sama dengan cara melakukan mekanisme penyesuaian.
Adapun mekanisme yang diperlukan untuk menyatukan variabel diatas adalah sebagai berikut:

  • Pengarahan (direction) yang mencakup pembuatan keputusan, kebijaksanaan, supervisi, dan lain-lain.
  • Rancangan organisasi dan pekerjaan.
  • Seleksi, pelatihan, penilaian, dan pengembangan.
  • Sistem komunikasi dan pengendalian.
  • Sistem reward.

Hal tersebut memang tidak mengherankan karena posisi Manajer Proyek memegang peranan kritis dalam keberhasilan sebuah proyek terutama di bidang teknologi informasi. Berikut ini kualifikasi teknis maupun nonteknis yang harus dipenuhi seorang Manajer Proyek yang saya sarikan dari IT Project Management Handbook.

Setidaknya ada 3 (tiga) karakteristik yang dapat digunakan untuk mengukur tingkat kualifikasi seseorang untuk menjadi Manajer Proyek yaitu:

  • Karakter Pribadinya
  • Karakteristik Kemampuan Terkait dengan Proyek yang Dikelola
  • Karakteristik Kemampuan Terkait dengan Tim yang Dipimpin

Karakter Pribadinya

  1. Memiliki pemahaman yang menyeluruh mengenai teknis pekerjaan dari proyek yang dikelola olehnya.
  2. Mampu bertindak sebagai seorang pengambil keputusan yang handal dan bertanggung jawab.
  3. Memiliki integritas diri yang baik namun tetap mampu menghadirkan suasana yang mendukung di lingkungan tempat dia bekerja.
  4. Asertif
  5. Memiliki pengalaman dan keahlian yang memadai dalam mengelola waktu dan manusia.

Karakteristik Kemampuan Terkait dengan Proyek yang Dikelola

  1. Memiliki komitmen yang kuat dalam meraih tujuan dan keberhasilan proyek dalam jadwal, anggaran dan prosedur yang dibuat.
  2. Pelaksanakan seluruh proses pengembangan proyek IT sesuai dengan anggaran dan waktu yang dapat memuaskan para pengguna/klien.
  3. Pernah terlibat dalam proyek yang sejenis.
  4. Mampu mengendalikan hasil-hasil proyek dengan melakukan pengukuran dan evaluasi kinerja yang disesuaikan dengan standar dan tujuan yang ingin dicapai dari proyek yang dilaksanakan.
  5. Membuat dan melakukan rencana darurat untuk mengantisipasi hal-hal maupun masalah tak terduga.
  6. Membuat dan menerapkan keputusan terkait dengan perencanaan.
  7. Memiliki kemauan untuk mendefinisikan ulang tujuan, tanggung jawab dan jadwal selama hal tersebut ditujukan untuk mengembalikan arah tujuan dari pelaksanaan proyek jika terjadi jadwal maupun anggaran yang meleset.
  8. Membangun dan menyesuaikan kegiatan dengan prioritas yang ada serta tenggat waktu yang ditentukan sebelumnya.
  9. Memiliki kematangan yang tinggi dalam perencanaan yang baik dalam upaya mengurangi tekanan dan stres sehingga dapat meningkatkan produktifitas kerja tim.
  10. Mampu membuat perencanaan dalam jangka panjang dan jangka pendek.

Karakteristik Kemampuan Terkait dengan Tim yang Dipimpin

  1. Memiliki kemampuan dan keahlian berkomunikasi serta manajerial.
  2. Mampu menyusun rencana, mengorganisasi, memimpin, memotivasi serta mendelegasikan tugas secara bertanggung jawab kepada setiap anggota tim.
  3. Menghormati para anggota tim kerjanya serta mendapat kepercayaan dan penghormatan dari mereka.
  4. Berbagi sukses dengan seluruh anggota tim.
  5. Mampu menempatkan orang yang tepat di posisi yang sesuai.
  6. Memberikan apresiasi yang baik kepada para anggota tim yang bekerja dengan baik.
  7. Mampu mempengaruhi pihak-pihak lain yang terkait dengan proyek yang dipimpinnya untuk menerima pendapat-pendapatnya serta melaksanakan rencana-rencana yang disusunnya.
  8. Mendelegasikan tugas-tugas namun tetap melakukan pengendalian melekat.
  9. Memiliki kepercayaan yang tinggi kepada para profesional terlatih untuk menerima pekerjaan-pekerjaan yang didelegasikan darinya.
  10. Menjadikan dirinya sebagai bagian yang terintegrasi dengan tim yang dipimpinnya.
  11. Mampu membangun kedisiplinan secara struktural.
  12. Mampu mengidentifikasi kelebihan-kelebihan dari masing-masing anggota tim serta memanfaatkannya sebagai kekuatan individual.
  13. Mendayagunakan setiap elemen pekerjaan untuk menstimulasi rasa hormat dari para personil yang terlibat dan mengembangkan sisi profesionalisme mereka.
  14. Menyediakan sedikit waktu untuk menerima setiap ide yang dapat meningkatkan kematangan serta pengembangan dirinya.
  15. Selalu terbuka atas hal-hal yang mendorong kemajuan.
  16. Memahami secara menyeluruh para anggota tim yang dipimpinnya dan mengembangkan komunikasi efektif di dalamnya.
Kriteria Manajer Proyek Yang Efektif

Tidak ada yang sempurna, kata ini memang menunjukkan sebuah realitas. Bagaimanapun tuntutan kesempurnaan kerja seorang manajer proyek yang efektif tidak dapat seratus persen terwujud. Akan tetapi ada beberapa criteria dan usaha pendekatan ke arah sana. Grey&Larson (2006) mendeskripsikan beberapa indicator, ciri dan kualitas seorang manajer proyek yang efektif. Beberapa kontradiksi yang dihadapkan oleh manajer proyek antara lain:
• Inovasi dan menjaga stabilitas.
• Menetapkan gambaran dan terlibat langsung di lapangan.
• Mendorong individu tetapi juga menekan tim.
• Campur tangan atau tidak.
• Fleksibel tapi ketat.
• Loyalitas tim dan loyalitas organisasi.
Kontradiksi ini memerlukan kecakapan khusus bagi manajer proyek untuk mengambil posisi mereka dan menempatkan keputusan sesuai dengan keadaan. Terpaku pada suatu prinsip yang ketat tidak akan menyelesaikan masalah, karena manajer proyek tidak bekerja sendiri. Dalam buku yang sama Grey&Larson (2006) juga menggambarkan ciri-ciri dari seorang manajer proyek yang efektif. Diantaranya adalah:
1. Pemikir Sistem, kemampuan dalam berpikir untuk mengelola interaksi antar komponen dan sumber daya proyek yang berbeda-beda, karena tidak bisa dikatakan efektif apabila penyelesaian masalah hanya secara parsial. Hal ini akan mempersulit sang manajer untuk mengambil keputusan.
2. Integritas Pribadi, membangun dan meningkatkan kemampuan diri menjadi sangat penting dilakukan terlebih dahulu sebelum meningkatkan kemampuan anggota tim.
3. Proaktif, bedakan dengan reaktif. Para manajer proyek dituntut tidak hanya akan melihat peristiwa yang telah terjadi (reaktif), akan tetapi juga selalu meneropong masa depan dan berjuang keras menemukan masa depan proyek (Kartajaya, 2003)
4. Toleransi yang tinggi terhadap Stress, mengingat proyek merupakan hal yang rumit dan kompleks, pasti akan menimbulkan tekanan terhadap orang yang bebankan tanggungjawab kepadanya. Manajer proyek harus mampu mengelola kondisi psikologis mereka agar dapat bertahan dalam tekanan.
5. Perspektif Bisnis Umum, seorang manajer proyek harus memahami dasar-dasar bisnis dari disiplin teknis yang berbeda-beda sebagai kerja antar fungsional.
6. Politikus Mahir, strategi dalam menghadapi banyak orang dan mendapatkan dukungan dari semua pihak merupakan cirri penting manajer proyek yang sukses.
7. Optimis, Slater (1999) dalam bukunya Saving Big Blue mengatakan “Anda dalam kesulitan Besar jika Menganggap anda Sudah Selesai”. Maksud dari kata-kata ini ialah, masalah-masalah yang sudah diselesaikan tidak bisa kita lepas begitu saja, karena pada nantinya kan bermunculan masalah-masalah baru di dalam pelaksanaan proyek. Kepercayaan diri terhadap proyek, mampu membuat seorang manajer proyek melakukan inovasi dan mengubah strategi proyek ke arah yang lebih baik tanpa meninggalkan perencanaan yang telah ditetapkan.


sumber :
http://freezcha.wordpress.com/2011/05/
http://cheeoche.blogspot.com/2012/04/kriteria-manager-proyek-yang-baik.html
http://saiiamilla.wordpress.com/2011/05/13/kriteria-manager-proyek-yang-baik/

COCOMO (Constructive Cost Model)

Apa itu COCOMO ?? masih cukup asing kita mendengar istilah COCOMO. COCOMO adalah singkatan dari Constructive Cost Model yang merupakan sebuah kombinasi dari estimasi parameter persamaan dan metode pembobotan. Untuk lebih mengenal lagi tetang COCOMO mari kita lihat artikel berikut .

Sejarah COCOMO

COCOMO pertama kali diterbitkan pada tahun 1981 Barry Boehm W.'s Book ekonomi Software engineering sebagai model untuk memperkirakan usaha, biaya, dan jadwal untuk proyek-proyek perangkat lunak. Ini menarik pada studi dari 63 proyek di TRW Aerospace mana Barry Boehm adalah Direktur Riset dan Teknologi Perangkat Lunak pada tahun 1981. Penelitian ini memeriksa proyek-proyek ukuran mulai dari 2.000 sampai 100.000 baris kode, dan bahasa pemrograman mulai dari perakitan untuk PL / I. Proyek-proyek ini didasarkan pada model pengembangan perangkat lunak waterfall yang merupakan proses software umum pembangunan di 1981.

Pengertian COCOMO

Tidak seperti model estimasi biaya yang lain, COCOMO adalah model terbuka, sehingga semua detail dipublikasikan, termasuk :
  • Dasar persamaan perkiraan biaya
  • Setiap asumsi yang dibuat dalam model
  • Setiap definisi
  • Biaya yang disertakan dalam perkiraan dinyatakan secara eksplisit
Perhitungan paling fundamental dalam COCOMO model adalah penggunaan Effort Equation (Persamaan Usaha) untuk mengestimasi jumlah dari Person-Months yang dibutuhkan untuk pengembangan proyek.

COCOMO terdiri dari tiga bentuk hirarki semakin rinci dan akurat. Tingkat pertama, Basic COCOMO adalah baik untuk cepat, order awal, kasar estimasi besarnya biaya perangkat lunak, namun akurasinya terbatas karena kurangnya faktor untuk memperhitungkan perbedaan atribut proyek (Cost Drivers). Intermediate COCOMO mengambil Driver Biaya ini diperhitungkan dan Rincian tambahan COCOMO account untuk pengaruh fase proyek individu.


SOURCE LINE OF CODE
  • Perhitungan COCOMO didasarkan pada estimasi anda pada ukuran proyek dalam Source Line Of Code (SLOC). Pendefinisian SLOC:
  • Hanya jumlah baris kode yang dikirim sebagai bagian dari produk yang disertakan (test drivers dan software pendukung lainnya tidak dihitung).
  • Baris kode dibuat oleh staf proyek (kode yang di-generate oleh aplikasi tidak dihitung).
  • Satu SLOC adalah satu baris kode secara logis.
  • Deklarasi dihitung sebagai SLOC.
  • Komentar tidak dihitung sebagai SLOC.
Model COCOMO 81 didefinisikan dalam bentuk Delivered Source Instruction, yang mana sangat menyerupai SLOC. Perbedaan utama antara DSI dan SLOC adalah sebuah SLOC mungkin merupakan beberapa baris secara fisik. Sebagai contoh, sebuah statement “if-then-else” akan dihitung sebagai satu SLOC, tetapi mungkin dihitung sebagai beberapa DSI.

SCALE DRIVERS

Pada model COCOMO II, beberapa factor terpenting yang berkontribusi pada durasi proyek dan biaya yang dikeluarkan adalah Scale Drivers. Anda mengeset setiap Scale Driver untuk mendeskripsikan proyek anda. Scale Drivers tersebut menentukan eksponen yang digunakan dalam Effort Equation.
Ada 5 Scale Drivers :
  • Precedentedness
  • Development Flexibility
  • Architecture / Risk Resolution
  • Team Cohesion
  • Process Maturity
Catat bahwa Scale Drivers telah menggantikan Development Mode dari COCOMO 81. Dua Scale Drivers yang pertama, Precedentedness dan Development Flexibility sebenamya mendeskripsikan pengaruh yang hampir sama dibanding Development Mode.

COST DRIVERS

COCOMO II memiliki 17 cost drivers. Cost driver tersebut adalah factor pengali yang menentukan usaha yang diperlukan untuk menyelesaikan proyek software anda. Sebagai contoh, jika proyek anda akan mengembangkan software yang mengatur penerbangan pesawat, anda akan mengeset Required Software Reliability (RELY) cost driver menjadi sangat tinggi. Rating tersebut berhubungan dengan effort multiplier 1,26 yang berarti bahwa proyek anda akan membutuhkan usaha lebih sebesar 26% dibanding proyek software pada umumnya. COCOMO II mendefinisikan setiap cost drivers dan effort multiplier yang terhubung dengan setiap rating.

Model COCOMO


Model COCOMO terdiri dari 3 model yaitu :

1. Dasar Cocomo

Dengan menggunakan estimasi parameter persamaan (dibedakan menurut tipe sistem yang berbeda) upaya pengembangan dan pembangunan durasi dihitung berdasarkan perkiraan DSI.

Dengan rincian untuk fase ini diwujudkan dalam persentase. Dalam hubungan ini dibedakan menurut tipe sistem (organik-batch, sebagian bersambung-on-line, embedded-real-time) dan ukuran proyek (kecil, menengah, sedang, besar, sangat besar).

Model COCOMO dapat diaplikasikan dalam tiga tingkatan kelas:
  • Proyek organik (organic mode) Adalah proyek dengan ukuran relatif kecil, dengan anggota tim yang sudah berpengalaman, dan mampu bekerja pada permintaan yang relatif fleksibel.
  • Proyek sedang (semi-detached mode)Merupakan proyek yang memiliki ukuran dan tingkat kerumitan yang sedang, dan tiap anggota tim memiliki tingkat keahlian yang berbeda
  • Proyek terintegrasi (embedded mode)Proyek yang dibangun dengan spesifikasi dan operasi yang ketat
Model COCOMO dasar ditunjukkan dalam persamaan 1, 2, dan 3 berikut ini:


keterangan :
  • E : besarnya usaha (orang-bulan)
  • D : lama waktu pengerjaan (bulan)
  • KLOC : estimasi jumlah baris kode (ribuan)
  • P : jumlah orang yang diperlukan.


2. Model COCOMO Lanjut (Intermediate COCOMO)

Pengembangan model COCOMO adalah dengan menambahkan atribut yang dapat menentukan jumlah biaya dan tenaga dalam pengembangan perangkat lunak, yang dijabarkan dalam kategori dan subkatagori sebagai berikut:

a. Atribut produk (product attributes)
1. Reliabilitas perangkat lunak yang diperlukan (RELY)
2. Ukuran basis data aplikasi (DATA)
3. Kompleksitas produk (CPLX)

b. Atribut perangkat keras (computer attributes)
1. Waktu eksekusi program ketika dijalankan (TIME)
2. Memori yang dipakai (STOR)
3. Kecepatan mesin virtual (VIRT)
4. Waktu yang diperlukan untuk mengeksekusi perintah (TURN)

c. Atribut sumber daya manusia (personnel attributes)
1. Kemampuan analisis (ACAP)
2. Kemampuan ahli perangkat lunak (PCAP)
3. Pengalaman membuat aplikasi (AEXP)
4. Pengalaman penggunaan mesin virtual (VEXP)
5. Pengalaman dalam menggunakan bahasa pemrograman (LEXP)

d. Atribut proyek (project attributes)
1. Penggunaan sistem pemrograman modern(MODP)
2. Penggunaan perangkat lunak (TOOL)
3. Jadwal pengembangan yang diperlukan (SCED)

3. Model COCOMO II (Complete atau Detailed COCOMO model)


Model COCOMO II, pada awal desainnya terdiri dari 7 bobot pengali yang relevan dan kemudian menjadi 16 yang dapat digunakan pada arsitektur terbarunya. Sama seperti COCOMO Intermediate (COCOMO81), masing-masing sub katagori bisa digunakan untuk aplikasi tertentu pada kondisi very low, low, manual, nominal, high maupun very high. Masing-masing kondisi memiliki nilai bobot tertentu. Nilai yang lebih besar dari 1 menunjukkan usaha pengembangan yang meningkat, sedangkan nilai di bawah 1 menyebabkan usaha yang menurun. Kondisi Laju nominal (1) berarti bobot pengali tidak berpengaruh pada estimasi. Maksud dari bobot yang digunakan dalam COCOMO II, harus dimasukkan dan direfisikan di kemudian hari sebagai detail dari proyek aktual yang ditambahkan dalam database.

Sumber :
ttp://yayuk05.wordpress.com/2007/11/09/constructive-cost-model-cocomo/
http://www.dashboardcafe.com/index.php?option=com_content&view=article&id=102:dashboard-cocomo&catid=1:beritaterbaru&Itemid=50
http://aduk-udik.blogspot.com/2011/03/cocomo-constructive-cost-model.html
http://tikknara.blogspot.com/2012/04/cocomo-constructive-cost-model.html