IT Indonesia dan peluangnya berkaca dari India

Berbicara kondisi industri Teknologi Informasi (TI) atau perangkat lunak di Indonesia berdasarkan sumber informasi yang didapat dari website resmi SDA Asia Magazine indonesia yang berbicara mengenai Benchmarking IT Industry Competitiveness, dimana penelitian mengenai hal tersebut dilakukan oleh Economiest Intellegence Unit dari SDA Asia Magazine Indonesia, yang berupaya untuk membandingkan kinerja negara-negara didunia dalam membangun sebuah lingkungan yang mendukung daya saing TI. Menurut laporan dari Economiest Intellegence Unit bahwa skor indeks keseluruhan indonesia mencapai 23.7. Pencapaian indeks tahun ini, Indonesia dinilai menunjukan kinerja yang lebih baik dalam lingkungan bisnis secara keseluruhan (Urutan ke 51). Sementara itu, Indonesia dinilai paling lemah bila dibandingkan dengan semua negera dalam hal infrastruktur TI dengan menempati urutan ke 64. infrastruktur TI ini meliputi belanja hardware, software dan layanan TI, kepemilikan dekstop dan laptop, koneksi broadband, dan server intranet yang aman. Sebagai perbandingan, untuk skala global mengenai infrastruktur TI ini, Vietnam berada di urutan ke 60, Filipina menempati urutan ke 55, Thailand urutan ke 49, Malaysia berada diurutan 33 dan singapura berada diurutan ke 12. Skor indeks ini secara keseluruhan menyimpulkan bahwa sejumlah negara memiliki semua faktor yang diperlukan untuk mendukung sektor TI agar tumbuh. Melihat skor indeks tersebut dapat dilihat bagaimana daya saing Indonesia dikawasan regional.

Meningkatkan Kualitas Produksi Piranti Lunak Dalam Negeri dengan Menerapkan CMM-SW

ABSTRACT

Saat ini kebutuhan akan adanya piranti lunak disetiap sektor pembangunan, demikian tinggi. Di sisi lain dengan semakin terbukanya keran 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.

Oleh karena itu, pengembang piranti lunak dalam negeri harus bisa meningkatkan kualitas produksinya dengan menerapkan CMM-SW. Penerapan CMM-SW ini bukan semata-mata untuk meningkatkan prestise, tapi lebih kepada peningkatan kualitas produksi piranti lunak.

Kata kunci: Capability Maturity Model for Software (CMM-SW), Piranti Lunak, Software Process

I. PENDAHULUAN

Ada tiga hal yang sangat penting dalam perkembangan teknologi saat ini. Ketiga hal tersebut adalah software (piranti lunak), hardware (piranti keras), dan sumber daya manusia. Ketiga hal ini dipastikan ada di dalam setiap organisasi.

Salah satu hal yang menjadi bahasan utama dalam makalah ini adalah piranti lunak. Piranti lunak sudah menjadi tulang punggung dalam setiap bussiness proses di tiap-tiap organisasi. Seiring dengan kemajuan zaman, maka kebutuhan akan piranti lunak semakin tinggi. Tidak hanya itu, pasar akan semakin jeli dalam memilih piranti lunak yang akan digunakan dalam organisasinya. Piranti lunak yang mereka pilih adalah yang berkualitas. Karena tingkat kualitas piranti lunak akan sangat mempengaruhi bussiness proses organisasi. Jika bussiness processnya baik, maka akan meningkatkan pelayanan, meningkatkan kinerja, dan meningkatkan revenue.

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.

II. CAPABILITY MATURITY MODEL FOR SOFTWARE (CMM-SW)

Dalam sebuah organisasi pengembang piranti lunak, Software Process adalah inti utamanya. Software Process merupakan sekumpulan aktivitas, metode, praktek, dan berbagai transformasi yang digunakan oleh sekumpulan manusia di dalamnya untuk membangun dan memelihara piranti lunak serta hal-hal yang berkaitan dengannya, misalnya project plan, dokumen desain, code, testing, cases, dan user manual.

Berkaitan dengan Software Process tersebut, terdapat istilah Software Process Capability, Software Process Performance, dan Software Process Maturity. Software Process Capability mendeskripsikan jangkauan akan hasil yang diharapkan dari Software Process. Sedangkan Software Process Performance merupakan hasil yang saat ini diraih dari Software Process.

