Image and video hosting by TinyPic

Java Community Process

Sejarah JCP
Java Community Process mungkin organisasi yang paling penting dalam dunia perangkat lunak Java, dengan kemungkinan pengecualian dari Sun Microsystems itu sendiri.Bahkan JCP, yang membantu menentukan masa depan Jawa dengan mengembangkan teknologi Java baru spesifikasi dan referensi implementasi, hampir tidak terpisah dari Sun.Sponsor perusahaan organisasi dengan membayar gaji para staf, dan memberikan pengaruh yang besar atas kerja dalamnya.
 

The JCP didirikan oleh Sun Microsystems pada tahun 1998.Selama dekade terakhir perusahaan telah melepaskan kontrol atas JCP, tetapi para pengecam mengatakan itu tidak cukup.Banyak di masyarakat Jawa percaya bahwa Sun mengejar kepentingan komersial sendiri tidak sesuai dengan tujuan membina sebuah lingkungan kolaboratif yang hanya bertujuan untuk meningkatkan teknologi Java.
 

Beberapa telah menyerukan perubahan yang lebih mendasar pemerintahan dari JCP, atau mengusulkan agar JCP harus dibebaskan dari Sun sama sekali.
 

Lain mengatakan bahwa Sun tidak mampu melepaskan kendali atas badan standar Jawa, dan bahwa kepemimpinan JCP membutuhkan lebih banyak dari Sun, tidak kurang.
Mendemokrasikan JCP
 

Ada dua pokok kritik, salah satunya adalah bahwa Sun memiliki terlalu banyak pengaruh, dan yang lainnya adalah bahwa organisasi ini terlalu rahasia,” kata Patrick Curran, ketua JCP.
 

Meskipun ia adalah karyawan Sun, Curran mengatakan ia melakukan yang terbaik untuk memajukan kepentingan masyarakat daripada Sun.Dia membela Sun peran penting dalam JCP sementara mengakui bahwa ia ingin kelompok untuk menjadi lebih “terbuka, demokratis, dan egaliter”.Kedepan nya, Curran mengharapkan JCP revisi ke model pemerintahan yang akan menambah transparansi dan menciptakan lebih tingkat lapangan bermain.
The reformer Pembaharu
 

Patrick Curran JCP Ketua baru-baru ini berbicara dengan JavaWorld tentang proses standar JCP, tantangan yang dihadapi JCP, dan bagaimana ia percaya mereka dapat tetap: Dengarkan podcast.
 

Meskipun kritik, Sun eksekutif Jeet Kaul mengatakan JCP adalah salah satu badan standar lebih baik ia telah berpartisipasi dalam, terutama karena melibatkan perusahaan dalam persaingan pasar langsung dengan satu sama lain.
 

“Satu-satunya peran yang kita mainkan adalah mencoba untuk memastikan ada kesepakatan dan hal-hal yang bergerak maju,” kata Kaul, Senior Vice President of client software di Sun. “Kompatibilitas adalah tanda dari apa yang kita inginkan. Jika anda memiliki versi yang berbeda 7.000 Jawa itu tidak memiliki nilai di pasaran saat ini. Itu akan menyakiti orang yang sama yang mengeluh.”
Project Harmony Proyek Harmony
 

Yang paling terkenal mungkin JCP kontroversi adalah satu-satunya yang melibatkan Apache Software Foundation, yang menuduh Sun menolak untuk memberikan izin itu yang dapat diterima untuk open source yang disebut implementasi Java SE Harmony.Menurut Geir Magnusson, Apache perwakilan ke JCP, lisensi Minggu itu menawarkan akan “membatasi kebebasan pengguna [dari Apache Harmony] telah menggunakan kembali perangkat lunak, apakah itu untuk mendistribusikan atau membuat karya turunan.”
 

Magnusson adalah marah bahwa Sun memegang kekuasaan untuk lisensi teknologi Java, mengatakan bahwa Apache harus dapat melakukan apa pun yang dipilihnya selama pelaksanaannya kompatibel dengan spesifikasi JCP yang disetujui.
 

Tapi aturan saat ini telah disetujui oleh anggota komite eksekutif JCP pada umumnya, bukan oleh Sun sendiri, Curran catatan.
 

Apache on 23 Februari melemparkan satu-satunya suara tidak setuju terhadap Java EE 6 spesifikasi, dan mengatakan itu bentuk protes terhadap sikap Sun pada Java SE lisensi.”Kami percaya bahwa anggota JCP yang tidak sesuai dengan isi dan semangat dari aturan-aturan yang mengatur seharusnya tidak diperbolehkan untuk memimpin JSRs,” Apache komentar.
 

Kaul menuduh Apache menginginkan sebuah “lisensi yang bebas” di mana siapa saja yang menggunakan kode Apache “bisa melakukan apa saja dengan Jawa yang mereka inginkan.”Pada suatu titik, pendekatan semacam itu akan menghancurkan kemampuan Sun untuk menghasilkan uang, katanya.

Curran mengatakan sengketa dapat menjelaskan masalah dengan Java Specification Participation Agreement (JSPA), sebuah dokumen hukum yang masing-masing anggota JCP harus masuk ke dalam dengan Sun. “Jika ada cukup ambiguitas dalam dokumen JSPA pengacara mahal sehingga dapat tidak sepakat tentang maknanya,” katanya, “kita perlu memperbaikinya sehingga jelas dan tidak ambigu dan mengungkapkan apa yang kita inginkan untuk mengungkapkan.”
 

SELENGKAP'y >> https://docs.google.com/file/d/0BzbO9wa_piOMZXNxcUh2UWZ4MmM/edit

Postest Kendali Audit SI

