Capability Maturity Model (CMM)

·         Pengertian CMM

Capability Maturity Model disingkat CMM  Merupakan mekanisme kualifikasi sebuah software development house yang dapat memberikan gambaran tentang kemampuan perusahaan tersebut dalam melakukan development software. Dalam arti lain, Capability Maturity Model disingkat CMM adalah suatu model kematangan kemampuan (kapabilitas) proses yang dapat membantu pendefinisian dan pemahaman proses-proses suatu organisasi. Pengembangan model ini dimulai pada tahun 1986 oleh SEI (Software Engineering Institute) Departemen Pertahanan Amerika Serikat di Universitas Carnegie Mellon di Pittsburgh, Amerika Serikat.

CMM awalnya ditujukan sebagai suatu alat untuk secara objektif menilai kemampuan kontraktor pemerintah untuk menangani proyek perangkat lunak yang diberikan. Walaupun berasal dari bidang pengembangan perangkat lunak, model ini dapat juga diterapkan sebagai suatu model umum yang membantu pemahaman kematangan kapabilitas proses organisasi di berbagai bidang. Misalnya rekayasa perangkat lunak, rekayasa sistem, manajemen proyek, manajemen risiko, teknologi informasi, serta manajemen sumber daya manusia.

Secara umum, maturity model biasanya memiliki ciri sebagai berikut:

1.    Proses pengembangan dari suatu organisasi disederhanakan dan dideskripsikan dalam wujud tingkatan kematangan dalam jumlah tertentu (biasanya empat hingga enam tingkatan)

2.    Tingkatan kematangan tersebut dicirikan dengan beberapa persyaratan tertentu yang harus diraih.

3.    Tingkatan-tingkatan yang ada disusun secara sekuensial, mulai dari tingkat inisial sampai pada tingkat akhiran (tingkat terakhir merupakan tingkat kesempurnaan)

4.    Selama pengembangan, sang entitas bergerak maju dari satu tingkatan ke tingkatan berikutnya tanpa boleh melewati salah satunya, melainkan secara bertahap berurutan.

·         Definisi Harafiah

1.     Capability : menjadi kapabilitas yang berarti kemampuan yang bersifat laten. Capability lebih mengarah kepada integritas daripada kapabilitas yang  berarti itu sendiri.

2.     Maturity : matang / dewasa . Matang merupakan hasil proses, sedangkan dewasa merupakan hasil dari pertumbuhan.

Model : suatu penyederhanaan yang representatif terhadao keadaan di dunia nyata

·         Tujuan CMM

Tujuan penggunaan CMM adalah membuat ujian saringan masuk BAGI KONTRAKTOR YANG MENDAFTARKAN DIRI UNTUK MENJADI KONSULTAN.

·         Nilai-nilai yang dilihat dalam pengukuran CMM

1.     Apa yang diukur ( parameter )

2.     Bagaimana cara mengukurnya ( metode )

3.     Bagaimana standar penilaiannya ( skala penilaian )

4.     Bagaimana interpretasinya ( bagi manusia )

·         Kegunaan CMM

1.     Untuk menilai tingkat kematangan sebuah organisasi pengembang perangkat lunak.

2.     Untuk menyaring kontraktor yang akan menjadi pengembang perangkat lunak

3.     Untuk memberikan arah akan peningkatan organisasi bagi top management di dalam sebuah organisasi pengembang perangkat lunak.

4.     Sebagai alat bantu untuk menilai keunggulan kompetitif yang dimiliki sebuah perusahaan dibandingkan perusahaan pesaingnya.

·         Tahapan dalam CMM

Tahapan dalam CMM

1.     Initial Level

Level ini hiasa disebut anarchy atau chaos. Pada pengembangan sistem ini masing – masing developer menggunakan peralatan dan metode sendiri. Berhasil atau tidaknya tergantung dari project teamnya. Project ini seringkali menemukan saat – saat krisis, kadang kelebihan budget dan di belakang rencana. Dokumen sering tersebar dan tidak konsisten dari satu project ke project lainnya. Level initial bercirikan sebagai berikut :

• Tidak adanya manajemen proyek
• Tidak adanya quality assurance
• Tidak adanya mekanisme manajemen perubahan (change management)
• Tidak ada dokumentasi
• Adanya seorang guru/dewa yang tahu segalanya tentang perangkat lunak yang dikembangkan.
• Sangat bergantung pada kemampuan individual

2.     Repeatable level

Proses project management dan prakteknya telah membuat aturan tentang biaya projectnya, schedule, dan funsionalitasnya. Fokusnya adalah pada project management bukan pada pengembangan sistem. Proses pengembangan sistem selalu diikuti, tetapi akan berubah dari project ke project. Sebuah konsep upaya dibuat untuk mengulang kesuksesan project dengan lebih cepat. Level Repeatable bercirikan sebagai berikut :

• Kualitas perangkat lunak mulai bergantung pada proses bukan pada orang
• Ada manajemen proyek sederhana
• Ada quality assurance sederhana
• Ada dokumentasi sederhana
• Ada software configuration managemen sederhana
• Tidak adanya knowledge managemen
• Tidak ada komitment untuk selalu mengikuti SDLC dalam kondisi apapun
• Tidak ada statiskal control untuk estimasi proyek
• Rentan terhadap perubahan struktur organisasi.

3.      Defined level

Standard proses pengembangan sistem telah dibeli dan dikembangkan dan ini telah digabungkan seluruhnya dengan unit sistem informasi dari organisasi. Dari hasil penggunaan proses standard, masing – masing project akan mendapatkan hasil yang konsisten dan dokumentasi dengan kualitas yang baik dan dapat dikirim. Proses akan bersifat stabil, terprediksi, dan dapat diulang. Level Defined bercirikan :

• SDLC sudah dibuat dan dibakukan
• Ada komitmen untuk mengikuti SDLC dalam keadaan apapun
• Kualitas proses dan produk masih bersifat kwalitatif bukan kualitatif (tidak terukur hanya kira-kira saja)

•Tidak menerapkan Activity Based Costing
• Tidak ada mekanisme umpan balik yang baku

4.     Managed level

Tujuan yang terukur untuk kualitas dan produktivitas telah dibentuk. Perhitungan yang rinci dari standard proses pengembangan sistem dan kualitas produk secara rutin akan dikumpulkan dan disimpan dalam database. Terdapat suatu usaha untuk mengembangkan individual project management yang didasari dari data yang telah terkumpul. Level Managed bercirikan :

• Sudah adanya Activity Based Costing dan dan digunakan untuk estimasi untuk proyek berikutnya
• Proses penilaian kualitas perangkat lunak dan proyek bersifat kuantitatif.
• Terjadi pemborosan biaya untuk pengumpulan data karena proses pengumpulan data masih dilakukan secara manual
• Cenderung bias. Ingat efect thorne, manusia ketika diperhatikan maka prilakunya cenderung berubah.
• Tidak adanya mekanisme pencegahan defect
• Ada mekanisme umpan balik

5.     Optimized level

Proses pengembangan sistem yang distandardisasi akan terus dimonitor dan dikembangkan yang didasari dari perhitungan dan analisis data yang dibentuk pada level 4. Ini dapat termasuk perubahan teknologi dan praktek – praktek terbaik yang digunakan untuk menunjukkan aktivitas yang diperlukan pada standard proses pengembangan sistem . Level Optimized bercirikan :

• Pengumpulan data secara automatis
• Adanya mekanisme pencegahan defect
• Adanya mekanisme umpan balik yang sangat baik
• Adanya peningkatan kualitas dari SDM dan peningkatan kualitas proses.