Minggu, 26 April 2015

Kode Etik Seorang Database Administrator



Seorang database administrator (DBA) adalah orang yang bertanggung jawab untuk mendesain, implementasi, pemeliharaan dan perbaikan database. DBA sering disebut juga database koordinator database programmer, dan terkait erat dengan database analyst, database modeler, programmer analyst, dan systems manager. Peran DBA mencakup pengembangan dan desain strategi database, pemantauan dan meningkatkan kinerja dan kapasitas database, dan perencanaan kebutuhan pengembangan di masa depan. DBA mungkin juga merencanakan, mengkoordinasi dan melaksanakan langkah-langkah keamanan untuk menjaga database. Suatu perusahaan mungkin mengharuskan seorang DBA memiliki sertifikasi atau gelar untuk  sistem database (misalnya, Microsoft Certified Database Administrator).
Peran Database Administrator meningkat berdasarkan database dan proses yang dikelola dan kemampuan dari database management system (DBMS). Skill yang harus dimiliki seorang DBA :
  • Backup Recovery
  • Database Security
  • Availibilty Management
  • Database Performance Tuning
  • Integrity of Data
  • Developer Assistant
Untuk dapat melaksanakan tugasnya dengan baik, seorang DBA harus memiliki kemampuan sebagai berikut :
  • Memiliki pengetahuan mengenai database yang digunakan, termasuk juga tools dan utilities-nya.
  • Memiliki pemahaman mengenai design database
  • Memiliki kemampuan tuning dan monitoring terhadap database
  • Memiliki kemampuan backup dan recovery
  • Memiliki pengetahuan mengenai security management
  • Kemampuan dasar seorang IT-Pro harus dimilki
  • Kemampuan komunikasi, teamwork, dan negosiasi
  • Kemampuan problem-solving dan analytical yang bagus
  • Familiar dengan bahasa manipulasi utama dan prinsip dari perancangandatabase
  • Fleksibilitas dan adaptabilitas
  • Kemampuan organisasional yang bagus
  • Mampu untuk bekerja dibawah tekanan pada deadline yang sempit
  • Business awareness dan mengerti keperluan bisnis dari IT
  • Kemauan untuk tetap up to date dengan perkembangan teknologi baru
  • Komitmen untuk melanjutkan professional development
  • Mengerti perundang-undangan informasi, contoh Data Protection Act
 Hal-hal yang harus di patuhi sebagai DBA(database administrator):
·        menjaga kerahasiaan data
·        mempunyai sikap yang tegas
·        memberi wewenang kepada pihak tertentu
·        tidak membeberkan informasi kelemahan system
·        tidak mempublikasikan tentang management system

Hal ini yang harus di jaga atau kode etik dari sebuah profesi seorang DBA.agar kerahasiaan sebuah data dapat terjamin dengan baik.walaupun contoh di atas tidak bisa memberi keamanan 100% karna banyak para peretas (cracking) yang mencoba menembus keamanan dari sebuah system database.ini yang juga harus di perhatikan agar tidak mudah dalam memasuki sebuah management system databases. Caranya yang baik agar sebuah system dapat menghalau dari serangan-serangan cracking dll. Dengan mengunakan antivirus yang selalu di update agar ketahanan system dapat terjaga baik.juga menjaga keamanan management system dengan memberikan hak akses yang di bagi-bagikan khusus agar tidak mudah masuk begitu saja ke tempat file-file yang penting dari sebuah management system database.
            Sedangkan pada sumber yang kedua disebutkan ada beberapa tambahan dalam hal-hal yang harus dipatuhi sebagai DBA(database administrator)
1. Mampu menjaga kerahasiaan data
2. Mampu beradaptasi dengan berbagai management system database
3. Memahami jenis data dan mekanismenya
4. Bisa menganalisa suatu management sytem database dengan cara yang baik
5. Mempunyai sikap yang tegas
6. Memberi wewenang kepada pihak tertentu
7. Tidak boleh membeberkan informasi kelemahan system
8. Tidak mempublikasikan tentang management system

Contoh Masalah dalam profesi seorang DBA adalah :

