Keuntungan Dan Kerugian Open Source

Penggunaan open source belakangan ini semakin popular saja. Namun, open source ini memliki keuntungan dan kerugian.

Beberapa keuntungan :

1. Adanya hak untuk mendistribusikan modifikasi dan perbaikan pada code.
2. Ketersediaan source code dan hak untuk memodifikasi
3. Tidak disandera vendor.
   Open source menggunakan format data terbuka, sehingga data menjadi transparan dan bisa dengan bebas diproses di sistem komputer yang berbeda-beda, sambil tetap menjaga keamananya. Dengan demikian, konsumen tidak lagi terikat pada kemauan vendor untuk dapat menggunakan data-datanya.
4. Banyaknya tenaga (SDM) untuk mengerjakan proyek.
   Proyek open source biasanya menarik banyak developer, misalnya: pengembangan web server Apache menarik ribuan orang untuk ikut mengembangkan dan memantau.
5. 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 tersedia membuat setiap orang dapat mengusulkan perbaikan tanpa harus menunggu dari vendor.
6. Kualitas produk lebih terjamin.
   Hal ini dikarenakan evaluasi dapat dilakukan oleh banyak orang, sehingga kualitas produk dapat lebih baik. Namun, hal ini hanya berlaku untuk produk open source yang ramai dikembangkan orang. Tidak selamanya open source dikembangkan oleh banyak orang, karena bisa juga dilakukan oleh individual.
7. Lebih aman (secure).
   Sifatnya yang terbuka membuat produk open source dapat dievaluasi oleh siapa pun. Public scrutinity merupakan salah satu komponen penting dalam bidang keamanan. Secara umum, open source memiliki potensi untuk lebih aman meskipun dia tidak terkendali secara otomatis. Namun, hal ini dapat tercapai, jika security by obscurity bukan tujuan utamanya.
8. Hemat biaya.Sebagian besar developer ini tidak dibayar/digaji.
   Dengan demikian, biaya dapat dihemat dan digunakan untuk pengeluaran yang tidak dapat ditunda, misal membeli server untuk hosting web.
9. Tidak mengulangi development.
   Pengulangan (re-inventing the wheel) merupakan pemborosan. Adanyasource code yang terbuka membuka jalan bagi seseorang programmer untuk melihat solusi-solusi yang pernah dikerjakan oleh orang lain. Namun, pada kenyataannya tetap banyak pengulangan.
10. User dapat membuat salinan tak terbatas, menjual atau memberikan bebas hasil lisensi.
11. User dapat memodifikasi dan mengunci agar hanya kalangan terbatas yang dapat membaca kode dan memodifikasinya.
12. Mencegah software privacy yang melanggar hukum.

Beberapa kerugian :

1. Kurangnya SDM yang dapat memanfaatkan open source.
   Ketersediaan source code yang diberikan dapat menjadi sia-sia, jika SDM yang ada tidak dapat menggunakannya. SDM yang ada ternyata hanya mampu menggunakan produk saja, Jika demikian, maka tidak ada bedanya produk open source dan yang propriertary dan tertutup.
2. Tidak adanya proteksi terhadap HaKI.
   Kebanyakan orang masih menganggap bahwa open source merupakan aset yang harus dijaga kerahasiannya. Hal ini dikaitkan dengan besarnya usaha yang sudah dikeluarkan untuk membuat produk tersebut. Karena sifatnya dapat di-abuse oleh orang-orang untuk mencuri ide dan karya orang lain.
3. Kesulitan dalam mengetahui status project.
4. Tidak ada garansi dari pengembangan.
5. Limitasi modifikasi oleh orang – orang tertentu yang membuat atau memodifikasi sebelumnya.
6. Untuk beberapa platform, contohnya JAVA yang memiliki prinsip satu tulis dan bisa dijalankan dimana saja, akan tetapi ada beberapa hal dari JAVA yang tidak competible dengan platform lainnya. Contohnya J2SE yang  SWT – AWT bridge–nya belum bisa dijalankan di platform Mac OS.
7. Open Source digunakan secara sharing, dapat menimbulkan resiko kurangnya diferensiasi antara satu software dengan yang lain, apabila kebetulan menggunakan beberapa Open Source yang sama.

KRITERIA MANAJER PROYEK YANG BAIK

KRITERIA MANAJER PROYEK YANG BAIK

Manajer Proyek (Project Manager (PM)) merupakan posisi pertama yang harus ada pada sebuah tim proyek. Seorang Manajer Proyek yang menentukan apakah sebuah proyek dapat dikerjakan atau tidak. Seorang manajer Proyek harus memiliki kemampuan berkomunikasi yang baik, memiliki pengetahuan tentang manajemen proyek kemampuan berorganisasi dan keahlian teknik. Adapun kriteria-kriteria yang harus dimiliki seorang manajer proyek, adalah sebagai berikut:

• Menginsipirasi Visi Bersama

Seorang Manajer Proyek harus memiliki visi ke mana harus pergi untuk mengartikan visi tersebut. Pemimpin yang visioner dapat memungkinkan seseorang untuk merasa bahwa mereka memilik kepentingan yang nyata, serta pemimpin yang seperti itu dapat memberikan visi dan semangat untuk berubah kepada bawahannya.

