CAPABILITY MATURITY MODEL INTEGRATION

A. PENGERTIAN CMMI
	1.	Definisi
		Capability Maturity Model Integration atau CMMI (Integrasi Model Kematangan Kemampuan) adalah suatu pendekatan perbaikan proses yang memberikan unsur-unsur penting proses efektif bagi organisasi. Praktik-praktik terbaik CMMI dipublikasikan dalam dokumen-dokumen yang disebut model, yang masing-masing ditujukan untuk berbagai bidang yang berbeda. Supintan. Ini adalah kerangka kerja (framework) yang bisa digunakan untuk mengembangkan proses di dalam perusahaan. Saat ini terdapat dua bidang minat yang dicakup oleh model CMMI: development (pengembangan) dan acquisition (akuisisi). Versi terkini CMMI adalah versi 1.2 dengan dua model yang tersedia yaitu CMMI-DEV (CMMI for Development) yang dirilis pada Agustus 2006 dan ditujukan untuk proses pengembangan produk dan jasa, serta CMMI-ACQ (CMMI for Acquisition) yang dirilis pada November 2007 dan ditujukan untuk manajemen rantai suplai, akuisisi, serta proses outsourcing di pemerintah dan industri. Proses adalah cara kita melakukan suatu tugas.Supintan. Misalnya, membuat proposal, menganalisa kebutuhan client, membuat kode program, dan kegiatan lainnya. Semua tata laksana kegiatan tersebut dikenal dengan nama proses atau prosedur. CMMI membantu kita untuk memperbaiki proses di perusahaan/organisasi kita. Dengan membaiknya proses, diharapkan produk yang dihasilkan akan ikut menjadi baik. CMMI dirumuskan oleh Software Engineering Institute di Carnegie Mellon University. Para peneliti di SEI telah mengamati proyek pembangunan perangkat lunak di seluruh dunia, mulai dari proyek kecil sampai proyek raksasa. Organisasi yang diteliti meliputi NASA, IBM, dan kontraktor Departemen Pertahanan Amerika Serikat. Pengalaman yang dimiliki organisasi tersebut dirangkum dalam seperangkat aturan yang disebut CMMI. Nah, apakah perusahaan kita sudah lebih canggih daripada organisasi di atas, dalam hal mengelola proyek software? Kalau belum, mari kita belajar dari mereka. CMMI terdiri dari rangkaian practices.Supintan. Dalam rangkaian practices ini ada rambu-rambu atau rekomendasi yang dapat diikuti. Practices dalam CMMI dibagi menjadi dua, yaitu Generic Practices (GP) dan Specific Practices (SP). Bila kita sudah mengimplementasikan practices dengan sempurna, kita dianggap sudah memenuhi Goals. Sama seperti practices, ada Generic Goals (GG) dan Specific Goals (SG). SG dan SP dikelompokkan menjadi Process Area (PA). Total ada 22 Process Area dalam CMMI for Development versi 1.2 Secara harfiah CMMI diartikan sebagai : Capability : menjadi kapabilitas yang berarti kemampuan yang bersifat laten. Capability lebih mengarah kepada integritas daripada kapabilitas yang berarti itu sendiri. Maturity : matang / dewasa . Matang merupakan hasil proses, sedangkan dewasa merupakan hasil dari pertumbuhan. Model : suatu penyederhanaan yang representatif terhadap keadaan di dunia nyata. Integration : Suatu hubungan timbal balik antara satu dengan yang lainnya dan saling terhubung
	2.	Tujuan
		Untuk menilai tingkat kematangan sebuah organisasi pengembang perangkat lunak. Untuk menyaring kontraktor yang akan menjadi pengembang perangkat lunak. Untuk memberikan arah akan peningkatan organisasi bagi top management di dalam sebuah organisasi pengembang perangkat lunak. Sebagai alat bantu untuk menilai keunggulan kompetitif yang dimiliki sebuah perusahaan dibandingkan perusahaan pesaingnya.
	3.	Sejarah Singkat
		CMMI pada awalnya dikenal sebagai Capability Maturity Model (CMM) yang dikembangkan oleh Software Enginnering Institute di Pittsburgh pada tahun 1987. Tujuan awal dirumuskannya CMMI adalah untuk mendukung proses tender di lingkungan Departemen Pertahanan Amerika Serikat (US-DoD). Mereka ingin memiliki sistem penilaian terhadap semua vendor yang mengajukan proposal. Untuk itu dirumuskanlah sistem penilaian vendor berupa Maturity Level (Maturity Level). Pada tahun 2000 cmm dileburkan ke dalam cmmi . Peleburan ini disebabkan karena adanya kritik bahwa pengaplikasian cmm di pengembangan perangkat lunak khususnya bisa menimbulokan masalah karena model cmm belum terintegrasi di dalam dan di seantero organisasi.
