Kriteria Manager yang Baik

Kriteria Manager yang Baik

Setiap organisasi memilih Manajer proyek yang professional dalam bidang manajemen proyek agar dia dapat bertanggung jawab untuk menyelesaikan tugas atau proyek tersebut sesuai denga tujuan organisasi. Baik proyek dalam bidang pendidikan, arsitektur, telekomunikasi dan informasi teknologi  dll

Dalam hal ini kriteria menajer yang baik adalah yang memiliki dasar ilmu pengetahuan sebagai teori maupun pedoman serta kemampuan/skill dalam setiap kegiatan yang dilakukan.

Berikut ini ilmu pengetahuan yang harus dimiliki untuk menjadi manajer proyek yang baik, terdapat 9 ilmu yang harus dikuasai. Adapun ke sembilan ilmu yang dimaksud antara lain :

·         Manajemen Ruang Lingkup;

·         Manajemen Waktu;

·         Manajemen Biaya;

·         Manajemen Kualitas;

·         Manajemen Sumber Daya Manusia;

·         Manajemen Pengadaan;

·         Manajemen Komunikasi;

·         Manajemen Resiko;

·         Manajemen Integrasi.

 Sedangkan kemampuan (skill) untuk menjadi seorang manajer proyek yang baik adalah sebagai berikut :

·         Problem Solving, kemampuan manajer dalam menyelesaikan masalah secara efektif dan efisien.

·         Budgeting and Cost Skills, Kemampuan dalam hal membuat anggaran biaya proyek, analisis kelayakan investasi agar keuangan proyek dapat berjalan optimal sesuai dengan keinginan penyedia dana.

·         Schedulling and Time Management Skills, kemampuan untuk menjadwalkan proyek. Disini manajer proyek dituntut untuk dapat mengelola waktu secara baik agar proyek dapat selesai tepat waktu seperti yang diharapkan.

·         Technical Skills, Kemampuan teknis melingkupi pengetahuan dan pengalaman dalam hal proyek itu sendiri, dengan mengetahui prosedur-prosedur dan mekanisme proyek. Kemampuan teknis biasanya di dapat dari penimbaan ilmu khusus di bangku formal, misalnya Institut Manajemen Proyek, dan sebagainya.

·         Leadership Skills, Kepemimpinan menjadi salah satu peranan penting yang dimiliki oleh seorang manajer proyek.

·         Resource Management and Human Relationship Skills, Pemakaian sumber daya adalah masalah utama bagi para manajer proyek. Manajer proyek perlu memahami akibat dari kegagalan dalam mengelola sumber daya, oleh karena itu perlu kehati-hatian dalam menempatkan sumberdaya yang ada dan menjadwalkannya

·         Communication Skills, Perencanaan sebuah proyek akan menjadi tidak berguna ketika tidak ada komunikasi yang efektif antara manajer proyek dengan timnya. Setiap anggota tim harus mengetahui tanggung jawab mereka. Kadang, jadwal perencanaan yang sudah dibuat secara sempurna oleh manajer proyek tidak dijalankan oleh timnya, tim lebih memilih bekerja dengan aturan mereka sendiri. Hal ini dikarenakan sang manajer tidak memberikan penjelasan atau mempresentasikan prosedur yang diinginkan dalam menjalankan proyek.

Sumber :

-          http://id.wikipedia.org/wiki/Manajemen_proyek

-          http://nayay.wordpress.com/2010/03/08/manager-proyek/

-          http://ferryibo.blogspot.com/2011/04/pengertian-manajer.html

-           http://ndtndt-bagol.blogspot.com/2012/06/kriteria-manajer-proyek-yang-baik.html

Keuntungan dan Kerugian Menggunakan Software Open Source

Keuntungan dan Kerugian Menggunakan Software Open Source

 Factor yang menyebabkan orang / user banyak menggunakan software open source karena memiliki sifat FREE  yaitu seperti :

Ø Bebas memiliki software yang tersedia sesuai kebutuhan

Ø Bebas menggunakan software sesuai keinginannya (di kembangkan ataupun di publikasikan/di distribusikan)

Ø Bebas untuk menjalankan programnya untuk tujuan apa saja.

Beberapa keuntungan dari software open source :

v    Penghematan biaya karena mendapatkanya secara gratis.

v    Keamanan perusahaan /  Negara karena memiliki system tertutup

v    Ketersediaan source code dan hak untuk memodifikasi.

v    Penggunanya free license dan  legal

v    Hak untuk mendistribusikan modifikasi dan perbaikan pada code.

v    Software open source berjalan stabil dan mendukung berjalan di berbagai platform.

v    Software open source tangguh dalam menghadapi berbagai macam virus komputer

Beberapa kekurangan dari software opensource :

ü Software open source  tidak  memiliki  garansi  dari  pihak  pengembang.

