Kriteria Manager Proyek yang Baik

   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. Berikut kepopuleran dan keterampilan seorang manager :

·        Latar belakang teknis yang kuat.

·        Seorang manajer yang keras kepala.

·        Individu yang bersifat dewasa.

·        Seseorang yang tersedia.

·        Seseorang yang memiliki hubungan baik dengan para eksekutif senior.

·        Seseorang yang dapat memelihara kebahagiaan tim proyek.

·        Orang yang telah bekerja dalam beberapa departemen berbeda.

   Menurut Timothy R. Barry dalam artikelnya di http://projectsmart.co.uk mengatakan ada 10 kriteria dalam menjadi manajer proyek yang baik, yaitu :

1. Menginspirasi Visi Bersama

Seorang pemimpin proyek yang efektif sering digambarkan sebagai memiliki visi ke mana harus pergi dan kemampuan untuk mengartikulasikan itu. Visioner berkembang pada perubahan dan mampu menarik batas-batas baru. Hal ini pernah dikatakan bahwa seorang pemimpin adalah seseorang yang "mengangkat kita, memberi kita alasan untuk menjadi dan memberikan visi dan semangat untuk berubah." Pemimpin visioner memungkinkan orang untuk merasa bahwa mereka memiliki kepentingan nyata dalam proyek tersebut. Mereka memberdayakan orang untuk mengalami visi sendiri. Menurut Bennis "Mereka menawarkan kesempatan orang untuk menciptakan visi mereka sendiri, untuk mengeksplorasi apa visi akan berarti untuk pekerjaan dan kehidupan mereka, dan untuk membayangkan masa depan mereka sebagai bagian dari visi untuk organisasi."(Bennis, 1997).

2. Pembicara 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 ditempatkan pada keterbukaan dan keterusterangan. Pemimpin proyek juga link tim untuk organisasi yang lebih besar. Pemimpin harus memiliki kemampuan untuk secara efektif bernegosiasi dan menggunakan persuasi bila diperlukan untuk memastikan keberhasilan tim dan proyek. Melalui komunikasi yang efektif, pemimpin proyek dukungan prestasi individual dan tim dengan membuat pedoman yang jelas untuk mencapai hasil dan untuk kemajuan karir anggota tim.

3. Integritas

Salah satu hal yang paling penting seorang pemimpin proyek harus diingat adalah bahwa nya tindakan, dan bukan kata-kata, mengatur modus operandi untuk tim. Kepemimpinan yang baik menuntut komitmen untuk, dan demonstrasi, praktek etika. Menciptakan standar perilaku etis bagi diri sendiri dan hidup dengan standar-standar, serta penghargaan mereka yang memberikan contoh praktek-praktek, adalah tanggung jawab pemimpin proyek.Kepemimpinan termotivasi oleh kepentingan diri sendiri tidak melayani kesejahteraan tim.Kepemimpinan didasarkan pada integritas mewakili tidak kurang dari satu set nilai-nilai orang lain, perilaku yang konsisten dengan nilai-nilai dan dedikasi untuk kejujuran diri dan dengan anggota tim. Dengan kata lain pemimpin "berjalan pembicaraan" dan dalam proses mendapatkan kepercayaan.

4. Antusiasme

Polos dan sederhana, kita tidak suka pemimpin yang negatif - yang mereka bawa kita.Kami ingin pemimpin dengan antusias, dengan bouncing pada langkah mereka, dengan sikap bisa-melakukan. Kami ingin percaya bahwa kita adalah bagian dari sebuah perjalanan menyegarkan - kita ingin merasa hidup. Kita cenderung mengikuti orang-orang dengan sikap bisa-melakukan, bukan mereka yang memberi kita 200 alasan mengapa sesuatu tidak dapat dilakukan. Antusias para pemimpin berkomitmen untuk tujuan mereka dan mengekspresikan komitmen ini melalui optimisme. Kepemimpinan muncul sebagai seseorang menyatakan komitmen percaya diri seperti itu untuk proyek yang lain ingin berbagi harapan optimis nya. Antusiasme bersifat menular dan pemimpin yang efektif tahu itu.

5. Empati

Apa perbedaan antara empati dan simpati? Meskipun kata-kata yang serupa, mereka, pada kenyataannya, saling eksklusif. Menurut Norman Paulus, dalam simpati subjek ini terutama diserap dalam perasaan sendiri karena mereka diproyeksikan ke objek dan memiliki kepedulian kecil untuk realitas dan validitas pengalaman khusus benda. Empati, di sisi lain, mengandaikan keberadaan objek sebagai individu yang terpisah, berhak nya perasaannya sendiri, ide-ide dan sejarah emosional (Paul, 1970). Sebagai salah satu siswa sehingga fasih mengatakan, "Ini bagus ketika pemimpin proyek mengakui bahwa kita semua memiliki kehidupan di luar pekerjaan."