B. PERBEDAAN ISO DAN CMMI
	CMMI dan ISO sama-sama standar yang digunakan untuk menilai proses suatu organisasi. Kalau kita programmer Java, kita punya sertifikasi SCJP, SCWD, SCBCD, dan sebagainya. Nah, anggap saja CMMI atau ISO ini adalah sertifikasinya perusahaan. Kalau di SCJP yang dinilai adalah penguasaan kita terhadap bahasa pemrograman Java, maka di ISO/CMMI yang dinilai adalah penguasaan perusahaan terhadap prosesnya sendiri. Logo : ISO 9001 -2008. Gambar link : http://www.astbearings.com/blog/wp-content/uploads/ISO_Logo-01-web.jpg Perbedaan CMMI dan ISO terletak pada ketelitiannya. Supintan. Bila kita ingin perusahaan kita mendapat sertifikasi ISO, perusahaan kita harus memiliki Standard Operating Procedure (SOP) yang tertulis. Kemudian kita harus membuktikan pada badan sertifikasi bahwa SOP tersebut kita jalankan dengan baik. Apa saja yang kita tulis dalam SOP bebas terserah kita. ISO tidak mengatur sampai ke tingkat itu. Berbeda dengan CMMI, selain kita punya SOP, dia punya aturan khusus tentang isi SOP. Misalnya, kalau kita melakukan analisa kebutuhan (requirement gathering), ada beberapa aturan yang harus diikuti, misalnya : Pernyataan kebutuhan user harus dicatat Pernyataan kebutuhan harus dikonfirmasi ke user Pernyataan kebutuhan harus disetujui kedua pihak Kalau ada perubahan, harus dicatat Antara kebutuhan dan software yang dideliver, harus bisa dilacak bolak-balik