• Pembicara Yang Baik

Seorang Manajer Proyek harus memiliki kemampuan untuk berkomunikasi dengan orang-orang di semua tingkatan (dengan atasan maupun bawahan). Pemimpin harus memiliki kemampuan untuk secara efektif bernegosiasi dan menggunakan persuasi bila diperlukan untuk memastikan keberhasilan tim dan project yang dikerjakan.

• Kepemimpinan

Salah satu hal yang paling penting pada seorang pemimpin proyek ialah tindakannya bukan kata-kata untuk mengatur modus operandi untuk tim.

• Antusiasme

Seorang bawahan ingin memiliki pemimpin dengan antusias, dengan sikap bisa melakukan.

• Empati

Seorang manajer proyek harus memiliki empati kepada bawahannya, karena seorang manajer proyek harus mengakui bahwa kita semua memiliki kehidupan di luar pekerjaan.

• Kompetensi

Sebagai manajer proyek harus memiliki kemampuan untuk memimpin orang lain bukan pada keahlian teknis.

• Kemampuan untuk Mendelegasikan Tugas

Seorang manajer proyek harus dapat melakukan tindakat seperti memeriksa dan mengontrol pekerjaan, dan seberapa banyak anda mendelegasikan tugas seseorang untuk berpartisipasi.

• Tenang di Bawah Tekanan

Seorang Manajer Proyek harus bisa bekerja walaupun sedang berada di bawah tekanan, dan bisa bersikap tenang menghadapi masalah yang sedang dihadapi.

• Membangun Keterampilan tim

Manajer proyek merupakan seseorang yang kuat dalam memberikan substansi yang memegang tim bersama-sama dalam tujuan umum terhadap tujuan yang tepat.

• Memiliki Keterampilan dalam Memecahkan Masalah

Seorang Manajer Proyek harus memiliki kemampuan dalam memecahkan suatu masalah yang dihadapi oleh tim.

Demikianlah kriteria-kriteria yang harus dimiliki oleh Seorang Manajer Proyek dalam memimpin sebuah tim demi tercapainya visi atau tujuan tim. #SemogaBermanfaat

COCOMO (Constructive Cost Model)

A. Sejarah COCOMO (Constructive Cost Model)
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.

B. Pengertian COCOMO (Constructive Cost Model)
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.
Cocomo adalah model konstruktif biaya dan dikembangkan di TRW / Northrop-Grumman pada tahun 2002. Cocomo merupakan suatu model parametris pengestimasian yang menghitung jumlah FP dalam perencanaan serta pengembangan perangkat lunak. Satu hasil observasi yang paling penting dalam model ini adalah bahwa motivasi dari tiap orang yang terlibat ditempatkan sebagai titik berat.

C. Jenis-jenis COCOMO (Constructive Cost Model)

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:

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

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)
 Reliabilitas perangkat lunak yang diperlukan (RELY)
 Ukuran basis data aplikasi (DATA)
 Kompleksitas produk (CPLX)

b. Atribut perangkat keras (computer attributes)
 Waktu eksekusi program ketika dijalankan (TIME)
 Memori yang dipakai (STOR)
 Kecepatan mesin virtual (VIRT)
 Waktu yang diperlukan untuk mengeksekusi perintah (TURN)

c. Atribut sumber daya manusia (personnel attributes)
 Kemampuan analisis (ACAP)
 Kemampuan ahli perangkat lunak (PCAP)
 Pengalaman membuat aplikasi (AEXP)
 Pengalaman penggunaan mesin virtual (VEXP)
 Pengalaman dalam menggunakan bahasa pemrograman (LEXP)

d. Atribut proyek (project attributes)
 Penggunaan sistem pemrograman modern(MODP)
 Penggunaan perangkat lunak (TOOL)
 Jadwal pengembangan yang diperlukan (SCED)

Masing-masing subkatagori diberi bobot seperti dalam tabel 2 dan kemudian dikalikan.
Dari pengembangan ini diperoleh persamaan:

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

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.

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

E. Pengembangan model COCOMO
Pengembangan model COCOMO adalah dengan menambahkan atribut yang dapat menentukan jumlah biaya dan tenaga dalam pengembangan perangkat lunak, yang dijabarkan dalam kategori dan subkategori sebagai berikut: 1. Atribut produk
a. Reliabilitas perangkat lunak yang diperlukan
b. Ukuran basis data aplikasi
c. Kompleksitas produk

2. Atribut perangkat keras
a. Performa program ketika dijalankan
b. Memori yang dipakai
c. Stabilitas mesin virtual
d. Waktu yang diperlukan untuk mengeksekusi perintah

3. Atribut Sumber Daya Manusia
a. Kemampuan analisis
b. Kemampuan ahli perangkat lunak
c. Pengalaman membuat aplikasi 

d. Pengalaman menggunakan mesin virtual 

e. Pengalaman dalam menggunakan bahasa pemrograman 

4. Atribut proyek 

a. Menggunakan perangkat lunak tambahan 

b. Metode rekayasa perangkat lunak 

c. Waktu yang diperlukan