Minggu, 15 April 2012

kreteria manager proyek yang baik

0 komentar Diposting oleh nda_kamal di 02.47


DEFENISI MANAJER PROYEK


Menurut Project Mangement Body of Knowledge Guide (PMI 2001) mengatakan bahwa manajer proyek seseorang yang bertanggung jawab dalam mengurus sebuah proyek. Menurut Ritz (1994) seorang manajer proyek berasal dari suatu institusi atau seorang pengusaha yang sinonim dengan pengurus, eksekutif, supervisor dan boss.
Pemilihan seorang manajer proyek merupakan satu dari dua atau tiga keputusan paling utama mengenai proyek. Manajer proyek perlu memiliki kerangka harapan agar dapat berhasil dengan baik. Berikut adalah daftar kepopuleran, keterampi– lan dan kualitas yang dicari manakala pemilihan seorang manajer proyek:

1.Latar belakang teknis yang kuat.
2.Seorang manajer yang keras kepala.
3.Individu yang bersifat dewasa.
4.Seseorang yang tersedia.
5.Seseorang yang memiliki hubungan baik dengan para eksekutif senior.
6.Seseorang yang dapat memelihara kebahagiaan tim proyek.
7.Orang yang telah bekerja dalam beberapa departemen berbeda.


Berikut ini penjelasan kriteria manajer yang baik menurut pendekatannya kepada landasan Pancasila yaitu sebagai berikut :
1.       Bertaqwa kepada Tuhan Yang Maha Esa, dengan selalu bertaqwa kepada Tuhan Yang Maha Esa, maka sifat-sifat yang baik dari seorang manajer akan terjamin dalam pelaksanaannya.
2.      Ing ngarso sung tulodho, memberi suri teladan kepada para bawahannya dalam lingkungan organisasinya, dengan contoh/pelaksanaan kerja secara riil.
3.      Ing madya mangun karso,seorang manajer harus mampu membangkitkan semangat kerja para bawahannya, berusaha dan berpikir sendiri dan memberi kesempatan dan memupuk kemampuan bawahannya untuk dapat berkembang.
4.      Tut wuri handayani, seorang manajer harus mampu mendorong para bawahannya agar berani berjalan di depan dan sanggup bertanggung jawab, berjalan di depan artinya mengambil prakarsa dalam melaksanakan tugas tertentu.
5.      Waspodo purbo waseso, selalu waspada, sanggup mengawasi dan memberi koreksi kepada para bawahannya.
6.      Ambek paromo arto, dapat memilih dengan tepat mana yang harus didahulukan.
7.      Prasojo, sederhana atau tidak berlebih-lebihan.
8.     Setyo, bersikap loyal baik terhadap tugas maupun terhadap sesama anggota organisasi secara timbal balik (vertikal dan horizontal) yang didasari oleh semangat kekeluargaan / kesetiakawanan.
9.      Gemi nastiti, mampu mengatasi penggunaan/pengeluaran segala sesuatu kepada yang benar-benar diperlukan (tidak bersifat boros).
10.  Beloko, bersedia untuk dikoreksi oleh pihak lain dan berani mempertanggung jawabkan atas segala tindakannya.
11.   Legowo, berjiwa besar dan ikhlas apabila suatu saat untuk menyerahakan segala tanggung jawabnya dan kedudukannya kepada generasi berikutnya (regenerasi).

Kriteria Manajer Proyek Yang Efektif Nobody’s Perfect, 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:
  1. Inovasi dan menjaga stabilitas.
  2. Menetapkan gambaran dan terlibat langsung di lapangan.
  3. Mendorong individu tetapi juga menekan tim.
  4. Campur tangan atau tidak.
  5. Fleksibel tapi ketat.
  6. 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:

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.

Integritas Pribadi, membangun dan meningkatkan kemampuan diri menjadi sangat penting dilakukan terlebih dahulu sebelum meningkatkan kemampuan anggota tim.
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)
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. Perspektif Bisnis Umum, seorang manajer proyek harus memahami dasar-dasar bisnis dari disiplin teknis yang berbeda-beda sebagai kerja antar fungsional.

Komunikator yang baik, telah dijelaskan sebelumnya. Manajemen waktu yang efektif, telah dijelaskan sebelumnya. Politikus Mahir, strategi dalam menghadapi banyak orang dan mendapatkan dukungan dari semua pihak merupakan cirri penting manajer proyek yang sukses.

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.