ü Support berbayar dan langka.

ü Software open source tidak begitu friendly seperti software berlesensi, atau dengan kata lain cukup sulit di mengerti.

ü Kerja komunitas bukan professional Beberapa software dikembangkan oleh sebuah komunitas yang mempunya tujuan khusus, jaminan dan kepercayaan kualitas produk hasil perlu dicompare dengan produk komersil yang jauh lebih mumpuni dari segala sisi.

ü Open Source digunakan secara sharing, dapat menimbulkan resiko kurangnya diferensiasi antara satu software dengan yang lain, apabila kebetulan menggunakan beberapa Open Source yang sama.

Sumber :

http://jnanayoga-online.blogspot.com/2011/05/macam-macam-lisensi-pada-software.html

http://yudha-software.blogspot.com/2012/06/pengertian-open-source-dan-macam-macam.html

http://freezcha.wordpress.com/2011/03/18/keuntungan-dan-kerugian-penggunaan-open-source/

budi.insan.co.id/courses/ec7010/dikmenjur/winarso-report.doc

http://ndtndt-bagol.blogspot.com/2012/06/keuntungan-dan-kerugian-menggunakan.html

Pengertian COCOMO  dan Jenis - jenisnya

I.   Pengertian COCOMO

          COCOMO adalah sebuah model yang didesain oleh Barry Boehm untuk memperoleh perkiraan dari jumlah orang-bulan yang diperlukan untuk mengembangkan suatu produk perangkat lunak. Satu hasil observasi yang paling penting dalam model ini adalah bahwa motivasi dari tiap orang yang terlibat ditempatkan sebagai titik berat. Hal ini menunjukkan bahwa kepemimpinan dan kerja sama tim merupakan sesuatu yang penting, namun demikian poin pada bagian ini sering diabaikan.

II.   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.

           Referensi untuk model ini biasanya menyebutnya COCOMO 81. Pada tahun 1997 COCOMO II telah dikembangkan dan akhirnya diterbitkan pada tahun 2000 dalam buku Estimasi Biaya COCOMO II Software dengan COCOMO II. adalah penerus dari COCOMO 81 dan lebih cocok untuk mengestimasi proyek pengembangan perangkat lunak modern. Hal ini memberikan lebih banyak dukungan untuk proses pengembangan perangkat lunak modern, dan basis data proyek diperbarui. Kebutuhan model baru datang sebagai perangkat lunak teknologi pengembangan pindah dari batch processing mainframe dan malam untuk pengembangan desktop, usabilitas kode dan penggunaan komponen software off-the-rak. Artikel ini merujuk pada COCOMO 81.

III.  Jenis-jenis COCOMO

1. Model COCOMO Dasar

Model COCOMO dapat diaplikasikan dalam tiga tingkatan kelas:

a.       Proyek organik (organic mode)

Proyek organik merupakan proyek dengan ukuran relatif kecil, dengan anggota tim yang sudah berpengalaman, dan mampu bekerja pada permintaan yang relatif fleksibel.

b.       Proyek sedang (semi-detached mode)

Proyek sedang merupakan proyek yang memiliki ukuran dan tingkat kerumitan yang sedang, dan tiap anggota tim memiliki tingkat keahlian yang berbeda

c.       Proyek terintegrasi (embedded mode)

Proyek terintegrasi merupakan proyek yang dibangun dengan spesifikasi dan operasi yang ketat

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)

2.1 Persamaan Perangkat Lunak

Persamaan perangkat lunak merupakan model variabel jamak yang menghitung suatu distribusi spesifik dari usaha pada jalannya pengembangan perangkat lunak. 

2.2 Konversi Waktu Tenaga Kerja

Konversi waktu tenaga kerja ini diperoleh dari angka pembanding yang digunakan pada perangkat lunak ConvertAll, dengan hubungan persamaan antara orang-bulan (OB), orang-jam (OJ), orang-minggu (OM), dan orang-tahun (OT) adalah sebagai berikut :

OM = 40 OJ (6)

OT = 12 OB (7)

OT = 52 OM (8)

Dari persamaan di atas, diperoleh konversi orang-bulan ke orang-jam sebagai berikut :

OB = (40 OJ x 52) / 12

OB = 173,33 OJ (9)

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.

IV.   Metodologi Dashboard COCOMO.

Pada gambar dibawah ini dijelaskan tentang metodologi dashboard COCOMO. yang menggunakan demo dashboard LIVE Xcelsius. Anda dapat menggunakan komponen interaktif xcelsius dashboard ini untuk mengubah faktor dalam model dan langsung melihat hasilnnya. KPIs dalam Produk, Computer, Personalia dan Kategori Proyek.

Sumber :

http://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://dwiyuliani-dwiyuliani.blogspot.com/2011/04/cocomo.html