Jumat, 01 Mei 2015

Kriteria Manajer Proyek yang Baik

Ketika datang saatnya untuk menjadi seorang pemimpin, dibutuhkan keahlian khusus untuk mengelola dan mengatur suatu organisasi. Pemimpin harus memberikan yang terbaik kepada organisasinya, tidak peduli akan perbedaan antara setiap anggotanya. Konsep tersebut pun berlaku untuk manajemen proyek. Untuk menjadi manajer proyek yang baik harus memiliki beberapa kriteria yang baik pula. Employment Status Indicator (ESI) International telah menyusun daftar tanggapan dari sumber yang berbeda untuk membuat gambaran suatu kriteria manajer proyek yang baik. Berikut ini adalah 10 kriteria teratas yang disusun oleh ESI.
1.       Menginspirasi dengan Visi Bersama
Semua orang perlu memiliki visi yang sama untuk menyelesaikan suatu proyek. Manajer proyek yang baik membantu semua anggota tim agar mereka merasa seperti memiliki kepentingan yang sama dalam sebuah proyek, dan memberdayakan semua orang untuk berbagi dan mengalami visi kelompok. Warren Bennis, pelopor studi Kepemimpinan, mengatakan tentang jenis pemimpin yang visioner: "Mereka menawarkan kesempatan kepada orang-orang untuk menciptakan visi mereka sendiri, untuk mengeksplorasi apa visi tersebut berarti untuk pekerjaan dan kehidupan mereka, dan untuk membayangkan masa depan mereka sebagai bagian dari organisasi."
2.       Kominukator yang Baik
Kemampuan untuk berkomunikasi dengan orang-orang di semua tingkatan hampir selalu disebut sebagai keterampilan yang paling penting kedua oleh manajer proyek dan anggota tim. Kepemimpinan proyek panggilan untuk komunikasi yang jelas tentang tujuan, tanggung jawab, kinerja, harapan dan umpan balik. Ada banyak nilai yang ditempatkan pada keterbukaan dan keterusterangan. Pemimpin proyek juga merupakan penghubung terhadap tim untuk organisasi yang lebih baik. Pemimpin harus memiliki kemampuan untuk secara efektif bernegosiasi dan menggunakan persuasi bila diperlukan untuk memastikan keberhasilan tim dan proyek. Melalui komunikasi yang efektif, pimpinan proyek mendukung prestasi individu dan tim dengan menciptakan pedoman yang jelas untuk mencapai hasil dan untuk kemajuan karir anggota tim.
3.       Integritas
Salah satu hal yang paling penting bagi pemimpin proyek adalah tindakan, dan bukan sekedar kata-kata. Kepemimpinan yang baik menuntut komitmen, dan demonstrasi dari etika. Membuat standar perilaku etis bagi diri sendiri dan hidup dengan standar tersebut, serta memberi penghargaan bagi yang memberikan contoh praktek-praktek tersebut, adalah tanggung jawab pimpinan proyek. Kepemimpinan termotivasi oleh kepentingan diri sendiri, bukan untuk melayani kesejahteraan tim.
4.       Antusiasme
Pemimpin negatif dapat menjadi nyata perangkap untuk keberhasilan proyek dan efektivitas keseluruhan tim. Manajer proyek yang baik memiliki keuletan pada langkah mereka dan sikap percaya diri yang menetapkan kecepatan untuk seluruh tim mereka. Memiliki energi yang baik  sangat penting untuk menetapkan contoh positif dan sikap untuk tim. Manajer proyek yang berkomitmen positif dan memiliki tujuan bahkan ketika melakukan kesalahan akan membantu mengilhami orang lain untuk tidak menjadi negatif ketika proyek mengalami keterlambatan atau halangan.
5.       Empati
Empati dan simpati adalah dua hal yang berbeda. Simpati biasanya diproyeksikan, sedangkan empati berarti benar-benar memahami bagaimana orang lain merasakan sesuatu, terutama ketika datang ke hal-hal yang melibatkan kehidupan di luar pekerjaan. Kadang-kadang empati perlu ditunjukkan kepada anggota tim yang sedang berjuang untuk mengatasi masalah karena bisa saja terdapat masalah pribadi yang mungkin dapat mempengaruhi pekerjaan mereka. Dengan demikian, seorang manajer proyek yang kuat akan berempati dengan masalah anggota tim tanpa menunjukkan penyesalan. Memastikan anggota tim dapat tetap produktif pada proyek, tanpa memperburuk masalah pribadi mereka.
6.       Kompetensi
Anggota tim perlu merasa seperti manajer proyek mereka memiliki beberapa tingkat keahlian dalam subyek proyek. Dengan demikian, pemimpin proyek harus memiliki kemampuan untuk memimpin tim mereka dengan keahlian teknis jika suatu saat terjadi masalah teknis yang tidak dapat diatasi oleh tim. Hal ini tidak berarti seorang manajer proyek pada proyek pengembangan perangkat lunak membutuhkan kemampuan untuk membuka Visual Studio dan mulai coding di console, namun itu tidak berarti bahwa manajer proyek memahami implikasi dari tantangan teknis yang berbeda. Pemimpin yang dianggap sebagai kompeten oleh rekan-rekan mereka memiliki kemampuan untuk menginspirasi, mengaktifkan, dan mendorong.
7.       Mendelegasikan Tugas
Kepercayaan adalah bagian terbesar dari manajemen proyek yang efektif, dan berapa banyak manajer proyek percaya tim mereka sering ditunjukkan melalui seberapa besar tanggung jawab mereka bersedia untuk mendelegasikan. Manajer proyek yang baik memahami tingkat pengawasan setiap kebutuhan anggota tim untuk tugas dari masing-masing anggota. Menetapkan tugas yang tepat untuk orang yang tepat dan mempercayai mereka untuk memanfaatkan yang terbaik dari kemampuan mereka adalah kunci dari karakteristik manajer proyek yang baik.
8.       Stay Cool walaupun dalam Under Pressure
Dalam dunia yang sempurna, setiap proyek akan selesai tepat waktu, sesuai anggaran, dan pada lingkupnya. Sayangnya, kita tidak hidup di dunia yang sempurna. Ketika keadaan menjadi sulit, manajer proyek yang baik bisa tetap menjaga sikapnya untuk tenang. Bennis Waran menyatakan: " Keluar dari ketidakpastian dan kekacauan perubahan, pemimpin bangkit dan mengartikulasikan gambaran baru masa depan yang menarik proyek bersama" Singkatnya, semakin banyak manajer proyek tampak "stres", semakin banyak tim dan klien akan stres juga. Manajer proyek yang baik akan tetap dingin di bawah tekanan.
9.       Keterampilan Team Building
Sebuah pembangun tim terbaik dapat didefinisikan sebagai orang yang kuat yang memberikan substansi yang memegang tim bersama-sama dalam tujuan yang sama menuju tujuan yang tepat. Agar sebuah tim berkembang dari sekelompok orang asing ke unit kohesif tunggal, pemimpin harus memahami proses dan dinamika yang diperlukan untuk transformasi ini. Dia juga harus tahu gaya kepemimpinan yang sesuai untuk digunakan selama setiap tahap pengembangan tim. Pemimpin juga harus memiliki pemahaman tentang pemain tim yang berbeda gaya dan cara memanfaatkan masing-masing pada waktu yang tepat, untuk masalah yang dihadapi.
10.   Tahu Bagaimana Memecahkan Masalah
Manajer proyek yang baik memecahkan masalah dengan berbagi tanggung jawab dengan para ahli di tim mereka. Mirip dengan item nomor 6 di atas tentang kompetensi, bahkan manajer proyek yang baik tidak akan memiliki solusi untuk setiap masalah yang muncul, hanya saja tidak mungkin. Namun, manajer proyek yang baik akan memahami bagaimana untuk mengatur jalur menuju solusi. Hal ini berarti meningkatkan pengetahuan para anggota tim dan para pemangku kepentingan yang memiliki pengetahuan ahli untuk membantu, dan menetapkan rencana untuk memecahkan masalah yang sulit dengan memanfaatkan pengalaman tim. Sebagian besar karakteristik tersebut di atas mengikat satu sama lain, dan jika seorang manajer proyek yang baik akan menampilkan satu atau dua dari kriteria ini maka kemungkinan mereka dapat bekerja untuk menjadi lebih baik.