Ada tiga garis besar yang dibahas dalam buku ini untuk menciptakan berlangsungnya sebuah proyek, yaitu :
1. Perencanaan
Untuk mencapai tujuan, sebuah proyek perlu suatu perencanaan yang matang. Yaitu dengan meletakkan dasar tujuan dan sasaran dari suatu proyek sekaligus menyiapkan segala program teknis dan administrasi agar dapat diimplementasikan.Tujuannya agar memenuhi persyaratan spesifikasi yang ditentukan dalam batasan waktu, mutu, biaya dan keselamatan kerja. Perencanaan proyek dilakukan dengan cara studi kelayakan, rekayasa nilai, perencanaan area manajemen proyek (biaya, mutu, waktu, kesehatan dan keselamatan kerja, sumberdaya, lingkungan, resiko dan sistem informasi.

2. Penjadwalan
Merupakan implementasi dari perencanaan yang dapat memberikan informasi tentang jadwal rencana dan kemajuan proyek yang meliputi sumber daya (biaya, tenaga kerja, peralatan, material), durasi dan progres waktu untuk menyelesaikan proyek. Penjadwalan proyek mengikuti perkembangan proyek dengan berbagai permasalahannya. Proses monitoring dan updating selalu dilakukan untuk mendapatkan penjadwalan yang realistis agar sesuai dengan tujuan proyek. Ada beberapa metode untuk mengelola penjadwalan proyek, yaitu Kurva S (hanumm Curve), Barchart, Penjadwalan Linear (diagram Vektor), Network Planning dan waktu dan durasi kegiatan. Bila terjadi penyimpangan terhadap rencana semula, maka dilakukan evaluasi dan tindakan koreksi agar proyek tetap berada dijalur yang diinginkan.

3. Pengendalian Proyek
Pengendalian mempengaruhi hasil akhir suatu proyek. Tujuan utama dari utamanya yaitu meminimalisasi segala penyimpangan yang dapat terjadi selama berlangsungnya proyek. Tujuan dari pengendalian proyek yaitu optimasi kinerja biaya, waktu , mutu dan keselamatan kerja harus memiliki kriteria sebagai tolak ukur. Kegiatan yang dilakukan dalam proses pengendalian yaitu berupa pengawasan, pemeriksaan, koreksi yang dilakukan selama proses implementasi.


SUMBER
http://eziekim.wordpress.com/2012/04/12/kriteria-manajer-proyek-yang-baik/
http://wartawarga.gunadarma.ac.id/2012/04/kriteria-manager-proyek/

 

Jumat, 06 April 2012

COCOMO

0 komentar Diposting oleh nda_kamal di 09.34



COCOMO (Constructive Cost Model) dikembangkan pada tahun 1981, oleh Barry Boehm memperkenalkan hirarki model estimasi PL dengan nama COCOMO, Barry Boehm mendesain COCOMO untuk memberikan estimasi / perkiraan jumlah Person-Months untuk mengembangkan suatu produk software. Referensi pada model ini dikenal dengan nama COCOMO 81.
Pada tahun 1990, muncul suatu model estimasi baru yang disebut dengan COCOMO II. Secara umum referensi COCOMO sebelum 1995 merujuk pada original COCOMO model yaitu COCOMO 81, setelah itu merujuk pada COCOMO II.
COCOMO II diset sebagai siklus hidup software modern. Orgininal COCOMO model sudah sangat berhasil, tetapi tidak sesuai dengan praktek pengembangan software yang lebih baru sebagaimana dengan software tradisional. COCOMO II menargetkan proyek software pada tahun 1990an sampai 2000an dan akan terus berkembang dalam beberapa tahun ke depan.
Sejarah singkat 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.
Pengertian cocomo 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.Dalam perkembangannya, COCOMO memiliki 3 jenis implementasi, yaitu :


1. Basic COCOMO (COCOMO I 1981)
Menghitung dari estimasi jumlah LOC (Lines of Code). Pengenalan COCOMO ini diawali di akhir tahun 70-an. Sang pelopor, Boehm, melakukan riset dengan mengambil kasus dari 63 proyek perangkat lunak untuk membuat model matematisnya. Model dasar dari model ini adalah sebuah persamaan sebagai berikut :
effort = C * size^M
ket :
effort  = usaha yang dibutuhkan selama proyek, diukur dalam person-months;
c dan M = konstanta-konstanta yang dihasilkan dalam riset Boehm dan tergantung pada penggolongan besarnya proyek perangkat lunak
size = estimasi jumlah baris kode yang dibutuhkan untuk implementasi, dalam satuan KLOC (kilo lines of code).
COCOMO berlaku untuk tiga kelas proyek perangkat lunak:
Organik proyek : “kecil” tim dengan pengalaman “baik” bekerja dengan “kurang dari kaku” persyaratan.
Semi-terpisah proyek : “sedang” tim dengan pengalaman bekerja dicampur dengan campuran persyaratan kaku kaku dan kurang dari.
Embedded proyek : dikembangkan dalam satu set “ketat” kendala (hardware, software, operasional).


             2. Intermediate COCOMO (COCOMO II 1999)
Menghitung dari besarnya program dan cost drivers (faktor-faktor yang berpengaruh langsung kepada proyek), seperti: perangkat keras, personal, dan atribut-atribut proyek lainnya. Selain itu pada jenis ini, COCOMO mempergunakan data-data historis dari proyek-proyek yang pernah menggunakan COCOMO I, dan terdaftar pengelolaan proyeknya dalam COCOMO database. yang dijabarkan dalam kategori dan sub-kategori 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)