Satu hal yang sangat penting yaitu Software Process Maturity. Hal ini berkaitan dengan cakupan proses tertentu yang benar-benar telah terdefinisikan secara eksplisit, sudah dapat diatur, dapat diukur, dikontrol, dan efektif. Dengan kata lain, Software Process Maturity berkaitan dengan tingkat kematangan dalam Software Process, dan akan berakibat pada kualitas produk piranti lunak yang dihasilkan. Berkaitan dengan inilah, maka kini terdapat sebuah model untuk menggambarkan tingkat kematangan Software Process pada sebuah pengembang piranti lunak, hal tersebut dikenal dengan Capability Maturity Model for Software (CMM-SW).

CMM-SW adalah sebuah metode untuk mengevaluasi dan mengukur tingkat kematangan (maturity) dari proses rekayasa piranti lunak. Dalam dokumen resminya, dijelaskan bahwa CMM-SW menyediakan pedoman kepada pengembang piranti lunak tentang bagaimana untuk meningkatkan kontrol terhadap proses mereka dalam membangun dan memelihara piranti lunak, dan tentang bagaimana untuk mengembangkan lebih jauh sebuah kultur rekayasa piranti lunak dan majemen yang baik. CMM-SW didesain sebagai pedoman pengembang piranti lunak dalam memilih strategi peningkatan proses, dengan mengukur kematangan proses yang sedang berjalan dan mengidentifikasi beberapa isu yang paling kritikal sehubungan dengan kualitas piranti lunak dan peningkatan proses.

Dengan demikian, bila sebuah pengembang piranti lunak menerapkan CMM-SW pada organisasinya, diharapkan pengembang tersebut dapat lebih mengontrol dan mengarahkan Software Process mereka. Sehingga cara kerjanya tidak lagi dilakukan seperti halnya sebuah proyek dadakan tanpa rencana. Hal ini juga dapat dijadikan sebagai acuan bagi pengembang piranti lunak yang baru untuk mengetahui bagaimana seharusnya proses sebuah pengembangan piranti lunak berlangsung. Sehingga proses "building block" akan lebih efektif dan efisien. dalam hal mengembangkan perusahaan yang bersangkutan. Aktivitas pengontrolannya pun dapat dilakukan secara terukur.

Dengan CMM-SW, pengembang piranti lunak akan benar-benar menjadi pengembang piranti lunak yang sesungguhnya. Karena CMM-SW akan membentuk kultur internal dan manajemen yang baik. Kultur dan struktur dari hasil CMM-SW tersebut akan sangat terintegrasi dengan pengembangan piranti lunak.

III. LIMA LEVEL PADA CMM-SW

Dalam pelaksanaan teknisnya, CMM-SW terdiri dari 5 level dilihat dari tingkat kematangan Software Process. Kelima level tersebut terdiri dari Initial (level 1), Repeatable (level 2), Defined (level 3), Managed (level 4), dan Optimizing (level 5). Semakin tinggi status level CMM pada sebuah pengembang piranti lunak, maka bisa dipastikan kualitas produksinya semakin baik.

Secara singkat, berikut ini adalah penjelasan dari masing-masing level tersebut:

Level 1: Initial. Software process dikarakteristikan sebagai sebuah ad hoc, dan kadang-kadang terjadi peristiwa chaos. 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. Proses-proses pada manajemem proyek yang fundamental telah berjalan baik dalam hal untuk menelusuri pembiayaan, penjadwalan, dan fungsionalitas. Ketertiban proses yang diperlukan adalah dalam hal untuk mengulangi kembali kesuksesan-kesuksesan dalam proyek dengan aplikasi yang serupa.

Level 3: Defined. 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. 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. Peningkatan proses secara kontinyu diberlakukan dengan feedback kuantitatif dari proses tersebut, dan dari teknologi-teknologi serta ide-ide pilot-project 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.

Jika ilustrasikan dengan sebuah perjalanan menuju suatu tujuan, maka kelima level tersebut ibaratkan titik-titik pada peta perjalanan yang harus dilalui oleh pengembang piranti lunak agar dapat mencapai tujuannya dengan lebih efisien dan efektif. Jika tanpa peta perjalanan, mungkin akan sampai tujuan, tapi mungkin tidak efisien dan/atau tidak efektif. Bahkan mungkin tujuan tidak tercapai.

