SEKOLAH TINGGI TEKNOLOGI INFORMASI NIIT ITECH

Program Studi : TEKNIK INFORMATIKA Nama : Atika Juliana NIM: 421031053

Capability Maturity Model for Software (CMM-SW)

Seiring dengan perkembangan zaman, maka kebutuhan piranti lunak akan semakin tinggi. Di sisi lain dengan semakin terbukanya pasar bebas, mendorong pengembang piranti lunak dalam negeri harus bisa bersaing dengan pengembang piranti lunak luar negeri. Pasar pasti akan memiliki piranti lunak yang berkualitas, karena akan sangat berpengaruh pada bisnis mereka. Bagi pasar, baik atau tidaknya kualitas sebuah piranti lunak, akan mereka lihat dari sejauh mana penerapan Capability Maturity Model for Software (CMM-SW) pada pengembang piranti lunak yang bersangkutan. Secara umum, pasar tidak begitu memahami secara mendalam tentang bagaimana kualitas piranti lunak yang baik itu. Oleh karena itu, dalam menilai kualitas sebuah produk piranti lunak, pasar akan menilainya secara pragmatis, salah satunya yaitu dengan melihat sejauh mana penerapan CMM-SW pada organisasi piranti lunak yang bersangkutan. Semakin tinggi level penerapan CMM-SW-nya, maka dipastikan akan semakin baik kualitas produksinya. CMM adalah sebuah penyederhanaan yang representatif yang digunakan untuk mengukur tingkat kematangan sebuah software development house dalam menyajikan/membuat/mengembangkan perangkat lunak sebagaimana telah dijanjikan secara tertulis dalam perjanjian kerja sama. Capability Maturity Model membuat 5 level/skala kematangan yaitu : Level 1: Initial. 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. Hanya sedikit dari proses yang telah didefinisikan dengan jelas, dan kesuksesan tergantung pada usaha individu. Semua pengembang piranti lunak minimal sudah pasti ada pada level ke-1 ini.

Level 2: Repeatable. 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. Sudah mulai banyak perusahaan-perusahaan pengembang piranti lunak di Indonesia yang telah mencapai CMM level 2 ini. Manajemen proyek sederhana yang digunakan salah satunya adalah dengan membuat timeline atau diagram gant chart yang menggambarkan aktivitas pengembangan proyek. Adanya testing perangkat lunak dengan metode black box dan white box untuk memastikan perangkat lunak berjalan dengan baik. Pembuatan dokumentasi user guide atau dokumentasi yang menggambarkan business process aplikasi yang akan menjadi panduan dalam pengembangan software. Akan tetapi, perusahaan tersebut tidak selalu mengikuti SDLC. Sering kali terjadi diagram UML yang mengikuti prosess development piranti lunak, dimana programmer membuat piranti lunak terlebih dahulu sebelum membuat dokumentasi business process, atau bisa juga kita kenal sebagai xtream programmer.

Level 3: Defined. 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 kirakira saja) Tidak menerapkan Activity Based Costing Tidak ada mekanisme umpan balik yang baku Pada level ini, pengembangan piranti lunak untuk manajemen dan aktivitas rekayasa telah didokumentasikan dengan baik, distandarisasikan, dan diintegrasikan dalam sebuah standar Software Process untuk organisasi yang bersangkutan. Semua proyek menggunakan standarisasi Software Process milik organisasi yang telah disetujui dan disesuaikan, untuk membangun dan memelihara piranti lunak.

Level 4: Managed. 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 Pada level ini, ukuran-ukuran mendetail dari Software Process dan kualitas produksi telah dimiliki. Software process dan produksi secara kuantitatif sudah dipahami dan dapat dikontrol.

Level 5: Optimizing. Pengumpulan data secara automatis Adanya mekanisme pencegahan defect Adanya mekanisme umpan balik yang sangat baik Adanya peningkatan kualitas dari SDM dan peningkatan kualitas proses. Peningkatan proses secara kontinyu diberlakukan dengan feedback kuantitatif dari proses tersebut, dan dari teknologi-teknologi serta ide-ide yang inovatif. Secara umum, kelima level diatas merupakan gambaran adanya suatu tahapan dalam upaya untuk meningkatkan kualitas piranti lunak. Setiap level harus dilalui secara sekuensial. Tidak bisa melakukan lompatan-lompatan ke level atas, sebelum menerapkan CMM-SW pada level dibawahnya. Di sini dapat dilihat bahwa usaha peningkatan kualitas tersebut dilakukan dengan berorientasi kepada peningkatan proses.