6. Kompetensi

Sederhananya, mendaftarkan diri dalam menyebabkan lain, kita harus percaya bahwa orang yang tahu apa yang dia lakukan. Kompetensi kepemimpinan tidak selalu bagaimanapun kemampuan teknis mengacu pada pemimpin proyek dalam teknologi inti dari bisnis. Sebagai manajemen proyek terus diakui sebagai lapangan dalam dan dari dirinya sendiri, pemimpin proyek akan dipilih berdasarkan kemampuan mereka untuk berhasil memimpin orang lain bukan pada keahlian teknis, seperti di masa lalu. Memiliki track record menang adalah cara paling pasti untuk dianggap kompeten. Keahlian dalam keterampilan kepemimpinan adalah dimensi lain dalam kompetensi. Kemampuan untuk tantangan, menginspirasi, memungkinkan, model dan mendorong harus ditunjukkan jika pemimpin harus dilihat sebagai mampu dan kompeten.

7. Kemampuan untuk Mendelegasikan Tugas

 Kepercayaan merupakan elemen penting dalam hubungan seorang pemimpin proyek dan tim nya. Anda menunjukkan kepercayaan Anda pada orang lain melalui tindakan Anda - seberapa banyak Anda memeriksa dan mengontrol pekerjaan mereka, seberapa banyak Anda mendelegasikan dan seberapa banyak Anda memungkinkan orang untuk berpartisipasi. Individu yang tidak mampu untuk mempercayai orang lain sering gagal sebagai pemimpin dan selamanya tetap sedikit lebih bahwa mikro-manajer, atau akhirnya melakukan semua pekerjaan sendiri. Sebagai salah satu proyek mahasiswa manajemen mengatakan, "Seorang pemimpin yang baik sedikit malas." Sebuah perspektif yang menarik!

8. Tenang di Bawah Tekanan

Dalam dunia yang sempurna, proyek akan disampaikan pada waktu, di bawah anggaran dan tanpa masalah besar atau rintangan. Tapi kita tidak hidup di dunia yang sempurna - proyek mengalami masalah. Seorang pemimpin dengan sikap tangguh akan membawa masalah ini dengan tenang. Ketika para pemimpin menghadapi peristiwa stres, mereka menganggap itu menarik, mereka merasa bahwa mereka dapat mempengaruhi hasil dan mereka melihatnya sebagai sebuah kesempatan. "Keluar dari ketidakpastian dan kekacauan perubahan, pemimpin bangkit dan mengartikulasikan sebuah gambar baru masa depan yang menarik proyek bersama." (Bennis 1997) Dan ingat - tidak pernah membiarkan mereka melihat Anda berkeringat.

9. Membangun Keterampilan Tim

Sebuah pembangun tim terbaik dapat didefinisikan sebagai orang yang kuat yang memberikan substansi yang memegang tim bersama-sama dalam tujuan umum terhadap tujuan yang tepat. Agar sebuah tim untuk kemajuan dari kelompok asing untuk sebuah unit tunggal yang kohesif, pemimpin harus memahami proses dan dinamika yang diperlukan untuk transformasi ini. Dia juga harus mengetahui gaya kepemimpinan yang sesuai untuk digunakan selama setiap tahap pengembangan tim. Pemimpin juga harus memiliki pemahaman tentang gaya tim pemain yang berbeda dan bagaimana memanfaatkan masing-masing pada waktu yang tepat, untuk masalah di tangan.

10. Keterampilan Memecahkan Masalah

Meskipun seorang pemimpin yang efektif dikatakan untuk berbagi pemecahan masalah tanggung jawab dengan tim, kami berharap para pemimpin proyek kami untuk memecahkan masalah yang sangat baik kemampuan sendiri. Mereka memiliki "segar, respon kreatif untuk sini-dan-sekarang kesempatan," dan keprihatinan tidak banyak dengan bagaimana orang lain telah dilakukan mereka. (Kouzes 1987).

Sumber : 

http://bayduaenam.blogspot.com/2012/06/kreteria-manager-proyek.html 

UNIT TESTING