1. Integritas Sistem
a. Ketersediaan dan kesinambungan sistem komputer untuk user
b. Kelengkapan, Keakuratan, Otorisasi, serta proses yg auditable
c. Persetujuan dari user atas kinerja sistem yang di inginkan
d. Preventive maintenance agreements untuk seluruh perlengkapan
e. Kesesuaian kinerja antara S/W dan jaringan dengan yang diharapkan
f. Serta adanya program yang disusun untuk operasi secara menyeluruh

2. Manajemen Sumber Daya
a. Faktor-faktor yang melengkapi integritas sistem
b. Yaitu meyakini kelangsungan (ongoing) H/W, S/W, SO, S/W aplikasi, dan komunikasi jaringan komputer, telah di pantau dan dikelola pada kinerja yang maksimal namun tetap dengan biaya yang wajar.
c. Hal-hal tersebut di dokumentasikan secara formal, demi proses yang berkesinambungan
 
3. Pengendalian Perubahan S/W Aplikasi dan S/W sistem
a. Menentukan adanya keterlibatan dan persetujuan user dalam hal adanya perubahan terhadap s/w aplikasi dan s/w sistem
b. Setiap pengembangan dan perbaikan aplikasi harus melalui proses formal dan di serta telah melalui tahapan-tahapan pengembangan sistem yang dibakukan dan disetujui.
 
4. Backup dan Recovery
a. Demi kelangsungan usaha, harus tersedia data processing disaster recovery planning (rencana pemulihan data dan pusat sistem informasi apabila terjadi kehancuran),
b.Baik berupa backup dan pemulihan normal, maupun rencana contingency untuk kerusakan pusat SI (lokasi gedung, peralatanya, SDM-nya maupun manualnya).
 
5. Contigency Planning
a. Perencanaan yang komprehenshif di dalam mengantisipasi terjadinya ancaman
b. terhadap fasilitas pemrosesan SI
c. Dimana sebagian besar komponen utama dari disaster recovery plan telah
dirumuskan dengan jelas, telah di koordinasikan dan disetujui, seperti critical
application systems, identifikasi peralatan dan fasilitas penunjang H/W, sistem S/W dan sebagainya.
 
6. System S/W Support
a. Pengukuran pengendalian dalam pengembangan, penggunaan, dan pemeliharaan dari S/W SO, biasanya lebih canggih dan lebih cepat perputarannya dibandingkan dengan S/W aplikasiDengan ketergantungan yang lebih besar kepada staf teknik untuk integritas fungsionalnya
b. Pengukuran kendali pengamanan aplikasi individu maupun pengamanan logika sistem secara menyeluruh (systemwide logical security) 

7. Dokumentasi
a. Integritas dan ketersediaan dokumen operasi, pengembangan aplikasi, user dan S/W sistem
b. Diantaranya dokumentasi program dan sistem, buku pedoman operasi dan schedule operasi,
c. Untuk setiap aplikasi sebaiknya tersedia dokumentasi untuk tiap jenjang user.

8. Pelatihan atau Training
a. Adanya penjenjagan berdasarkan kemampuan untuk seluruh lapisan manajemen dan staf, dalam hal penguasaannya atas aplikasi-aplikasi dan kemampuan teknisnya
b. Serta rencana pelatihan yang berkesinambungan

9. Administrasi
a. Struktur organisasi dan bagannya, rencana strategis, tanggungjawab fungsional, job description, sejalan dengan metoda job accounting dan/atau charge out yang digunakan
b. Termasuk didalamnya pengukuran atas proses pengadaan dan persetujuan untuk semua sumber daya SI.

10. Pengendalian Lingkungan dan Keamanan Fisik
a. Listrik, peyejuk udara, penerang ruangan, pengaturan kelembaban, serta kendali akses ke sumber daya informasi
b. Pencegahan kebakaran, ketersediaan sumber listrik cadangan,
c. Juga pengendalian dan backup sarana telekomunikasi

11. Operasi
a. Diprogram untuk merespon permintaan/keperluan SO
b. Review atas kelompok SO berdasarkan job schedulling, review yang terus-menerus terhadap operator, retensi terhadap console log message, dokumentasi untuk run/restore/backup atas seluruh aplikasi
c. Daftar personel, dan nomor telepon yang harus dihubungi jika muncul masalah SO, penerapan sistem sift dan rotasi serta pengambilan cuti untuk setiap operator.

12. Telekomunikasi
a. Review terhadap logical and physical access controls, 
b. Metodologi pengacakan (encryption) terhadap aplikasi electronic data interchange (EDI)
c. Adanya supervisi yang berkesinambungan terhadap jaringan komputer dan
komitmen untuk ketersediaan jaringan tersebut dan juga redundansi saluran
telekomunikasi.

13. Program Libraries
a. Terdapat pemisahan dan prosedur pengendalian formal untuk application source code dan compiled production program code dengan yang disimpan di application test libraries development
b. Terdapat review atas prosedur quality assurance.
 
14. Application Support
a. Bahwa proses tetap dapat berlangsung walaupun terjadi kegagalan sistem
b. Sejalan dengan kesinambungan proses untuk inisiasi sistem baru, manajemen
c. , proses pengujian yang menyeluruh antara user dan staf SI
d. Adanya review baik formal maupun informal terhadap tingkat kepuasan atas 
SDLC yang digunakan.
 
15. Microcomputer Controls
a. Pembatasan yang ketat dalam pengadaan, pengembangan aplikasi, dokumentasi atas aplikasi produksi maupun aplikasi dengan misi yang kritis, sekuriti logika, dan fisik terhadap microcomputer yang dimiliki,
b. Serta pembuatan daftar inventaris atas H/W, S/W, serta legalitas dari S/W untuk menghindari tuntutan pelanggaran hak cipta.