IV. ALAT BANTU MENINGKATKAN KUALITAS

CMM-SW inilah yang merupakan "alat bantu" agar pengembang piranti lunak dapat mencapai tujuannya, meningkatkan kualitas produksinya.

Dalam setiap levelnya, CMM memiliki Key Process Area (KPA) sebagai rincian tentang hal-hal yang harus menjadi perhatian. Misalnya, pada level-2 KPA-nya antara lain Requirement Management, Software Project Planning, Software Project Tracking and Oversight, Software Subcontract Management, Software Quality Assurance, dan Sofware Configuration Management. Setiap KPA tersebut memiliki beberapa tujuan yang harus dicapai. Agar memudahkan dalam mencapai tujuan, CMM-SW menyediakan Common Feature, yang merupakan beberapa hal yang harus menjadi perhatian dalam implementasi. Setiap Common Feature tersebut memiliki Key Practice, yang merupakan garis-garis besar yang harus dilakukan oleh organisasi piranti lunak.

Khusus untuk level-1, di sini tidak ada Key Process Area. Karena semua organisasi piranti lunak sudah dianggap berada pada level ini.

Dari rincian struktur CMM-SW ini, dapat kita lihat bahwa CMM-SW dapat membimbing pengembang piranti lunak dalam melakukan proses yang baik dan benar. Proses pembimbingannya tersebut benar-benar didesain dalam bentuk yang terstruktur dan bertahap agar pengembang dapat mudah mengikutnya. Karena kebertahapan merupakan suatu keniscayaan untuk menuju sesuatu yang lebih baik.

CMM-SW berorientasi kepada peningkatan proses pada setiap levelnya. Karena pembangunan dan pemeliharaan piranti lunak sangat bergantung kepada prosesnya. Semakin baik prosesnya, maka akan semakin baik pula kualitas outputnya.

IV. PENTINGNYA KUALITAS PIRANTI LUNAK

Untuk pengembang piranti lunak dalam negeri, CMM-SW ini harus menjadi acuan agar mereka dapat bersaing dengan pengembang piranti lunak dari manca negara. Persaingannya adalah dalam hal berlomba-lomba dalam peningkatan kualitas, bukan dalam hal berlomba-lomba meningkatkan prestise. Prestise akan datang dengan sendirinya kalau produksi yang dihasilkan berkualitas baik.

Di sisi lain, manusia pada saat ini berbeda dengan manusia yang lalu. Saat ini manusia lebih cerdas, lebih kreatif, dan lebih kritis dalam menilai sesuatu. Sedangkan organisasi terdiri dari banyak manusia. Dengan demikian, organisasi saat ini pun akan semakin kritis dalam menilai sesuatu, termasuk dalam memilih piranti lunak. Apalagi pengembang piranti lunak semakin banyak, maka pasar pasti akan melakukan pemilihan, yaitu memilih yang berkualitas. Ini merupakan salah satu hal yang menggambarkan betapa pentingnya kualitas piranti lunak.

Selain itu, dengan adanya peningkatan kualitas piranti lunak akan mendorong pesatnya perkembangan sebuah organisasi. Sebagaimana telah disebutkan sebelumnya, dengan dukungan piranti lunak yang berkualitas, akan meningkatkan pelayanan, meningkatkan kinerja, dan revenue.

Semua itu akan mendukung daya saing pengembang piranti lunak dalam negeri terhadap pengembang piranti lunak manca negara. Apalagi kalau pengembang piranti dalam negeri hendak mengekspor produksinya ke luar negeri, CMM-SW ini merupakan syarat yang sangat penting.

Untuk membangun suasana pengembangan piranti lunak yang kondusif, pemerintah turut bertanggung jawab untuk mendorong agar perusahaan-perusahaan memiliki perhatian penuh terhadap peningkatan kualitas. Dukungan pemerintah terhadap hal ini berupa diterapkannya CMM-SW sebagai bakuan dalam setiap proyek pengembangan piranti lunak oleh pemerintah. Hal ini akan mendorong para pengembang piranti lunak dalam negeri untuk menerapkan CMM-SW pada organisasinya untuk peningkatan kualitas. Karena peningkatan kualitas tersebut secara umum akan meningkatkan pembangunan nasional.

V. MASA DEPAN