sumber referensi :
http://www.projectsmart.co.uk/pdf/top-10-qualities-of-a-project-manager.pdf
http://www.recruiter.com/i/10-things-that-make-a-good-project-manager-great/

COCOMO

COCOMO atau Constructive Cost Model adalah model algoritma estimasi biaya perangkat lunak yang dikembangkan oleh Barry Boehm pada tahun 1981. Model ini menggunakan dasar regresi formula, dengan parameter yang berasal dari data historis dan karakteristik proyek-proyek saat ini.

Pada tahun 1981, Barry Boehm mendesain COCOMO untuk memberikan estimasi 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, kemudian setelah itu merujuk pada COCOMO II.

Model estimasi COCOMO telah digunakan oleh ribuan project manager suatu proyek perangkat lunak, dan berdasarkan pengalaman dari ratusan proyek sebelumnya. 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. Sebagian besar dari hasil-hasil lain COCOMO, termasuk estimasi untukRequirement dan Maintenance berasal dari persamaan tersebut.

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 multipliersyang 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://rpl07.wordpress.com/2007/06/20/cocomo-constructive-cost-model-oleh-dommy-5105-100-163/
http://ethownside.blogspot.com/2012/04/constructive-cost-model-cocomo.html
http://pu2tgoclo.blogspot.com/2011/04/apa-itu-cocomo-dan-apa-saja-jenis.html

Keuntungan Menggunakan Software Open Source

