Kriteria Manager 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 : http://aromblog.blogspot.co.id/2013/04/kriteria-manager-proyek-yang-baik.html

Pengertian COCOMO dan Jenis-Jenisnya

COCOMO (Constructive Cost Model )

Constructive Cost Model (COCOMO) Merupakan algoritma estimasi biaya perangkat lunak model yang dikembangkan oleh Barry Boehm. Model ini menggunakan rumus regresi dasar, dengan parameter yang berasal dari data historis dan karakteristik proyek proyek saat ini.

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.

Model Jenis COCOMO Ada tiga model cocomo, diantaranya ialah:
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. Intermediate Cocomo
Persamaan estimasi sekarang mempertimbangkan (terlepas dari DSI) 15 pengaruh faktor-faktor; ini adalah atribut produk (seperti kehandalan perangkat lunak, ukuran database, kompleksitas), komputer atribut-atribut (seperti pembatasan waktu komputasi, pembatasan memori utama), personil atribut ( seperti aplikasi pemrograman dan pengalaman, pengetahuan tentang bahasa pemrograman), dan proyek atribut (seperti lingkungan pengembangan perangkat lunak, tekanan waktu pengembangan). Tingkat pengaruh yang dapat diklasifikasikan sebagai sangat rendah, rendah, normal, tinggi, sangat tinggi, ekstra tinggi; para pengganda dapat dibaca dari tabel yang tersedia.

3. Detil Cocomo
Dalam hal ini adalah rincian untuk fase tidak diwujudkan dalam persentase, tetapi dengan cara faktor-faktor pengaruh dialokasikan untuk fase. Pada saat yang sama, maka dibedakan menurut tiga tingkatan hirarki produk (modul, subsistem, sistem), produk yang berhubungan dengan faktor-faktor pengaruh sekarang dipertimbangkan dalam persamaan estimasi yang sesuai. Selain itu detail cocomo dapat menghubungkan semua karakteristik versi intermediate dengan penilaian terhadap pengaruh pengendali biaya pada setiap langkah (analisis, perancangan, dll) dari proses rekayasa PL

Sumber : https://inarjutex.wordpress.com/2011/05/28/pengertian-cocomo-dan-jenisnya/

Kenapa anda dianjurkan menggunakan software open source dalam membuat aplikasi ? Buatlah keuntungan dan kerugiannya?

Open Source adalah sebuah sistem baru dalam mendistribusikan software kepada pengguna dengan memberikan program dan source code nya secara gratis! Bahkan pengguna dapat mempelajari dan melakukan modifikasi untuk membuat software tersebut sesuai dengan kebutuhan mereka. Richard M. Stallman,pendiri Free Software Foundation -sebuah organisasi yang mendukung Open Source,mengeluarkan sebuah lisensi software untuk Open Source yang dinamakan GPL (GNU Public License). Lisensi inilah yang saat ini paling banyak digunakan untuk mendistribusikan software Open Source. Selain GPL, masih banyak lisensi software lainnya yang dikembangkan oleh komunitas Open Source.

Berikut adalah keuntungan software Open Source:
Sisi pengguna:

• Gratis
• Pengguna dapat terlibat dalam pengembangan program karena memiliki source code nya
• Respon yang baik dari pemakai sehingga bug dapat ditemukan dan diperbaiki dengan lebih cepat.

Sisi developer:

• Seluruh komunitas mau dan dapat membantu untuk membuat software menjadi lebih baik 
• Tidak ada biaya iklan dan perawatan program
• Sebagai sarana untuk memperkenalkan konsep
• Linux adalah sebuah contoh yang bagus. Banyak sistem operasi yang berusaha meniru kisah sukses Linux, tetapi Linux tetap yang paling sukses hingga saat ini. Aspek positif dari Open Source adalah penerimaan yang luas untuk software yang benar-benar bagus.

Selain itu keuntungan dari opensource yaitu:

Meningkatnya reliabilitas. Oleh karena kode sumber untuk program-program open source tersedia secara bebas maka program yang dibuat oleh seseorang ataupun sesuatu organisasi akan mendapatkan review dari rekan-rekannya ataupun pihak-pihak lain. Hal ini mengakibatkan program-program open source mempunyai reliabilitas yang lebih tinggi dibandingkan dengan program-program closed source (proprietary). Reliabilitas yang tinggi ini tentu saja menguntungkan bagi pihak customer karena ia dapat memperoleh program-program yang dapat diandalkan dalam melakukan tugas-tugas yang diberikan kepadanya.
Meningkatnya keamanan. Selain itu dengan tersedianya kode sumber maka segala kesalahan yang terdapat dalam program, misalnya kesalahan logika ataupun kesalahan pengkodean, dapat segera diperbaiki tanpa perlu menunggu waktu yang lama, karena seseorang yang menemukan kesalahan tersebut dapat saja segera memperbaikinya dan mengirimkan perbaikan tersebut ke Internet atau bila ia tidak mampu memperbaikinya ia dapat memberitahu pihak-pihak lain. Sebagai contoh, suatu kesalahan dalam Linux umumnya segera diperbaiki dalam kurun waktu kurang dari satu hari, bahkan dalam beberapa jam sejak dikeluarkan. Namun demikian, software yang didistribusikan secara open source tidak menjamin bahwa software tersebut aman.
Selain itu dengan tersedianya kode sumber maka customer akan merasa lebih nyaman, lebih yakin karena ia tidak membeli kucing dalam karung. Bagaimanakah perasaan Anda bila mobil yang Anda beli tidak dapat dilihat mesinnya ataupun bagian-bagian dalam lainnya ?