CMM-SW sudah dikembangkan sejak lebih dari 10 tahun yang lalu. Untuk masa kini dan masa depan, sudah muncul lagi yang bernama CMMI (Capability Maturity Model® Integration). CMMI merupakan pengembangan lebih lanjut dari CMM-SW. Atau boleh dikatakan bahwa CMMI ini merupakan CMM-SW versi baru. Para pengembang piranti lunak sudah mulai disarankan untuk bermigrasi dari CMM-SW ke CMMI. Namun tidak ada salahnya jika kita pelajari lebih dahulu tentang CMM-SW untuk memahami dasarnya, setelah itu baru beranjak kepada CMMI.

VI. KESIMPULAN

Tantangan kedepan dalam bersaing adalah tantangan pemenuhan kualitas yang baik. Oleh karena itu penerapan CMM-SW pada sebuah pengembang piranti lunak dalam negeri merupakan suatu keniscayaan. Selain itu, CMM-SW juga dapat membimbing pengembang piranti lunak yang baru, agar dapat establish menjadi sebuah pengembang piranti lunak yang sebenar-benarnya. Tahapan-tahapan dalam CMM-SW sudah didesain untuk menuntun agar sebuah pengembang piranti lunak dapat tumbuh berkembang.

sumber

Pemanfaatan CMM (Capability Maturity Model) Dalam Pengembangan Aplikasi Software

CMM (Capability Maturity Model) dikembangkan pertama kali oleh SEI (Software Engineering Institute) yang berbasis di Carnegie Mellon University in Pittsburgh berdasarkan pesanan dari Departemen Pertahanan Amerika Serikat.

CMM dikembangkan sebagai alat ukur dalam menguji para calon kontraktor yang akan direkrut oleh Departemen Pertahanan Amerika Serikat dalam melaksanakan kontrak pekerjaan pengembangan aplikasi perangkat lunak komputer di lembaga tersebut.

Jika disetarakan dengan standar yang ditetapkan oleh Badan Standarisasi Internasional (ISO) maka CMM dapat disetarakan dengan ISO 9001 (bagian dari seri ISO 9000).

Dimana ISO 9000 adalah standar yang ditetapkan bagi industri jasa dan manufaktur dari sisi sistem kendali mutu yang efektif.

Sedangkan ISO 9001 diperuntukkan secara khusus sebagai standar dalam pengembangan dan pemeliharaan aplikasi perangkat lunak.

Perbedaan yang cukup mendasar antara CMM dan ISO 9001 adalah pada fokus item pengujian atas sebuah proyek pengembangan aplikasi perangkat lunak komputer.

ISO 9001 lebih fokus pada standar minimum yang wajib dipenuhi dalam proses pengembangan software yang berkualitas.

Sedangkan CMM dikembangkan sebagai framework yang dapat digunakan secara berkelanjutan dalam peningkatan proses dibandingkan hanya sekedar menetapkan standar minimum yang harus dipenuhi dalam memenuhi sebuah software yang berkualitas.

Nah, lantas apa manfaatnya CMM dalam sebuah proyek pengembangan aplikasi perangkat lunak komputer?

Secara sederhana, CMM dapat diibaratkan sebagai tolok-ukur dalam menentukan tingkat “kematangan” sebuah aplikasi perangkat lunak komputer.

“Tingkat Kematangan” disini berarti semakin tinggi levelnya maka semakin baik kemampuan setiap elemen organisasi dalam mengembangkan dan mengelola softwarenya.

Level disini didasarkan pada standar yang ditetapkan oleh CMM yang terdiri atas 5 (lima) tingkatan yaitu:

• Level 1 – Ad hoc (Chaotic)

Dalam tingkatan ini, sebuah organisasi yang menerapkan aplikasi perangkat lunak komputer masih bersifat serabutan.

Serabutan dalam arti masih belum memiliki standar yang menetapkan kebijakan pemanfaatan aplikasi tersebut dan bisa dikatakan “berantakan”.

Berantakan karena tidak atau belum ada kebijakan dari top-management mengenai pengelolaan hingga pihak yang diberi otoritas untuk melaksanakannya.

Dampaknya tentu bisa kita rasakan saat terjadi masalah pada sistem aplikasi yang dibangun dan sedang beroperasi.

Tidak ada pihak yang secara responsif menanganinya apalagi tersedianya rencana penanggulangan jika masalah tersebut terjadi.

Hingga salah satu akibatnya adalah menurunnya kualitas layanan kepada pelanggan hingga jatuhnya kepercayaan rekanan kepada organisasi tersebut.