C. MATURITY LEVEL
	Tujuan awal dirumuskannya CMMI sebenarnya adalah untuk mendukung proses tender di lingkungan Departemen Pertahanan Amerika Serikat (US-DoD). Mereka ingin memiliki sistem penilaian terhadap semua vendor yang mengajukan proposal. Untuk itu dirumuskanlah sistem penilaian vendor berupa Maturity Level (ML). Maturity Level di CMMI ada 5, mulai dari yang terendah ML 1, sampai yang paling canggih ML 5. Supintan. Bila perusahaan kita sudah ML-5, maka kita bisa ikut dalam tender proyek software rudal Patriot. Begitu kira-kira. Gambar Level pada CMMI. Link : http://www.modernrequirements.com/wp-content/uploads/2015/06/CMMiiterative-model.jpg Setiap ML memiliki seperangkat PA yang harus dipenuhi agar kita berhak menggunakan titel ML tersebut. Sebagai contoh, bila kita ingin lulus ML-2, maka kita harus mengimplementasikan 7 PA. Untuk mencapai ML-3, kita harus mengimplementasikan 7 PA dari ML-2 ditambah dengan 11 PA dari ML-3. Demikian seterusnya, sehingga ML-5 yang sudah mengimplementasikan 22 PA.
	1.	Maturity level 1 – Initialized
		Pada ML1 ini proses biasanya berbentuk ad hoc. Sukses pada level ini didasarkan pada kerja keras dan kompetensi yang tinggi orang-orang yang ada di dalam organisasi tersebut atau dapat juga dikatakan perusahaan ini belum menjalankan tujuan dan sasaran yang telah didefinisikan oleh CMMI.
	2.	Maturity level 2 – Managed
		Pada ML2 ini sebuah organisasi telah mencapai seluruh specific dan generic goals pada Level 2. Semua pekerjaan yang berhubungan dengan dengan proses-proses yang terjadi saling menyesuaikan diri agar dapat diambil kebijakan. Setiap orang yang berada pada proses ini dapat mengakses sumber daya yang cukup untuk mengerjakan tugas masing-masing. Setiap orang terlibat aktif pada proses yang membutuhkan. Setiap aktivitas dan hasil pekerjaan berupa memonitor, mengontrol, meninjau, serta mengevaluasi untuk menjaga kekonsistenan pada deskripsi yang telah diberikan.
	3.	Maturity level 3 – Defined
		Pada ML3 ini sebuah organisasi telah mencapai seluruh specific dan generic goals pada Level 2 dan Level 3. Proses dicirikan dengan terjadinya penyesuaian dari kumpulan proses standar sebuah organisasi menurut pedoman-pedoman pada organisasi tersebut, menyokong hasil kerja, mengukur, dan proses menambah informasi lain menjadi milik organisasi.
	4.	Maturity level 4 – Quantitatively Managed
		Pada ML4 ini, sebuah organisasi telah mencapai seluruh specific dan generic goals yang ada pada Level 2, 3, dan 4. Proses yang terjadi dapat terkontrol dan ditambah menggunakan ukuran-ukuran dan taksiran kuantitatif. Sasaran kuantitatif untuk kualitas dan kinerja proses ditetapkan dam digunakan sebagai kreteria dalam manajemen proses.
	5.	Maturity level 5 – Optimizing
		Pada ML5 ini suatu organisasi telah mencapai seluruh specific dan generic goals yang ada di Level 2, 3, 4, dan 5. ML5 fokus kepada peningkatan proses secara berkesinambungan melalui inovasi teknologi.