Unit testing berfokus pad usaha verifikasi pada unit terkecil dari disain software – komponen atau modul software. Penggunaan diskripsi disain tingkat komponen sebagai tuntunan, jalur kendali yang penting dites untuk menemukan errors, terbatas pada modul tersebut. Kompleksitas relatif terhadap tes dan errors yang dicakup dibatasi oleh batasan-batasan dari cakupan yang telah ditetapkan pada unit testing. Unit testing berorientasi white box, dan tahapan dapat dilakukan secara paralel pada banyak komponen. Hal-hal yang perlu diperhatikan pada unit testing : • Tes yang terdapat pada unit testing • Tes aliran data antar modul dibutuhkan sebelum inisialisasi tes lainnya. • Pemilihan jalur eksekusi testing adalah tugas yang esensial selama unit test. • Kesalahan komputasi yang umum terjadi • Komparasi dan alur kendali merupakan satu kesatuan • Batasan testing adalah tugas terakhir dari unit testing • Disain yang baik meliputi kondisi kesalahan yang diantisipasi dan jalur penanganan kesalahan diset untuk dapat digunakan kembali atau proses pembersihan pada terminasi saat kesalahan terjadi. Prosedur-prosedur unit test : • Setelah kode dikembangkan, dan diverifikasi terhadap tingkat disain komponen bersangkutan, disain test case dari unit test dimulai • Review informasi disain menyediakan tuntunan untuk menetapkan test cases agar dapat mendekati keseluruhan cakupan kesalahan di tiap kategori sebagaimana didiskusikan sebelumnya • Tiap test case harus dihubungkan dengan hasil yang diharapkan • Karena komponen bukan program yang berdiri sendiri, drivers dan atau stubs software harus dikembangkan untuk tiap unit test. • Drivers –> program utama yg menerima data test case, memasukkan data ke komponen yg dites dan mencetak hasil yg bersangkutan. • Stubs –> untuk menggantikan modul-modul yg merupakan subordinat (dipanggil oleh) komponen yg dites. Penerapan dari driver dan stubs dapat dilihat pada gambar dibawah ini : Sumber Referensi : http://www.scribd.com/doc/7038740/Unit-Testing http://tutorialpemrograman.wordpress.com/2010/06/02/tutorial-unit-testing-dengan-microsoft-visual-studio-2010-seri-1/

COCOMO

COnstructive COst MOdel (COCOMO)

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

Gambar 1. Jenis-Jenis COCOMO

Jenis-Jenis COCOMO terdiri dari 3 jenis, yaitu : 

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

Model COCOMO dasar ditunjukkan dalam persamaan 1, 2, dan 3 berikut ini: 

 

                                                                                                                                                   (1, 2, 3)

Dimana :

• E : besarnya usaha (orang-bulan)

• D : lama waktu pengerjaan (bulan)

• KLOC : estimasi jumlah baris kode (ribuan)

• P : jumlah orang yang diperlukan.

Sedangkan koefisien ab, bb, cb, dan db diberikan pada Tabel 1 berikut:

Tabel 1 . Koefisien Model COCOMO Dasar 

 

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) 

Masing-masing subkatagori diberi bobot seperti dalam tabel 2 dan kemudian dikalikan. 

Dari pengembangan ini diperoleh persamaan: 

(4)

Dimana :

• E : besarnya usaha (orang-bulan)

• KLOC : estimasi jumlah baris kode (ribuan)

• EAF : faktor hasil penghitungan dari sub-katagori di atas.

Koefisien ai dan eksponen bi diberikan pada tabel berikut.

Tabel 3. Koefisien Model COCOMO Lanjut 

1. Persamaan Perangkat Lunak

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

Persamaan berikut ini diperoleh dari hasil pengamatan terhadap lebih dari 4000 proyek perangkat lunak : 

                                                                                                                                                     (5)

Dimana :

• E = usaha yang dilakukan (orang-bulan atau orang-tahun)

• t = durasi proyek dalam (bulan atau tahun)

• B = faktor kemampuan khusus

• P = parameter produktivitas 

Nilai B diambil berdasarkan perkiraan. Untuk program berukuran kecil (0.5 < KLOC < 5), B = 0.16. Untuk program yang lebih besar dari 70 KLOC, B = 0.39.

Sedangkan besarnya nilai P merefleksikan:

1. Kematangan proses dan praktek manajemen

2. Kualitas rekayasa perangkat lunak

3. Tingkat bahasa pemrograman yang digunakan

4. Keadaan lingkungan perangkat lunak

5. Kemampuan dan pengalaman tim pengembang

6. Kompleksitas aplikasi

Berdasarkan teori, diperoleh P = 2000 untuk sistem terapan, P = 10000 untuk perangkat lunak pada sistem informasi dan sistem telekomunikasi, dan P = 28000 untuk sistem aplikasi bisnis.

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. 

Tabel 4. COCOMO II Early Design Effort Multipliers

 

Tabel 5. COCOMO II Post Architecture Effort Multipliers 

 

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 Referensi :

http://www.scribd.com/doc/81758764/Tugas-COCOMO

http://girlycious09.wordpress.com/2012/04/07/constructive-cost-model-cocomo/

http://ranggaadhityap.blogspot.com/2012/04/pengertian-cocomo-cocomo-adalah.html