• Level 2 – Repeatable

Nah, setelah lolos dari kondisi “berantakan” dan “semrawut” seperti yang terjadi di Level 1 maka organisasi yang sedang menerapkan aplikasi perangkat lunak akan naik ke Level 2.

Di Level 2 sudah mulai ditetapkan kebijakan dan tim yang akan menangani pengembangan serta pengelolaan aplikasi perangkat lunaknya.

Manajemen proyek pun sudah mulai diterapkan oleh setiap elemen dalam organisasi/perusahaan.

Sayangnya penerapannya masih belum dilaksanakan secara disiplin oleh sebagian atau bahkan seluruh elemen dalam organisasi.

Hal tersebut tentu saja sangat beresiko dalam terjadinya proyek-proyek yang “cenderung berulang” sehingga memboroskan biaya dan sumber daya lainnya.

Pengulangan tersebut biasanya terjadi karena hal-hal seperti lemahnya koordinasi, buruknya administrasi proyek, buruknya prosedur rekrutmen kontraktor, dsb.

• Level 3 – Defined

Setelah mengatasi masalah-masalah yang timbul di dua level sebelumnya maka di Level 3 menurut CMM sebuah organisasi sudah mulai menyusun batasan-batasan yang digunakan dalam menetapkan kebijakan-kebijakannya yang terkait dengan pengembangan serta pengelolaan aplikasi perangkat lunak.

Organisasi yang sudah mencapai Level 3 akan terlihat dari terbentuknya standar dan prosedur yang harus diikuti sebagai panduan setiap elemennya dalam mengembangkan maupun mengelola aplikasi perangkat lunaknya.

• Level 4 – Managed

Organisasi yang sudah mencapai Level 4 menurut CMM biasanya sudah menerapkan sistem pengukuran yang terukur dalam proses pengembangan maupun pengelolaan aplikasi softwarenya.

Dengan adanya sistem pengukuran yang obyektif maka pemborosan sumber daya dapat dicegah, dikendalikan dan diramalkan dari awal.

Selain itu secara kualitatif sudah dapat diramalkan bagaimana sebuah proses akan terjadi dengan tingkat presisi yang tinggi.

Nah, dari sudut pandang CMM jika sebuah organisasi mampu mencapai Level 4 maka dapat dikategorikan “memiliki kelayakan” dalam mengembangkan sebuah aplikasi software.

• Level 5 – Optimized

Sebuah organisasi yang mencapai Level 5 sudah memiliki fokus dalam proses pengembangan yang berkelanjutan.

Pengembangan proses yang berkelanjutan tersebut diarahkan pada efisiensi performa aplikasi, baik dari sisi kuantitatif maupun inovasi dari teknologi yang dikembangkan.

Lantas, apa yang bisa dimanfaatkan dari penerapan CMM?

Jika melihat tingkatan-tingkatan yang harus dilalui untuk memperoleh “predikat matang” menurut standar CMM maka suatu organisasi harus memiliki road-map dari pengembangan aplikasi softwarenya.

Road-map tersebut harus berangkat dari visi dan misi organisasi sehingga aplikasi softwarenya akan berkembang selaras dengan tujuan-tujuan yang ditetapkan oleh organisasi tersebut.

Selain dari sisi internal, CMM sendiri dapat digunakan untuk mengukur “tingkat kemapanan” sebuah organisasi yang akan direkrut sebagai kontraktor proyek-proyek kita.

Misalkan PT. X ingin mengembangkan aplikasi software ERP untuk internal perusahaannya.

Nah, PT. X kemudian mengundang PT. A, PT. B dan PT. C untuk menjadi calon kontraktor yang akan melaksanakan proses pengembangan hingga transfer pengetahuan.

Dengan menggunakan CMM maka PT. X dapat mengukur “tingkat kemapanan” dari masing-masin calon kontraktor tersebut.

Dari hasil penilaian tersebut maka dapat ditentukan perusahaan mana yang akan menjadi kontraktor berdasarkan Level menurut CMM.

PT. X tentunya akan memilih perusahaan yang sudah mencapai setidaknya Level 4 demi menjamin kesuksesan implementasi proyeknya.

sumber

Apa itu CMMI?