COCOMO II EFFORT EQUATION
Model COCOMO II ini membuat estimasi dari usaha yang dibutuhkan (diukur dari Person-Month) berdasarkan keutamaan dalam estimasi anda akan ukuran proyek perangkat lunak (yang diukur dalam ribuan SLOC atau KSLOC) :
Effort = 2,94 * EAF * (KSLOC)E
ket:
EAF = Effort Adjustment Factor yang berasal dari Cost Drivers adalah produk dari effort multipliers yang terhubung pada masing-masing cost drivers untuk proyek.
E = Eksponen yang berasal dari Scale Drivers.

COCOMO II SCHEDULE EQUATION
COCOMO II Schedule Equation memprediksi jumlah bulan yang dibutuhkan untuk menyelesaikan proyek perangkat lunak anda. Durasi dari proyek berdasarkan pada usaha yang diprediksi oleh effort equation :
Duration = 3,67 * (Effort)SE
Dimana :
Effort = usaha dari COCOMO II effort equation.
SE = eksponen scheduled equation yang berasal dari Scale Drivers.

COCOMO II memiliki 3 model berbeda, yakni:
a) The Application Composition Model
Sesuai untuk pembangunan proyek dengan tools GUI-builder yang modern. Berdasar pada Object Points baru.

            b) The Early Design Model
Model ini dapat digunakan untuk mendapat estimasi kasar biaya dan durasi dari suatu proyek sebelum menentukan arsitektur keseluruhan proyek tersebut. Model ini menggunakan sekumpulan kecil cost driver baru dan persamaan estimasi baru. Berdasar pada Unadjusted Function Points atau KSLOC.

   c) The Post-Architecture Model
Ini adalah model COCOMO II yang paling detail. Digunakannya setelah membentuk arsitektur proyek secara menyeluruh. Model ini memiliki cost driver baru, aturan penghitungan baris yang baru, dan persamaan baru.

          3. Advance COCOMO
Memperhitungkan semua karakteristik dari intermediate di atas dan cost drivers dari setiap fase (analisis, desain, implementasi, dsb) dalam siklus hidup pengembangan perangkat lunak. Model rinci kegunaan yang berbeda upaya pengali untuk setiap driver biaya atribut tersebut. Sensitif pengganda tahap upaya masing-masing untuk menentukan jumlah usaha yang dibutuhkan untuk menyelesaikan setiap tahap.
Pada COCOMO rinci, upaya dihitung sebagai fungsi dari ukuran program dan satu set driver biaya yang diberikan sesuai dengan tiap tahap siklus hidup rekayasa perangkat lunak. Fase yang digunakan dalam COCOMO rinci perencanaan kebutuhan dan perancangan perangkat lunak, perancangan detil, kode dan menguji unit, dan pengujian integrasi.

SUMBER :
http://wartawarga.gunadarma.ac.id/2012/03/cocomo-9/
http://eziekim.wordpress.com/2012/04/06/cocomo/


 

;;
Subscribe to: Postingan (Atom)