Berikut ini adalah beberapa alasan orang membuat software open source :

Kebutuhan. Software-software open source biasanya dikembangkan karena kebutuhan si pembuatnya. Dalam papernya yang berjudul “The Cathedral and the Bazaar” [Eri00], Eric S. Raymond, menjelaskan secara rinci bagaimana ia mengembangkan software fetchmail, yang disebabkan oleh tiadanya software yang sesuai dengan kebutuhannya. Pengembangan fetchmail juga dimaksudkan untuk menguji beberapa buah teori dalam rekayasa perangkat lunak yang didasarkan pada pengamatannya terhadap Linux.
Kepuasan. Banyak programer mengembangkan software karena mereka mencintainya dan hal tersebut merupakan pengungkapan intelektualitas mereka. Tanpa melakukan pengkodean, programer merasa dirinya tidak lengkap sebagai manusia.
Popularitas. Tidak dapat dipungkiri lagi bahwa beberapa orang membuat software open source demi popularitas. Dengan makin banyaknya software yang ditulisnya maka seseorang akan merasa lebih dihargai oleh sejawatnya.
Uang. Dengan menulis software-software open source maka seseorang dapat meningkatkan nilai dirinya bila nanti direkrut oleh perusahaan-perusahaan. Selain itu, bila software yang dikembangkannya banyak dibutuhkan oleh perusahaan-perusahaan, pembuat software tersebut dapat saja mendirikan sebuah perusahaan untuk memberikan pelayanan bagi perusahaan. Contoh hal ini adalah Eric Allman yang mendirikan perusahaan Sendmail Inc. untuk memberikan pelayanan tambahan bagi mereka yang menggunakan Sendmail.


Permasalahan Open Source


Pengembangan software berbasiskan open source selain memberikan beberapa buah keuntungan sebagaimana yang telah disebutkan di bagian terdahulu , softwate open source juga mempunyai kerugian :

Dengan banyaknya orang yang terlibat dalam pembuatan proyek software tidak menjamin bahwa proyek akan selesai dengan lebih cepat. Ada kemungkinan proyek bahkan tidak dapat terlaksana. Hal ini disebabkan dengan semakin banyaknya orang maka perbedaan akan sering terjadi, oleh karena itu diperlukan seorang pemimpin yang mampu bekerja sama dengan rekan-rekannya yang lain untuk membuat suatu arahan yang jelas tentang proyek.
Menurut Alan Cox dalam papernya “Cathedrals, Bazaars and the Town Council” [Ala98], permasalahan akan muncul ketika tibanya banyak orang yang tidak paham dan mereka mulai mengemukakan opininya, bukan memberikan kodenya. Mereka berdebat tentang hal-hal yang tidak berguna. Hal ini tentu saja akan sangat merugikan karena perdebatan tersebut tidak akan menghasilkan apa-apa.
Konflik di antara para pengembang. Terkadang dalam model open source sebagaimana juga terjadi dalam model pengembangan ilmiah, terjadi konflik antara para pengembang. Hal ini dapat terjadi bila satu atau beberapa pengembang merasa tidak puas dengan pengembang lainnya, baik dalam hal pencapaian ataupun masalah-masalah teknis dalam proyek yang sedang mereka kerjakan. Bilamana hal ini telah terjadi dapat mengakibatkan tertundanya proyek yang sedang mereka kerjakan, bahkan tidak tertutup kemungkinan proyek tersebut menjadi gagal.
Fragmentasi. Dengan tersedianya kode sumber untuk setiap aplikasi, maka seseorang dapat saja merubah sebagian kode sumber asli dan mengeluarkan aplikasi yang sama dengan nama baru atau mengeluarkan aplikasi sama dengan versi baru.
Ketergantungan pada satu orang pemimpin. Proyek-proyek open source biasanya dimulai oleh satu atau beberapa orang, sehingga ketergantungan menjadi sangat tinggi. Dengan berlalunya waktu, para pemimpin tersebut mungkin menjadi bosan, burn-out, dipekerjakan oleh organisasi lain. Akibatnya proyek-proyek yang mereka tangani dapat menjadi tertunda atau bahkan mungkin hilang.
Penjiplakan. Dengan tersedianya kode sumber bagi setiap software, tidak tertutup kemungkinan ada pihak-pihak yang memanfaatkan hal tersebut demi kepentingan dirinya, misalnya saja seorang mahasiswa ilmu komputer mendapat tugas untuk membuat suatu program, ia kemudian mencarinya di Internet dan mendapatkan versi open sourcenya. Lalu ia memodifikasi sedikit program tersebut dan menyerahkan pada dosennya untuk dinilai. Bila dosen tidak waspada maka program tersebut akan lolos dan si mahasiswa akan mendapat nilai dengan mudah dan tidak adil bagi mahasiswa yang membuatnya sendiri.

Sumber : http://bomy-id.blogspot.co.id/2014/04/kenapa-dianjurkan-menggunakan-software.html