Di milis Asosiasi Pengembang Perangkat Lunak Indonesia (APPLI) ramai dibahas mengenai standarisasi dalam pengembangan perangkat lunak. Salah satu standar yang populer digunakan adalah CMMI (Capability Maturity Model Integration) yang dikembangkan oleh Carnegie-Mellon University, untuk lebih tepatnya dalam departemen Software Engineering Institute. Selain itu, ada juga blog ini dan ini yang membahas tentang CMMI.

Dengan adanya standar, organisasi dapat berkembang dengan lebih terarah. Semua anggota organisasi mulai dari programmer, analis, tester, manajer, dan direktur menjadi tahu apa ruang lingkup pekerjaannya. Apa yang harus disediakan bagi pihak lain, dan juga apa yang bisa diharapkan dari departemen lain. Dengan demikian, tidak banyak effort yang terbuang karena miskomunikasi atau kurang koordinasi.

Sayangnya, dunia enterpreneur IT di Indonesia masih jarang yang hirau terhadap masalah standarisasi ini. Berbagai alasan dikemukakan, antara lain:

• Tidak mengerti bahasa Inggris
• Standar luar negeri tidak cocok untuk kondisi lokal
• Standar membuat organisasi monoton dan membosankan
• dan segudang alasan lainnya

Menurut saya, segala alasan itu cuma pembenaran saja untuk sifat malas belajar. Sebagai praktisi IT, tentunya kita sadar bahwa dunia tempat kita hidup sekarang (internet) dibangun di atas standar. Untuk bisa browsing, kita menggunakan protokol HTTP. Memeriksa email, menggunakan protokol POP3, IMAP, dan SMTP. Chatting, menggunakan protokol IRC, XMPP. Voice chat, menggunakan protokol SIP.

Protokol adalah nama lain dari standar. So, standar membuat hidup kita menjadi lebih baik. Setidaknya, standar apapun lebih baik daripada tanpa standar. Melalui artikel ini, mudah-mudahan para praktisi tergerak untuk setidaknya mempelajari dulu standar sebelum mengeluarkan vonis “tidak perlu” atau “tidak sesuai”.

Sekarang, mari kita lihat standarisasi dalam pengembangan perangkat lunak. Standar yang populer dan cukup saya kuasai adalah CMMI, jadi mari kita bahas tentang CMMI. Kebetulan saya pernah ikutan mengantarkan BaliCamp meraih CMMI Maturity Level 3.

Apa itu CMMI

CMMI adalah singkatan dari Capability Maturity Model Integration. Ini adalah kerangka kerja (framework) yang bisa digunakan untuk mengembangkan proses di dalam perusahaan.

Apa itu proses? Proses adalah cara kita melakukan suatu tugas. 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.

Apa sih isinya CMMI ??

CMMI terdiri dari rangkaian practices. 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.

Daftar PA, GG, SG, GP, dan SP dapat dilihat di spesifikasi CMMI yang bisa didonlod gratis di sini.

Apa hubungannya CMMI dengan standarisasi ISO

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.

Perbedaan CMMI dan ISO terletak pada ketelitiannya. 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

Singkatnya, kalau kita lulus ISO, belum tentu lulus CMMI. Sebaliknya, kalau kita lulus CMMI, besar kemungkinan kita akan langsung lulus ISO bila ikut sertifikasinya.

Apa yang dimaksud 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. Bila perusahaan kita sudah ML-5, maka kita bisa ikut dalam tender proyek software rudal Patriot. Begitu kira-kira.

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.

Bila kita sama sekali belum mengimplementasikan apa-apa, perusahaan kita dikategorikan sebagai ML-1. Level ini diadakan sebagai hiburan bagi perusahaan yang sudah ikut SCAMPI Class A, tapi tidak lulus bahkan di ML-2. Well, ML-1 kedengarannya lebih baik daripada No-ML atau ML-0 :p

Daftar lengkap PA per ML bisa dilihat di spesifikasi CMMI.

Perusahaan saya ingin mendapat ML-5, bagaimana caranya?

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.

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. 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.

Dalam sintaks Java 5, proses appraisal dalam SCAMPI Class A bisa digambarkan sebagai berikut.

int level = 1;