Perangkat lunak sumber terbuka (Inggris: open source software) adalah jenis perangkat lunak yang kode sumber-nya terbuka untuk dipelajari, diubah, ditingkatkan dan disebarluaskan. Karena sifat ini, umumnya pengembangannya dilakukan oleh satu paguyuban terbuka yang bertujuan mengembangkan perangkat lunak bersangkutan. Anggota-anggota paguyuban itu seringkali sukarela tapi bisa juga pegawai suatu perusahaan yang dibayar untuk membantu pengembangan perangkat lunak itu. Produk perangkat lunak yang dihasilkan ini biasanya bersifat bebas dengan tetap menganut kaidah dan etika tertentu.

Semua perangkat lunak bebas adalah perangkat lunak sumber terbuka, tapi sebaliknya perangkat lunak sumber terbuka belum tentu perangkat lunak bebas, tergantung kaidah yang dipakai dalam melisensikan perangkat lunak sumber terbuka tersebut.

Berikut beberapa keuntungan menggunakan software open source :


  1. Legal, Open Source, dengan berbagai kelebihannya, juga legal. Penggunaan software Open Source di seluruh Indonesia akan menyebabkan tingkatpembajakan software di Indonesia menjadi turun drastis, dari 88% menjadi 0%.
  2. Penyelamatan Devisa Negara, Dengan menggunakan solusi berbasis Open Source, maka dapat dilakukan penghematan devisa negara secara signifikan. Kemudian dana tersebut dapat dialokasikan ke usaha-usaha untuk kesejahteraan rakyat.
  3. Keamanan Negara /Perusahaan, Software Open Source bebas dari bahaya ini,karena bisa dilakukan audit terhadap kode programnya..contoh nyata nya Di tahun 1982, terjadi ledakan dahsyat di jalur pipa gas Uni Sovyet di Siberia. Kekuatan ledakan tersebutsekitar 3 kiloton, atau 25% dari kekuatan bom nuklir Hiroshima.16 tahun kemudian baru diketahui oleh publik bahwa ledakan tersebut disebabkan oleh softwarekomputer proprietary / tertutup yang telah diubah oleh CIA.
  4. Keamanan Sistem, pada software proprietary / tertutup, sangat sulit untuk dapat benar-benar yakin dengan keamanannya; karena kita tidak tahu apa yang ada di dalamnya.Selain itu, seringkali sangat sulit untuk mendapatkan solusinya. Sebagai contoh, ada security hole diInternet Explorer yang telah diketahui sejak tahun 2002, namun masih tetap belum ada solusinya.Sebuah komputer dengan OS Microsoft Windows 2000 yang kemudian disambungkan ke Internet, dapat terserang virus dalam waktu 10 menit atau kurang. Di tahun 2006, Internet Explorer tidak aman untukdigunakan selama 284 hari . Dan seterusnya.
  5. Hemat biaya, sebagian besar developer ini tidak dibayar. Dengan demikian, biaya dapat dihemat dan digunakan untuk pengeluaran yang tidak dapat ditunda, misal membeli server untuk hosting web.
  6. Kesalahan, (bugs, error) lebih cepat ditemukan dan diperbaiki, hal ini dikarenakan jumlah developer-nya sangat banyak dan tidak dibatasi. Visual inspection (eye-balling) merupakan salah satu metodologi pencarianbugs yang paling efektif. Selain itu, source code yang tersedia membuat setiap orang dapat mengusulkan perbaikan tanpa harus menunggu dari vendor.

Serupa dengan perangkat lunak gratis, perangkat lunak sumber terbuka merupakan perangkat lunak yang juga dapat diperoleh dan didistribusikan secara bebas. Berbeda halnya dengan perangkat lunak gratis yang belum tentu boleh dilihat kode aslinya, perangkat lunak sumber terbuka dapat dibaca kode-kode pemrograman sesuai aslinya. Kode pemrograman ini dapat juga diubah, dimodifikasi dan dikembangkan sendiri oleh kita dengan tetap memperhatikan kaidah yang berlaku sesuai dengan lisensi perangkat lunak tersebut.

Sebagai contoh untuk memahami perbedaan antara kedua jenis perangkat ini dapat diilustrasikan misalnya perusahaan Microsoft pada suatu saat menjadikan salah satu produknya menjadi perangkat lunak gratis. Hal ini berarti siapapun dapat mendapatkannya secara gratis. Akan tetapi anda tidak diperkenankan untuk kemudian memodifikasi dan mengembangkan produk perangkat lunak tersebut.

Dapat disimpulkan, perangkat lunak sumber terbuka sudah pasti merupakan perangkat lunak gratis, namun sebaliknya perangkat lunak gratis belum tentu merupakan perangkat lunak sumber terbuka.

Sumber :
http://id.wikipedia.org/wiki/Perangkat_lunak_sumber_terbuka
http://komunitas-os-smkn3sby.blogspot.com/2013/05/keuntungan-dan-kerugian-menggunakan.html