“ada seorang profesi DBA yang bekerja di salah satu perusahaan besar ia di tugaskan untuk ke luar kota dan ia di sana akan mengurusi sebuah cabang dari perusahaan tersebut.tetapi pada saat ia telah tiba di sana ada seseorang yang ia kenal yang bekerja di cabang tersebut ternyata itu teman sewaktu ia kuliah bersama dahulu dan sekarang ia bekerja di satu perusahaan yang sama.pada saat bertemu temannya ini bertanya kepada ia tentang jabatan yang ia dapatkan di perusahaan tersebut ia menjawab seorang DBA dan temannya ini bangga terhadapnya akan tetapi dalam percakapan tersebut temannya ingin mengajak untuk berbisnis dengannya ia di iming-imingi dengan pendapatan yang jauh lebih besar dari tempat yang sekarang ia bekerja.pada saat itulah temanya menanyakan tentang data-data atau file yang  menyangkut tentang perusahaan.karna bisnis yang di tawarkan ini mempunyai maksud untuk menjual aset-aset penting perusahaan agar perusahaan tersebut menjadi tidak mempunyai saingan lagi.setelah di jelaskan ternyata ia ingin mencoba bisnis tersebut dan akhirnya perusahaan pun menjadi rugi besar karna ulah seorang DBA tersebut.”


Solusi Masalah di Atas :

“seorang profesi DBA mempunyai tanggung jawab yang cukup berat terhadap yang ia kerjakan.karna hal-hal semacam itulah yang bersifat rahasia perusahaan yang tidak boleh di publikasikan.karna itu seorang DBA harus mempunyai prinsip yang kuat agar tidak mudah gampang terpengaruh oleh hal-hal yang tidak etis terhadap profesi IT (DBA) dan pihak lainnya.seharusnya di buat sebuah badan yang mengatur tentang kode etik (Hukum) seorang profesi IT (DBA) agar dapat membuat aturan-aturan (kode etik) yang jelas tentang apa saja yang boleh dan tidak boleh di lakukan seorang profesi IT (DBA)  ini juga harus ada peran dari pemerintah sebagai pelaksana dan juga sebagai regulasi dari aturan-aturan tersebut.kasus ini tidak akan terjadi bila pemerintah ikut berpartisipasi dalam memberikan perhatian lebih kepada pekerja IT (DBA) seperti ini dan juga menghargai sekaligus menghormati sebagai seorang pekerja profesi IT (DBA) di indonesia .”




https://ekosuwono.wordpress.com/2010/01/07/database-administrator/

https://yusniaalfisyahrin.wordpress.com/2011/07/09/etika_profesi_dba/

http://hendrasumitro.blogspot.com/2014/01/kode-etik-dan-tanggung-jawab-sebagai.html

Rabu, 15 April 2015

Apa itu 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 :
https://yulandari.wordpress.com/2013/06/29/apa-itu-cocomo/

Kenapa anda dianjurkan menggunakan software open source dalam membuat aplikasi ?



Open Source adalah sistem pengembangan yang tidak dikoordinasi oleh suatu individu / lembaga pusat, tetapi oleh para pelaku yang bekerja sama dengan memanfaatkan kode sumber (source-code) yang tersebar dan tersedia bebas (biasanya menggunakan fasilitas komunikasi internet). Pola pengembangan ini mengambil model ala bazaar, sehingga pola Open Source ini memiliki ciri bagi komunitasnya yaitu adanya dorongan yang bersumber dari budaya memberi, yang artinya ketika suatu komunitas menggunakan sebuah program Open Source dan telah menerima sebuah manfaat kemudian akan termotivasi untuk menimbulkan sebuah pertanyaan apa yang bisa pengguna berikan balik kepada orang banyak.
Pola Open Source lahir karena kebebasan berkarya, tanpa intervensi berpikir dan mengungkapkan apa yang diinginkan dengan menggunakan pengetahuan dan produk yang cocok. Kebebasan menjadi pertimbangan utama ketika dilepas ke publik. Komunitas yang lain mendapat kebebasan untuk belajar, mengutak-ngatik, merevisi ulang, membenarkan ataupun bahkan menyalahkan, tetapi kebebasan ini juga datang bersama dengan tanggung jawab, bukan bebas tanpa tanggung jawab.
Di bawah ini terdapat beberapa keuntungan dan kelemahan pada open source.
Keuntungan open source :
  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 pencarian bugs 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. Adanya source 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.
Kerugian open source :
  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.



Sumber :
https://freezcha.wordpress.com/2011/03/18/keuntungan-dan-kerugian-penggunaan-open-source/
http://id.wikipedia.org/wiki/Sumber_terbuka