appraisal:
for(int i=1; i<=5; i++) {
   List allProcessAreas = maturityLevel[i].getProcessAreas();
   for(ProcessArea pa : allProcessAreas) {
       for(GenericPractice gp : allGenericPractices) {
           if(!far.isImplement(pa, gp) { break appraisal; }
       }

       for(SpecificPractice sp : pa.getSpecificPractices()) {
           if(!far.isImplement(sp)) { break appraisal; }
       }

       level++;
   }
}

Berdasarkan hasil wawancara FAR oleh ATM, LA akan memutuskan ML berapa yang pantas untuk perusahaan kita.

Semua hasil SCAMPI Class A akan dilaporkan pada SEI dan akan dipublikasikan di internet. Sebagai contoh, kita bisa melihat hasil appraisal BaliCamp pada tahun 2006.

Sayangnya, sampai sekarang belum ada appraiser lokal. Jadi kita harus mendatangkan appraiser dari luar negeri.

Informasi lebih rinci mengenai SCAMPI dapat dilihat di spesifikasi resminya. Di sana ada penjelasan rinci tentang apa saja syarat menjadi ATM, bagaimana proses interview dilakukan, dan bagaimana cara memutuskan apakah suatu evidence sudah memenuhi syarat atau belum.

Apa yang dimaksud Continuous Representation?

Perusahaan mengadopsi CMMI untuk berbagai tujuan. Ada yang 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.

Kita kesampingkan dulu motif marketing. Mari kita lihat motif peningkatan kualitas. 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.

Bila perusahaan saya sudah ML-5, apakah perusahaan akan menjadi monoton dan membosankan? Apakah karyawannya akan menjadi seperti robot belaka??

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.

Well, saya sudah pernah mengantarkan BaliCamp meraih ML-3, dan ikut terlibat dalam persiapan mencapai ML-5. Jadi, yang akan saya ceritakan ini adalah pengalaman nyata, bukan FUD (Fear, Uncertainty, Doubt).

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. Fitur yang kita implementasi dengan susah payah, bertampilan Web 2.0, menggunakan teknologi AJAX, tiba-tiba divonis client, “Ini bukan yang saya mau, GANTI !!!”.

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.

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 imajinasi end-user.

Ini hanya satu contoh saja bagaimana implementasi CMMI memudahkan hidup kita sebagai programmer. Silahkan baca-baca spesifikasinya untuk mengetahui aturan-aturan lainnya. Secara umum, CMMI sama sekali tidak menyinggung tentang teknologi, IDE, tools, bahasa pemrograman yang digunakan. Bahkan kegiatan coding sendiri cuma dibahas dalam 2 PA dari 22 yang ada, yaitu Technical Solution dan Product Integration.

Technical Solution mengharuskan kita untuk mengidentifikasi alternatif pendekatan yang tersedia. Kemudian dari alternatif tersebut, kita pilih yang paling baik, berdasarkan kriteria yang kita tentukan sendiri. Jadi tidak boleh langsung coding, melainkan harus mikir dulu.

ML-4 dan ML-5 banyak menitikberatkan pada analisa kuantitatif dan continuous improvement. Sukakah anda terlibat dalam project yang selesai tepat waktu, tidak lembur, libur pada hari Sabtu-Minggu? Nah, kalau sudah ML-5, project seperti ini bukan lagi impian, tapi sudah menjadi hal yang biasa. Delay dalam project sudah bisa diketahui sejak dini. Dari mulai telat 1 hari, project manager sudah bisa tahu dan mengambil tindakan antisipasi seperti minta pengunduran jadwal, mengurangi requirement, dan sebagainya.

Sebagai programmer, tidak banyak perubahan yang kita rasakan selain project menjadi lebih tenang dan teratur. Yang paling besar terkena dampak implementasi CMMI adalah Project Manager. Tiba-tiba saja dia akan diharuskan membuat banyak dokumen dan menyediakan data. Pekerjaan administratifnya akan menjadi jauh lebih banyak.

Tentunya hal ini bisa diatasi dengan otomasi proses. Begitu prosesnya sudah rapi, kegiatan administrasi bisa di-online-kan. Masalah versioning dokumen bisa diatasi dengan Subversion. Daftar resiko project, task management, bug report, bisa diotomasi dengan Bug/Issue Tracker. Lagipula, bila perusahaan kita bergerak di bidang IT, tentunya persenjataan seperti itu sudah seharusnya menjadi lifestyle kita.

Demikianlah penjelasan singkat tentang CMMI. Lain waktu kita akan bahas satu persatu Process Area yang ada.

Semoga bermanfaat.

sumber