D. PENERAPAN DALAM PERUSAHAAN
	1.	Cara Mendapatkan CMMI
		Pertama, tentunya perusahaan kita harus memenuhi semua persyaratan mulai dari ML-2 sampai ML-5. Perusahaan kita harus sudah punya SOP yang mengatur semua proses sesuai aturan CMMI. Bila ada aturan yang tidak kita pahami, kita bisa datangkan konsultan untuk menjelaskan. Setelah ada SOP tersebut, setiap orang dalam perusahaan harus memahami dan menjalankannya dengan benar. Setelah kita yakin bahwa perusahaan kita mampu, kita mendatangkan appraiser atau auditor untuk memeriksa proses kita. Logo CMMI. Gambar Link : http://www.geo-viz.com/wp-content/uploads/2014/02/cmmi.png Kegiatan appraisal ini disebut dengan SCAMPI. Ada macam-macam SCAMPI, tapi yang berhak mengeluarkan peringkat ML hanyalah SCAMPI Class A. Dalam SCAMPI, Lead Appraiser(LA) akan merekrut beberapa orang dari perusahaan kita untuk membantunya mengaudit. Tim auditor ini disebut Appraisal Team Member (ATM). Perusahaan kita juga juga harus menyediakan tim yang akan diwawancarai oleh ATM, yang disebut dengan Functional Area Representative (FAR). FAR merupakan perwakilan dari berbagai departemen dalam organisasi. Supintan. Mungkin nantinya akan ada kelompok FAR dari procurement, tim project, network administrator, programmer, tester, dan lainnya. ATM dibutuhkan untuk menterjemahkan aturan CMMI ke dalam SOP perusahaan. Misalnya, dalam CMMI ada aturan mengenai analisa kebutuhan, yaitu process area Requirement Management (REQM) dan Requirement Development (RD). Process area ini di perusahaan A mungkin diimplementasikan dengan dokumen Software Requirement Specification (SRS), tapi di perusahaan B mungkin namanya User Requirement Specification (URS), dan di perusahaan C berupa Use Case Diagram dan User Stories. Nah, tugas ATM adalah menjembatani antara istilah CMMI dan istilah internal perusahaan. Wawancara ATM tidak aneh-aneh. Untuk setiap proses area, mereka akan tanya apakah FAR sudah mengimplementasikan. Bila sudah, mana buktinya. Bukti ini bisa berupa hard-copy, bisa juga soft-copy. Kita bisa mengajukan email sebagai evidence. Bahkan kita juga bisa menunjukkan log Subversion atau item bug dalam aplikasi bug tracker. Berdasarkan hasil wawancara FAR oleh ATM, LA akan memutuskan ML berapa yang pantas untuk perusahaan kita.
	2.	Continuous Representation
		Perusahaan mengadopsi CMMI untuk berbagai tujuan. Berikut ini beberapa tujuannya : bermotif marketing, yaitu meraih ML tertentu dengan harapan akan mendapat project dari US-DoD, ataupun simply memperkeren Company Profile. Sama saja dengan kita ambil SCJP. Ada juga yang memang berniat meningkatkan kualitas prosesnya. Mengadopsi CMMI dengan harapan perusahaan akan menjadi lebih baik. Ada beberapa pendekatan untuk mengadopsi CMMI. Kita bisa mengadopsi per ML, misalnya tahun ini ML-3, berikutnya ML-4, dan seterusnya. Atau bisa juga kita hanya memfokuskan perbaikan pada satu process area tertentu saja, misalnya Requirement Management, atau Risk Management. Bila kita berorientasi ML, maka kita mengambil pendekatan Staged Representation. Sedangkan bila kita berorientasi PA, maka kita mengambil pendekatan Continuous Representation.
	3.	CMMI yang sudah diterapkan
		Bagi programmer seperti saya dan Anda, kreativitas dan improvisasi adalah kenikmatan kerja yang utama. Itulah yang membuat kita memilih profesi software developer. Oleh karena itu, wajar bila kita mengkhawatirkan masalah ini. Sebagai programmer yang terlibat dalam project, hal yang paling menyebalkan bagi kita bukanlah kesulitan teknis atau kerumitan algoritma. Semakin sulit, semakin menantang bagi kita. Hal yang paling menyebalkan adalah perubahan requirement di tengah jalan. Atau mungkin tidak se-ekstrim itu. End-user hanya minta geser tombol sedikit, tambah fitur sedikit, dan sedikit-sedikit lainnya, yang lama-lama tentunya akan menjadi bukit. Tiba-tiba, project sudah telat 2 bulan, dan fitur baru 50% terimplementasi. Bukan karena kita codingnya lama, tapi karena user minta perubahan melulu. NASA salah satu contoh perusahaan yang sudah menerapkan CMMI. gambar link : http://cdn4.ceramiassociates.com/wp-content/uploads/2012/08/NASA_Exterior.jpg Nah, urusan perubahan requirement ini wajib hukumnya untuk dikelola dengan baik. Diatur dalam process area Requirement Management (REQM) yang ada di ML-2 dalam SP 1.3. Kalau perusahaan kita mengimplementasi REQM dengan baik, kita sebagai programmer akan lebih tenang hidupnya. Semua perubahan terhadap aplikasi yang sedang dibuat harus melalui rangkaian prosedur untuk memastikan perubahan tersebut benar-benar diinginkan dan sudah dipertimbangkan konsekuensinya. End-user tidak akan semena-mena meminta perubahan, tapi harus melalui persetujuan atasannya dan atasan kita. Dengan demikian, perubahan yang sampai pada programmer sudah pasti adalah perubahan yang penting, bukan hanya menurut end-user, tapi juga menurut sponsor project. Bahkan, adanya prosedur ini saja sudah cukup untuk membatasi liarnya imajinasiend-user.

Share on Google Plus

About muhamad hafiz

This is a short description in the author block about the author. You edit it by entering text in the "Biographical Info" field in the user admin panel.