LANDASAN TEORI
2.1 Definisi Sistem Informasi
Menurut O’Brien dan Marakas, sistem informasi dapat merupakan kombinasi terkelola dari manusia, hardware, software, jaringan komunikasi, sumber data dan kebijakan serta prosedur yang menyimpan, mendapatkan kembali, mentransformasi, dan menyebarkan informasi dalam organisasi (O’Brien, James dan Marakas, George., 2009).
2.2 Definisi CMMI (Capability Maturity Model Integration)
Menurut CMMI Product Team, CMMI merupakan suatu kumpulan praktik – praktik terbaik (best practice’s) untuk membantu organisasi dalam meningkatkan proses pengembangan aplikasi mereka. Model ini dikembangkan oleh tim yang terdiri dari praktisi dunia industry, pemerintah dan Software Engineering Institute (SEI) (CMMI Product Team, 2010).
CMMI mendefinisikan praktik – praktik yang secara khusus diimplementasikan oleh bisnis pengembangan aplikasi untuk mencapai kesuksesan. Praktik – praktik yang dimaksud termasuk topik yang secara langsung membahas mengenai bagaimana memperoleh dan mengelola kebutuhan, pengambilan keputusan, pengukuran kinerja, perencanaan
kerja, menangani risiko, dan lain sebagainya (Dadhich, Reena dan Chauhan, Ujana., 2012).
Model ini disebut sebagai CMMI for Development (CMMI-DEV), yang menyediakan model terintegrasi secara komprehensif bagi perusahaan pengembang aplikasi. Best practices dalam model ini berfokus untuk memenuhi kebutuhan pelanggan dan pengguna akhir. CMMI-DEV terdiri dari 22 area proses, 16 diantaranya adalah proses area inti, 1 diantaranya merupakan proses area yang terbagi, dan 5 diantaranya adalah proses area khusus pengembangan.
2.2.1 Keterkaitan antara Kerangka Sistem Informasi (IS Framework) dengan CMMI
Menurut O’Brien dan Marakas, kerangka sistem informasi terbagi menjadi 5 bagian pengetahuan (O’Brien, James dan Marakas, George, 2009) yaitu:
1. Foundation concepts: konsep tingkah laku dasar, teknikal, bisnis, dan manajerial seperti komponen dan fungsi sistem, atau strategi kompetitif.
2. Information technologies: konsep mayor, pengembangan, atau isu manajemen terkait hardware, software, manajemen data, jaringan dan teknologi lainnya.
3. Business applications: penggunaan mayor dari TI untuk proses bisnis, operasi, pembuatan keputusan, dan keunggulan strategis/kompetitif.
4. Development processes: bagaimana end user dan spesialis SI membangun dan mengimplementasi solusi bisnis/TI terhadap masalah dan peluang yang ada dalam bisnis.
5. Management challenges: bagaimana mengelola fungsi SI dan sumber daya TI secara efektif dan etis untuk mencapai kinerja puncak dan nilai bisnis dalam mendukung strategi bisnis perusahaan.
Gambar 2.1 Kerangka Sistem Informasi (O’Brien, James dan Marakas, George., 2009)
Bagian development processes berfokus pada bagaimana pendekatan dalam menanggapi masalah dan peluang yang ada dalam bisnis. Ketika pendekatan sistem dalam menyelesaikan masalah dapat dilakukan dengan pengembangan solusi SI, hal tersebut dapat disebut sebagai pengembangan SI atau pengembangan aplikasi (O’Brien, James dan Marakas, George., 2009). CMMI berfungsi
sebagai model yang dapat digunakan oleh organisasi untuk membantu dalam meningkatkan proses pengembangan aplikasi mereka. CMMI memberikan panduan dalam menerapkan best
practices pengembangan aplikasi yang berfokus dalam aktivitas
pengembangan aplikasi untuk memenuhi kebutuhan end user (CMMI Product Team, 2010).
2.3 Latar Belakang CMMI
Sejarah evolusi CMMI sejalan dengan perubahan industri pengembangan aplikasi dan juga kebutuhan perusahaan yang terus berkembang. Model CMMI pertama yang diciptakan adalah CMMI for Development. Sampat saat tesis ini dibuat, model CMMI-DEV terakhir yang dirilis adalah CMMI-DEV v.1.3. CMMI datang dalam bentuk panduan secara umum dan model yang melampaui disiplin – disiplin, memasukkan seluruh unsur siklus hidup proyek dari konsep, pengembangan, pengiriman (delivery) dan perawatan (Constantinescu, R dan Mihnea, I., 2007).
Gambar 2.2 Evolusi CMMI (CMMI Product Team, 2010)
Capability maturity model (CMM) berfokus pada meningkatkan
proses dalam organisasi. CMM berisi elemen dasar dari proses efektif untuk satu atau lebih disiplin dan menjelaskan mengenai evolusi jalur peningkatan proses dari yang bersifat ad hoc, proses immature hingga disiplin, proses mature dengan peningkatan kualitas dan effektifitas. Integrasi CMM dilakukan dengan tujuan menghilangkan kompleksitas penggunaan kombinasi model CMM. Hal ini bersumber dari kombinasi dari tiga model dibawah:
1. Capabiltity Maturity Model for Software (SW-CMM) 2. System Engineering Capability Model (SECM)
3. Integrated Product Developmet Capabiltiy Maturity Model (IPD-CMM)
Tujuan dari CMMI adalah menyediakan CMM yang mencakup pengembangan dan perawatan produk dan layanan serta sekaligus menyediakan framework yang luas sehingga badan pengetahuan (body of
knowledge) baru dapat ditambahkan. Saat ini, terdapat empat badan
pengetahuan yang tesedia ketika merencanakan peningkatan proses menggunakan CMMI:
1. System engineering 2. Software engineering
3. Integrated product and process development 4. Supplier sourcing
Setiap disiplin dari badan pengetahuan tercakup pada area proses yang terkait dan pada komponen model. Area proses adalah cluster dari
best practice terkait pada area yang ketika diimplementasikan secara
kolektif, dapat memberikan pemenuhan tujuan (goal) penting untuk memberikan peningkatan yang signifikan pada area tersebut (Constantinescu, R. dan Mihnea, I., 2007). CMMI memberikan model yang stabil dan terkoneksi satu sama lain, dengan cakupan yang lebih detail atas siklus hidup aplikasi dibandingkan model peningkatan proses lain. CMMI mengasimilasi pengalaman dari komunitas - komunitas dan
lesson learned yang didapat dari pengembangan, perawatan dan
penggunaan model sumber dari mulai aplikasi dikembangkan, hingga penemuan adanya masalah (defect, bugs). CMMI menggabungkan
software engineering dan sytem engineering menjadi product engineering,
Membantu perusahaan untuk berfokus pada end product dan proses – proses terkait. Hal ini memungkinkan fleksibilitas dalam mengimplementasikan model untuk pencapaian tujuan bisnis perusahaan.
Berdasarkan penelitian yang dilakukan oleh Naomi (Honda, Naomi dan Yamada, Shigeru., 2012) terhadap sebuah organisasi yang telah menerapkan CMMI level 5, diketahui bahwa organisasi tersebut mampu meningkatkan kualitas aplikasi yang dikembangkannya dengan pendeteksian defects pada tahap awal desain maupun code review, memastikan kualitas proses maupun produk, implementasi manajemen kuantitatif, serta kemampuan untuk melakukan analisa root-cause.
CMMI memberikan keuntungan bagi organisasi dengan menyediakan visi peningkatan yang umum dan terintegrasi. Keuntungan yang paling utama adalah peningkatan kinerja yang berarti biaya yang berkurang, peningkatan on-time delivery, peningkatan produktivitas, peningkatan kualitas, dan peningkatan kepuasan pelanggan (CMMI Institute, 2014).
2.4 Penyajian CMMI (CMMI Representation)
Berdasarkan panduan CMMI for Development versi 1.3, terdapat dua macam representasi yang dapat disajikan menggunakan CMMI-DEV. Model CMMI memungkinkan dua pendekatan/representasi dari apa yang disebut Quality Management: representasi continous dan representasi
staged. Dengan menggunakan representasi continous perusahaan dapat
mengetahui capability level, sedangkan dengan menggunakan representasi
Maturity secara konseptual merepresentasikan fase atas peningkatan
kuantitatif atau kualitatif perubahan kapabilitas dari elemen yang berevolusi menjadi lebih matang (mature) agar dapat menilai kemajuan atas area fokus yang didefinisikan (Kohlegger, Michael., Maier, Ronald., dan Thalmann, Stefan., 2009). Model maturity adalah instrumen populer yang populer digunakan, misalnya untuk menilai kapabilitas dari elemen yang menjadi matang dan memilih tindakan yang sesuai untuk membawa elemen tersebut pada maturity model yang lebih tinggi. Penggunaannya luas dan variatif mulai dari ilmu sains sampai ke bisnis dan teknik. Biasanya elemen yang menjadi matang adalah orang, objek atau sistem sosial. Model maturity dapat digunakan untuk mendeskripsikan perubahan pada objek yang diobservasi, serta memandu sang pemilik, pengelola atau individu terkait lainnya dalam membuat perubahan maturity dari elemen yang menjadi matang agar dapat lebih efektif atau efisien.
Perbedaan antara kedua representasi pada CMMI adalah, representasi staged menggunakan maturity level untuk memperlihatkan karakteristik keadaan proses organisasi secara keseluruhan. Representasi
stafed berfokus pada peningkatan proses secara sistematis dan terstruktur,
mengarah untuk mencapai tahap yang memungkinkan untuk menghasilkan
framework untuk tahap berikutnya. sementara representasi continous
menggunakan capability level untuk memperlihatkan karakteristik keadaan proses organisasi melalui proses area secara individual. Mengarah kepada peningkatan kinerja dari sebuah area proses dalam organisasi yang
diharapkan berkembang kepada sektor lain namun tetap sesuai dengan tujuan strategis organisasi (CMMI Product Development Team, 2002).
Gambar 2.3 Representasi Continous (CMMI Product Team, 2010)
Gambar 2.4 Representasi Staged (CMMI Product Team, 2010)
Untuk dapat mencapai level yang diinginkan, suatu perusahaan harus memenuhi semua goal dalam area proses yang dijadikan sasaran pengembangan, baik menggunakan capability level maupun maturity
level. Kedua representasi tersebut memberikan panduan untuk
meningkatkan proses untuk mencapai tujuan bisnis perusahaan. Representasi continous memberikan gambaran secara detail proses dalam perusahaan (CMMI Product Team, 2010). Hal ini memberikan kemampuan bagi organisasi untuk mengevaluasi area proses secara individual, mampu mengidentifikasi dan berfokus pada titik masalah serta mengukur status peningkatan. Untuk tiap area proses, tingkat kapabilitas digunakan untuk mengukur peningkatan dari proses yang tidak berjalan hingga proses yang teroptimisasi. Capability level tidak dapat dilewati, karena dibuat satu diatas yang lain. Menggunakan representasi continous membutuhkan pemahaman yang baik atas ketergantungan dari tiap area proses, karena interkoneksi diantaranya mungkin membutuhkan capability
level tertentu untuk area proses lain sebelum yang lain mencapai target capability level. Representasi ini mengatur area proses pada empat
kategori dasar (CMMI Product Team, 2010):
1. Support: berisi proses yang tidak memiliki output eksternal/komersil, namun menyediakan fondasi dimana bagian organisasi lainnya dapat melakukan aktifitas efisien
2. Engineering: berisi proses yang “do the work” – melakukan pekerjaan aktual organisasi
3. Project Management: berisi proses yang mengkordinasikan agar pekerjaan aktual dapat berjalan secara efisien dalam organisasi
4. Process Management: berisi proses yang mengatur jalur untuk seluruh organisasi
Representasi staged memberikan pandangan pada tingkat organisasi, menyediakan pengukuran keseluruhan organisasi (CMMI Product Team, 2010). Tidak sedetil jika dibandingkan representasi continous, namun menyediakan sudut pandang secara high level atas keseluruhan organisasi, sederhana, langsung pada tujuan, lebih mudah dipahami, dengan dampak yang lebih kepada implikasi bisnis organisasi. Representasi staged akan menyediakan pengukuran standardisasi atas maturity level keseluruhan organisasi.Seperti pada proses – proses dalam capability level, maturity
level dibuat satu diatas yang lain, sehingga level tidak dapat dilewati/skip,
dan tingkat maturity level yang lebih tinggi memiliki unsur persyaratan dari
maturity level yang lebih rendah. Representasi staged menyediakan roadmap untuk secara efisien berfokus pada meningkatkan proses dan area
proses, dengan milestone untuk membawa seluruh organisasi pada arah yang jelas dari tingkat initial ke tingkat optimizing, memastikan peningkatan yang kuat. Pencapaian atas maturity level memberikan pondasi yang solid bagi peningkatan keseluruhan organisasi untuk mencapai
maturity level berikutnya.
2.5 Model Bertingkat
Berdasarkan panduan CMMI for Development versi 1.3 (CMMI Product Team, 2010), terdapat lima maturity level, setiap tingkatnya
menyediakan fondasi dalam peningkatan proses dan sebagai pendukung tingkat selanjutnya. Lima maturity level tersebut adalah sebagai berikut: 1. Initial
2. Managed 3. Defined
4. Quantitatively Managed 5. Optimizing
Gambar 2.5 Lima Maturity Level (CMMI Product Team, 2010)
Istilah staged didasari dari bagaimana model menjelaskan tingkatan area proses yang menunjukkan bagaimana sebuah perusahaan seharusnya berfokus untuk meningkatkan proses mereka. Setiap area proses dideskripsikan sebagai praktek – praktek yang memegang peran dalam mencapai tujuannya. Maturity level terdiri dari praktik specific dan generic terkait untuk masing – masing area proses yang dapat meningkatkan kinerja organisasi secara keseluruhan. Setiap maturity level merupakan
subset penting bagi proses organisasi, mempersiapkannya untuk naik ke
maturity level berikutnya. Maturity level diukur dengan pencapaian dari
praktik specific dan generic yang terasosiasi dengan setiap set area proses.
2.6 Lima Maturity Level
2.6.1 Maturity Level 1: Initial
Pada maturity level ini proses biasanya berbentuk ad hoc (CMMI Product Team, 2010). 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. Organisasi terkarakteristik dengan adanya tendensi komitmen yang berlebih, meninggalkan pekerjaan mereka disaat terjadi krisis, dan tidak dapat mengulangi kesuksesan.
2.6.2 Maturity Level 2: Managed
Pada maturity level ini sebuah organisasi telah mencapai seluruh specific dan generic goals pada level 2 (CMMI Product Team, 2010). 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 secara aktif pada proses yang dibutuhkan. Setiap aktivitas dan hasil pekerjaan berupa memonitor, mengontrol, meninjau, serta mengevaluasi untuk menjaga
kekonsistenan pada deskripsi yang telah diberikan. Komitmen telah diciptakan diantara para stakeholder dan direvisi apabila perlu. Produk kerja dan layanan telah terkendali serta memenuhi deskripsi proses, standar dan prosedur.
2.6.3 Maturity Level 3: Defined
Pada maturity level ini sebuah organisasi telah mencapai seluruh specific dan generic goals pada level 2 dan level 3(CMMI Product Team, 2010). 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. Pada maturity level 3, organisasi meningkatkan proses mereka lebih jauh yang terkait dengan area proses di maturity
level 2. Praktik generic yang berhubungan dengan generic goal 3
yang belum ada di level 2 diimplementasikan untuk mencapai
maturity level 3.
2.6.4 Maturity Level 4: Quantitatively Managed
Pada maturity level ini, sebuah organisasi telah mencapai seluruh specific dan generic goals yang ada pada level 2, 3, dan 4 (CMMI Product Team, 2010). Proses yang terjadi dapat terkontrol dan ditambah menggunakan ukuran-ukuran dan taksiran kuantitatif. Sasaran kuantitatif untuk kualitas dan kinerja proses ditetapkan dan digunakan sebagai kriteria dalam manajemen proses. Perbedaan
yang jelas antara maturity level 3 dan 4 adalah prediktabilitas kinerja proses. Pada maturity level 4, kinerja proyek dan subproses terkendali dengan metode statistik dan kuantitatif lainnya, dan didasarkan prediksi, serta sebagai bagian dari analisa statistik data yang telah diproses dengan baik.
2.6.5 Maturity Level 5: Optimizing
Pada maturity level ini suatu organisasi telah mencapai seluruh
specific dan generic goals yang ada di level 2, 3, 4, dan 5(CMMI
Product Team, 2010). Maturity level 5 fokus kepada peningkatan proses secara berkesinambungan melalui inovasi teknologi. Perbedaan yang jelas antara maturity level 4 dan 5 adalah fokus dalam mengelola dan meningkatkan kinerja organisasi. Pada
maturity level 5, organisasi lebih berfokus pada kinerja organisasi
secara keseluruhan menggunakan data yang dikumpulkan dari banyak proyek. Hasil analisa data digunakan untuk peningkatan proses dan kinerja secara terukur.
2.7 Proses Area CMMI
Berdasarkan pembagian kategori area proses pada representasi
continous, area proses dapat dikategorikan menjadi empat jenis yaitu: Process Management, Project Management, Engineering dan Support.
Gambar 2.6 Area Proses berdasarkan Kategori (CMMI Product Team, 2010)
Area proses Supplier Agreement Management merupakan area proses yang terbagi (shared) dan bukan area proses inti. Area proses didalam Process Management, Project Management dan Engineering saling berkaitan satu sama lain. Namun, area proses Support berdiri sendiri. Sedangkan pada representasi staged, area proses diletakkan sesuai dengan maturity level sesuai dengan area proses terkait. Dibawah ini terdapat tabel yang menggambarkan daftar area proses sesuai dengan
Gambar 2.7 Area Proses berdasarkan Maturity Level (CMMI Product Team, 2010)
Untuk membantu perusahaan yang menggunakan representasi
staged, area proses dikelompokkan berdasarkan m aturity level,
mengindikasikan area proses yang harus diimplementasikan untuk mencapai tiap maturity level. Framework CMMI mencakup dua puluh dua (22) area proses yang mendefinisikan dimensi proses dari framework. Berikut dibawah merupakan penjelasan dari seluruh area proses dalam CMMI.
2.7.1 Requirement Management (REQM)
Tujuan Requirement Management (REQM) adalah untuk mengelola persyaratan produk proyek dan komponen produk dan untuk memastikan keselarasan antara kebutuhan dan rencana proyek dan produk kerja (CMMI Product Team, 2010). Requirement
Management mengelola semua persyaratan yang diterima atau
dihasilkan oleh proyek, termasuk persyaratan teknis dan non teknis serta persyaratan yang dikenakan pada proyek oleh organisasi. Terdapat lima (5) praktik spesifik yang tercakup dalam area proses ini, yaitu:
1) Mengembangkan pemahaman dengan penyedia kebutuhan
2) Mendapatkan komitmen atas kebutuhan
3) Mengelola perubahan terhadap kebutuhan
4) Mengelola bidirectional traceability antara kebutuhan – kebutuhan dan work product
5) Memastikan penyelarasan antara kebutuhan dan hasil proyek
2.7.2 Project Planning (PP)
Tujuan Project Planning (PP) adalah untuk membangun dan mempertahankan rencana yang mendefinisikan kegiatan proyek (CMMI Product Team, 2010). Perencanaan meliputi memperkirakan
atribut produk kerja dan tugas, menentukan sumber daya yang dibutuhkan, negosiasi komitmen,
menghasilkan jadwal, dan mengidentifikasi dan menganalisis risiko proyek. Iterasi melalui kegiatan ini mungkin diperlukan untuk menetapkan rencana proyek. Rencana proyek memberikan dasar untuk melakukan dan mengendalikan kegiatan proyek yang memberikan komitmen dengan pelanggan proyek. Terdapat empat belas (14) praktik spesifik yang tercakup dalam area proses ini, yaitu:
1) Mengestimasi lingkup proyek
2) Mengestimasi produk kerja dan atribut tugas
3) Mendefinisikan siklus hidup proyek
4) Mengestimasi upaya dan biaya proyek
5) Menetapkan dan mengelola jadwal dan anggaran proyek
6) Mengidentifikasi dan menganalisa risiko proyek
7) Merencanakan pengelolaan data proyek
8) Merencanakan sumber daya untuk melakukan proyek
9) Merencanakan pengetahuan dan kompetensi yang dibutuhkan untuk melakukan proyek
10) Merencanakan keterlibatan stakeholder yang teridentifikasi
11) Menetapkan dan mengelola perencanaan proyek
13) Merubah project plan untuk merekonsiliasi dan mengestimasi sumber daya yang tersedia
14) Mendapatkan komitmen dari stakeholder terkait
2.7.3 Project Monitoring and Control (PMC)
Tujuan Project Monitoring and Control (PMC) adalah untuk memberikan pemahaman tentang kemajuan proyek sehingga tindakan koreksi yang tepat dapat diambil ketika kinerja proyek menyimpang secara signifikan dari rencana (CMMI Product Team, 2010). Rencana proyek didokumentasikan sebagai dasar untuk kegiatan monitoring, status hubungan, dan mengambil tindakan korektif. Terdapat sepuluh (10) praktik spesifik yang tercakup dalam area proses ini, yaitu:
1) Memantau nilai aktual dari perencanaan proyek
2) Memantau komitmen
3) Memantau risiko
4) Memantau pengelolaan data proyek
5) Memantau keterlibatan stakeholder
6) Mengkaji secara periodik kemajuan proyek, kinerja dan isu
8) Mengumpulkan dan menganalisa isu dan menentukan corrective
action
9) Melakukan corrective action pada isu yang teridentifikasi
10) Mengelola corrective action hingga terselesaikan
2.7.4 Measurement and Analysis (M&A)
Tujuan Measurement and Analysis (MA) adalah untuk mengembangkan dan mempertahankan kemampuan pengukuran yang digunakan untuk mendukung kebutuhan informasi manajemen (CMMI Product Team, 2010). Pengukuran dan analisis komponen produk yang disediakan oleh pemasok sangat penting untuk manajemen yang efektif dari kualitas dan biaya proyek. Hal ini -dimungkinkan, dengan pengelolaan yang cermat dari perjanjian dengan pemasok, untuk memberikan informasi tentang data yang mendukung analisis kinerja pemasok. Terdapat delapan (8) praktik spesifik yang tercakup dalam area proses ini, yaitu:
1) Menetapkan dan mempertahankan objektif pengukuran
2) Menentukan pengukuran untuk mengakomodasi objektif pengukuran
3) Menentukan bagaimana data pengukuran akan didapatkan dan disimpan
4) Menentukan bagaimana data pengukuran akan dianalisa dan di komunikasikan
5) Mendapatkan data pengukuran yang ditentukan
6) Menganalisa dan menerjemahkan data pengukuran
7) Mengelola dan menyimpan data pengukuran
8) Mengkomunikasikan hasil pengukuran dan analisa
2.7.5 Process and Product Quality Assurance (PPQA)
Tujuan Process and Product Quality Assurance (PPQA) adalah untuk menyediakan staf dan manajemen dengan wawasan ke dalam proses objektif dan terkait kerja produk (CMMI Product Team, 2010). Process and Product Quality Assurance mendukung pengiriman produk berkualitas tinggi dengan menyediakan staf proyek dan manajer di semua tingkat dengan visibilitas yang tepat ke dalam, dan umpan balik, proses dan terkait pekerjaan produk sepanjang kehidupan proyek. Terdapat empat (4) praktik spesifik yang tercakup dalam area proses ini, yaitu:
1) Secara objektif mengevaluasi proses terpilih yang dilakukan dengan deskripsi proses, standar dan prosedur yang berlaku
2) Secara objektif mengevaluasi produk kerja dan layanan terpilih dengan deskripsi proses, standar dan prosedur yang berlaku
3) Mengkomunikasikan isu terkait kualitas dan memastikan penyelesaian atas isu ketidakpatuhan
4) Menetapkan dan mempertahankan rekor dari aktivitas quality
assurance
2.7.6 Configuration Management (CM)
Tujuan dari Configuration Management (CM) adalah untuk membangun dan menjaga integritas produk kerja menggunakan identifikasi konfigurasi, konfigurasi kontrol, akuntansi konfigurasi status, dan konfigurasi audit (CMMI Product Team, 2010). Terdapat tujuh (7) praktik spesifik yang tercakup dalam area proses ini, yaitu:
1) Mengidentifikasi configuration item, komponen dan produk kerja terkait
2) Menetapkan dan mempertahankan manajemen konfigurasi dan manajemen perubahan
3) Membuat atau merilis baseline untuk penggunaan internal dan untuk penyampaian ke pelanggan
4) Melakukan track permintaan perubahan atas configuration item
5) Mengendalikan perubahan atas configuration item
7) Melakukan audit konfigurasi untuk mempertahankan integritas atas baseline konfigurasi
2.7.7 Supplier Agreement Management (SAM)
Tujuan dari Supplier Agreement Management (SAM) adalah untuk mengelola akuisisi produk dan jasa dari pemasok (CMMI Product Team, 2010). Ruang lingkup area proses ini membahas akuisisi produk, jasa, dan produk dan layanan komponen yang dapat disampaikan kepada pelanggan proyek atau termasuk dalam sistem produk atau jasa. Terdapat enam (6) praktik spesifik yang tercakup dalam area proses ini, yaitu:
1) Menentukan tipe akuisisi untuk tiap produk atau komponen produk yang akan diakuisisi
2) Memilih pemasok berdasarkan evaluasi kemampuan mereka untuk dapat memenuhi kebutuhan yang ditentukan dan kriteria yang ditetapkan
3) Menetapkan dan mempertahankan perjanjian pemasok (supplier
agreement)
4) Melakukan aktivitas dengan pemasok seperti yang ditentukan dalam perjanjian pemasok
5) Memastikan bahwa perjanjian pemasok memuaskan sebelum menerima produk yang diakuisisi
6) Memastikan transisi produk yang diakuisisi dari supplier
2.7.8 Requirement Development (RD)
Tujuan Requirement Development (RD) adalah untuk memperoleh, menganalisis, dan membangun pelanggan, produk, dan persyaratan produk komponen (CMMI Product Team, 2010). Area proses ini menjelaskan tiga jenis persyaratan: persyaratan pelanggan, persyaratan produk, dan persyaratan produk komponen. Area proses ini mengirimkan semua kebutuhan pelanggan bukan hanya persyaratan tingkat produk karena pelanggan juga dapat memberikan desain persyaratan spesifik. Terdapat sepuluh (10) praktik spesifik yang tercakup dalam area proses ini, yaitu:
1) Memperoleh kebutuhan stakeholder, harapan, batasan dan antar
muka untuk seluruh fase siklus produk
2) Mentransformasi kebutuhan stakeholder, harapan, batasan dan
antar muka menjadi kebutuhan pelanggan
3) Menetapkan dan mengelola kebutuhan produk dan komponen produk, dimana didasarkan atas kebutuhan pelanggan
4) Mengalokasi kebutuhan untuk tiap komponen produk
5) Mengidentifikasi kebutuhan antar muka
6) Menetapkan dan mengelola konsep operasional dan skenario terkait
7) Menetapkan dan mengelola definisi atas kebutuhan fungsionalitas dan atribut kualitas
8) Menganalisa kebutuhan untuk memastikan bahwa mereka diperlukan dan mencukupi
9) Menganalisa kebutuhan untuk menyeimbangkan kebutuhan
stakeholder dan batasan - batasan
10) Memvalidasi kebutuhan untuk memastikan produk yang dihasilkan akan memberi kinerja seperti yang diharapkan di lingkungan pengguna
2.7.9 Technical Solution (TS)
Tujuan dari Technical Solution (TS) adalah untuk memilih, merancang, dan mengimplementasikan solusi untuk persyaratan (CMMI Product Team, 2010). Solusi, desain, dan implementasi meliputi produk, komponen produk, dan siklus hidup produk terkait baik secara tunggal atau dalam kombinasi sesuai area proses. Proses
Technical Solution ini berlaku pada setiap tingkat arsitektur produk
dan untuk setiap produk, komponen produk, dan proses siklus hidup produk terkait. Terdapat delapan (8) praktik spesifik yang tercakup dalam area proses ini, yaitu:
2) Memilih solusi komponen produk berdasarkan kriteria pemilihan
3) Membuat desain produk atau komponen produk
4) Menetapkan dan mengelola paket data teknis
5) Mendesain antar muka komponen produk menggunakan kriteria yang telah ditetapkan
6) Mengevaluasi apakah komponen produk perlu dibuat, dibeli atan di gunakan kembali (reuse) berdasarkan kriteria yang telah ditetapkan
7) Mengimplementasi desain komponen produk
8) Membuat dan mempertahankan dokumentasi end-use
2.7.10 Product Integration (PI)
Tujuan Product Integration (PI) adalah untuk merakit produk dari komponen produk, memastikan bahwa produk tersebut terintegrasi, memberikan kinerja baik (yaitu, memiliki fungsi dan atribut kualitas yang diperlukan), dan mengirimkan produk seperti yang diharapkan (CMMI Product Team, 2010). Terdapat sembilan (9) praktik spesifik yang tercakup dalam area proses ini, yaitu:
1) Menetapkan dan mempertahankan strategi integrasi produk
2) Menetapkan dan mempertahankan lingkungan yang dibutuhkan untuk mendukung integrasi dari komponen produk
3) Menetapkan dan mempertahankan prosedur dan kriteria untuk integrasi komponen produk
4) Mengkaji deskripsi antar muka untuk cakupan dan kelengkapan
5) Mengelola definisi antar muka internal dan eksternal, desain dan perubahan untuk produk dan komponen produk
6) Mengkonfirmasi, sebelum pemasangan, bahwa setiap komponen produk yang dibutuhkan untuk pemasangan produk telah diidentifikasi dan berlaku sesuai dengan deskripsi, dan antar
muka bahwa komponen produk sesuai dengan deskripsi antar muka
7) Memasang komponen produk sesuai dengan strategi integrasi produk dan prosedur
8) Mengevaluasi komponen produk terpasang untuk kompabilitas
antar muka
9) Memaketkan produk yang telah terpasang atau komponen produk dan mengirimkannya ke pelanggan
2.7.11 Verification (VER)
Tujuan Verification (VER) adalah untuk memastikan bahwa produk kerja yang dipilih memenuhi persyaratan yang ditentukan mereka (CMMI Product Team, 2010). Area proses Verivication melibatkan aktifitas berikut: verifikasi persiapan, kinerja verifikasi, dan identifikasi tindakan perbaikan. Terdapat delapan (8) praktik spesifik yang tercakup dalam area proses ini, yaitu:
1) Memilih produk kerja untuk diverifikasi dan metode verifikasi yang biasa digunakan
2) Menetapkan dan mengelola lingkungan yang dibutuhkan untuk mendukung verifikasi
3) Menetapkan dan mengelola prosedur dan kriteria verifikasi untuk produk kerja terpilih
4) Menyiapkan peer review untuk produk kerja terpilih
5) Melakukan peer review pada produk kerja terpilih dan mengidentifikasi isu yang ditemukan dari peer review
6) Menganalisa data mengenai persiapan, eksekusi dan hasil dari
peer review
7) Melakukan verifikasi dari produk kerja terpilih
2.7.12 Validation (VAL)
Tujuan Validation (VAL) adalah untuk menunjukkan bahwa suatu produk atau komponen produk memenuhi digunakan ketika ditempatkan di lingkungan yang dimaksudkan (CMMI Product Team, 2010). Kegiatan validasi dapat diterapkan pada semua aspek dari produk dalam lingkungan yang dimaksudkan, seperti layanan operasi, pelatihan, manufaktur, perawatan, dan dukungan. Terdapat lima (5) praktik spesifik yang tercakup dalam area proses ini, yaitu:
1) Memilih produk dan komponen produk untuk divalidasi dan metode validasi yang akan digunakan
2) Menetapkan dan mempertahankan lingkungan yang dibuthkan untuk mendukung validasi
3) Menetapkan dan mempertahankan prosedur dan kriteria validasi
4) Melakukan validasi pada produk dan komponen produk terpilih
5) Menganalisa hasil dari aktivitas validasi
2.7.13 Organizational Process Focus (OPF)
Tujuan Organizational Process Focus (OPF) adalah merencanakan, melaksanakan, dan menggunakan perbaikan proses organisasi berdasarkan pemahaman menyeluruh tentang kekuatan dan kelemahan dari proses organisasi dan aset proses (CMMI
Product Team, 2010). Terdapat sembilan (9) praktik spesifik yang tercakup dalam area proses ini, yaitu:
1) Menetapkan dan mengelola deskripsi kebutuhan proses dan objektif untuk organisasi
2) Menilai proses organisasi secara periodik dan sesuai kebutuhan untuk mempertahankan pemahaman atas kekuatan dan kelemahan proses
3) Mengidentifikasi peningkatan pada proses dan aset proses dalam organisasi
4) Menetapkan dan mempertahankan action plan proses untuk mengikutsertakan peningkatan dalam proses dan aset proses organisasi
5) Mengimplementasi action plan proses
6) Menyebarkan aset proses organisasi pada seluruh organisasi
7) Menyebarkan kumpulan proses standar organisasi di awal proyek dan menyebarkan perubahan pada proyek pada siklus proyek
8) Memantau implementasi kumpulan proses standar organisasi dan penggunaan aset proses pada seluruh proyek
9) Menggabungkan produk kerja terkait proses, pengukuran dan informasi peningkatan yang diturunkan dari perencanaan dan melakukan proses kedalam aset proses organisasi
2.7.14 Organizational Process Definition (OPD)
Tujuan dari Organizational Process Definition (OPD) adalah untuk membangun dan memelihara sebuah set dan dapat digunakan sebagai aset proses organisasi, standar lingkungan bekerja, serta aturan dan pedoman bagi organisasi (CMMI Product Team, 2010). Aset proses organisasi memungkinkan eksekusi proses yang konsisten di seluruh organisasi dan memberikan dasar untuk manfaat jangka panjang bagi organisasi. Terdapat tujuh (7) praktik spesifik yang tercakup dalam area proses ini, yaitu:
1) Menetapkan dan mempertahankan kumpulan proses standar organisasi
2) Menetapkan dan mempertahankan deskripsi model siklus hidup yang disetujui untuk digunakan dalam organisasi
3) Menetapkan dan mempertahankan kriteria tailoring dan panduannya untuk kumpulan proses standar organisasi
4) Menetapkan dan mempertahankan repositori pengukuran organisasi
6) Menetapkan dan mengelola standar lingkungan kerja
7) Menetapkan dan mengelola peraturan dan panduan organisasi untuk struktur, formasi dan operasi tim
2.7.15 Organizational Training (OT)
Tujuan Organizational Training (OT) adalah untuk
mengembangkan keterampilan dan pengetahuan orang sehingga mereka dapat melakukan peran mereka secara efektif dan efisien (CMMI Product Team, 2010). Terdapat tujuh (7) praktik spesifik yang tercakup dalam area proses ini, yaitu:
1) Menetapkan dan mengelola kebutuhan pelatihan strategis organisasi
2) Menentukan kebutuhan pelatihan mana yang menjadi tanggung jawab organisasi dan mana yang dapat menjadi tanggung jawab proyek individual atau grup pendukung
3) Menetapkan dan mengelola rencana taktis pelatihan organisasi
4) Menetapkan dan mengelola kapabilitas pelatihan untuk mengakomodasi kebutuhan pelatihan organisasi
5) Memberikan pelatihan sesuai rencana taktis pelatihan organisasi
6) Menetapkan dan mengelola catatan pelatihan organisasi
2.7.16 Integrated Project Management (IPM)
Tujuan dari Integrated Project Management (IPM) adalah untuk membangun dan mengelola proyek dan keterlibatan pemangku kepentingan yang relevan sesuai dengan proses terintegrasi dan didefinisikan yang disesuaikan dari organisasi set proses standar (CMMI Product Team, 2010). Mengelola usaha proyek, biaya, jadwal, staf, risiko, dan faktor lainnya terkait dengan tugas-tugas dari proses proyek yang telah didefinisikan. Pelaksanaan dan pengelolaan proses proyek yang telah didefinisikan biasanya dijelaskan dalam rencana proyek. Terdapat sepuluh (10) praktik spesifik yang tercakup dalam area proses ini, yaitu:
1) Menetapkan dan mengelola proses proyek yang telah terdefinisi dari mulai awal proyek ke seluruh hidup proyek
2) Menggunakan repositori aset proses dan pengukuran organisasi untuk mengestimasi dan merencanakan aktivitas proyek
3) Menetapkan dan mengelola lingkungan kerja proyek berdasarkan standar lingkungan kerja perusahaan
4) Mengintergrasikan rencana proyek dan rencana lainnya yang mempengaruhi proyek untuk menggambarkan proses proyek terdefinisi
5) Mengelola proyek menggunakan rencana proyek, rencana lainnya yang mempengaruhi proyek dan proses proyek terdefinisi
6) Menetapkan dan mengelola tim
7) Mengkontribusikan pengalaman terkait proses kepada aset proses organisasi
8) Mengelola keterlibatan stakeholder terkait dalam proyek
9) Berpartisipasi dengan stakeholder terkait untuk mengidentifikasi, menegosiasi dan track ketergantungan kritis
10) Menyelesaikan isu dengan stakeholder terkait
2.7.17 Risk Management (RSKM)
Tujuan dari Risk Management (RSKM) adalah untuk mengidentifikasi masalah potensial sebelum terjadi sehingga risiko kegiatan penanganan dapat direncanakan dan dipanggil sesuai kebutuhan di kehidupan produk atau proyek untuk mengurangi merugikan dampak pada pencapaian tujuan (CMMI Product Team, 2010). Manajemen risiko adalah, terus ke depan proses yang merupakan bagian penting dari manajemen proyek. Manajemen risiko harus membahas masalah yang bisa membahayakan pencapaian tujuan kritis proyek. Terdapat tujuh (7) praktik spesifik yang tercakup dalam area proses ini, yaitu:
1) Menentukan sumber risiko dan kategori
2) Mendefinisikan parameter yang digunakan untuk menganalisa dan mengkategorikan risiko dan parameter yang digunakan untuk mengontrol upaya manajemen risiko
3) Menetapkan dan mengelola strategi yang digunakan untuk manajemen risiko
4) Mengidentifikasi dan mendokumentasikan risiko
5) Mengevaluasi dan mengkategorikan setiap risiko yang teridentifikasi menggunakan kategori risiko dan parameter yang sudah didefinisikan, dan menentukan prioritas
6) Membuat rencana mitigasi risiko sesuai dengan strategi manajemen risiko
7) Memantau status dari setiap risiko secara periodik dan mengimplementasikan rencana mitigasi risikodengan sesuai
2.7.18 Decision Analysis and Resolution (DAR)
Tujuan Decision Analysis and Resolution (DAR) adalah untuk menganalisis keputusan yang mungkin menggunakan proses evaluasi formal untuk mengevaluasi alternatif yang teridentifikasi dengan kriteria yang telah ditetapkan (CMMI Product Team, 2010). Proses Decision Analysis and Resolution melibatkan dan menetapkan pedoman untuk menentukan suatu pengambilan
keputusan harus mengikuti dan menerapkan proses evaluasi formal terhadap masalah. Sebuah proses evaluasi formal adalah pendekatan terstruktur untuk mengevaluasi solusi alternatif terhadap kriteria yang ditetapkan untuk menentukan solusi yang direkomendasikan. Terdapat enam (6) praktik spesifik yang tercakup dalam area proses ini, yaitu:
1) Menetapkan dan mengelola panduan untuk menentukan isu apa yang menjadi subyek proses evaluasi formal
2) Menetapkan dan mengelola kriteria untuk mengevaluasi alternatif dan peringkat relatif dari kriteria ini
3) Mengidentifikasi solusi alternatif untuk menyelesaikan isu
4) Memilih metode evaluasi
5) Mengevaluasi solusi alternatif menggunakan kriteria dan metode yang telah ditetapkan
6) Memilih solusi dari alternatif yang ada berdasarkan kriteria evaluasi
2.7.19 Organizational Process Performance (OPP)
Tujuan Organizational Process Performance (OPM) adalah untuk secara proaktif mengelola kinerja organisasi untuk memenuhi tujuan usahanya (CMMI Product Team, 2010). Area proses
untuk mengelola kinerja organisasi, secara iteratif menganalisis agregat data proyek, mengidentifikasi kesenjangan dalam kinerja terhadap tujuan bisnis, dan memilih serta menggunakan perbaikan untuk menutup kesenjangan. Terdapat lima (5) praktik spesifik yang tercakup dalam area proses ini, yaitu:
1) Menetapkan dan mengelola kualitas dan tujuan kinerja proses
2) Memilih proses
3) Menetapkan pengukuran kinerja proses
4) Menganalisa kinerja dari proses terpilih dan menetapkan dan mengelola baseline kinerja proses
5) Menetapkan dan mengelola model kinerja proses untuk kumpulan proses standar organisasi
2.7.20 Quantitative Project Management (QPM)
Tujuan Quantitative Project Management (QPM) adalah mengelola proyek kuantitatif untuk mencapai kualitas proyek dan kinerja sasaran proses (CMMI Product Team, 2010). Area proses menerapkan konsep-konsep untuk mengelola kelompok lain dan dapat membantu untuk menghubungkan aspek yang berbeda dari kinerja organisasi untuk memberikan dasar dalam menyeimbangkan dan menentukan prioritas yang utama untuk mengatasi satu set yang
lebih luas dari tujuan bisnis. Terdapat tujuh (7) praktik spesifik yang tercakup dalam area proses ini, yaitu:
1) Menetapkan dan mengelola kualitas proyek dan tujuan kinerja proses
2) Menggunakan statistik atau teknik kuantitatif lain, menyusun proses yang terdefinisi yang memungkinkan proyek mencapai tujuan kualitas dan kinerja proses
3) Memilih subproses dan atribut kritis untuk mengevaluasi kinerja dan yang membantu untuk mencapai tujuan kualitas dan kinerja proses proyek
4) Memilih pengukuran dan teknik analisa yang akan digunakan dalam manajemen kuantitatif
5) Memonitor kinerja dari sub proses terpilih menggunakan statistik dan teknik kuantitatif lainnya
6) Mengelola proyek menggunakan statistik dan teknik kuantitatif lainnya untuk menentukan apakah tujuan proyek untuk kualitas dan kinerja proses dapat terpenuhi
7) Melakukan analisa root cause dari isu terpilih untuk memperbaiki defisiensi
2.7.21 Organizational Process Management (OPM)
Tujuan Organizational Process Management (OPM) adalah untuk secara proaktif mengelola kinerja organisasi untuk memenuhi tujuan usahanya (CMMI Product Team, 2010). Area proses
Organizational Process Management memungkinkan organisasi
untuk mengelola kinerja organisasi, secara iteratif menganalisis data proyek agregat, mengidentifikasi kesenjangan dalam kinerja terhadap tujuan bisnis, dan memilih dan menggunakan perbaikan untuk menutup kesenjangan. Terdapat sepuluh (10) praktik spesifik yang tercakup dalam area proses ini, yaitu:
1) Mempertahankan tujuan bisnis berdasarkan pemahaman atas strategi bisnis dan hasil kinerja aktual
2) Menganalisa data kinerja proses untuk menentukan kemampuan organisasi untuk memenuhi tujuan bisnis yang teridentifikasi
3) Mengidentifikasi area potensial untuk peningkatan yang mungkin berkontribusi kepada pemenuhan tujuan bisnis
4) Memperoleh dan mengkategorikan peningkatan yang disarankan
5) Menganalisa peningkatan yang disarankan untuk dampak yang mungkin dalam mencapai tujuan kualitas dan kinerja proses organisasi
7) Memilih dan mengimplementasi peningkatan untuk penyebaran ke seluruh organisasi berdasarkan evaluasi biaya, manfaat dan faktor lainnya
8) Menetapkan dan mengelola rencana untuk menyebarkan peningkatan terpilih
9) Mengelola penyebaran dari peningkatan terpilih
10) Mengevaluasi dampak dari penyebaran peningkatan pada kualitas dan kinerja proses menggunakan teknik statistik dan kuantitatif lainnya
2.7.22 Causal Analysis and Resolution (CAR)
Tujuan Causal Analysis and Resolution (CAR) adalah untuk mengidentifikasi penyebab hasil terpilih dan mengambil tindakan untuk meningkatkan kinerja proses (CMMI Product Team, 2010).
Causal Analysis and Resolution meningkatkan kualitas dan
produktivitas dengan mencegah terjadinya cacat produk atau masalah dan mengidentifikasi secara tepat dalam menggabungkan sumber kinerja proses utama. Terdapat lima (5) praktik spesifik yang tercakup dalam area proses ini, yaitu:
1) Memilih hasil yang akan dianalisa
2) Melakukan analisa kausal dari hasil yang terpilih dan membuat usulan tindakan resolusi
3) Mengimplementasi usulan tindakan terpilih yang dikembangkan dalam analisa kausal
4) Mengevaluasi dampak dari tindakan yang diterapkan pada kinerja proses
5) Mencatat data analisa kausal dan resolusi untuk digunakan ke seluruh proyek dan organisasi
2.8 Penentuan Jumlah Sampel Proyek
Pengerjaan proyek pengembangan aplikasi di dalam sebuah organisasi mungkin dilakukan dengan cara yang berbeda tergantung oleh beberapa karakteristik seperti dibawah ini (O’Toole, Pat., 2012):
1. Proyek kecil mungkin dilakukan secara berbeda dibandingkan dengan proyek yang besar.
2. Proyek yang dikerjakan oleh tim yang berada di kantor pusat mungkin dilakukan dengan metodologi yang berbeda dengan yang dikerjakan oleh tim yang berada di cabang/lokasi lain, dst.
Dalam melakukan pemilihan sampel proyek pengembangan aplikasi, langkah awal yang perlu dilakukan adalah memetakan proyek menggunakan sampling factor. Terdapat beberapa sampling factor yang
harus dipertimbangkan yaitu sebagai berikut (SCAMPI Upgrade Team, 2011):
1. Lokasi (misal: kantor pusat, kantor cabang). 2. Pelanggan (misal: pemerintah, swasta/komersil).
3. Ukuran (misal: jangka pendek, jangka menengah, jangka panjang). 4. Struktur organisasi (misal: unit, departemen).
5. Tipe pekerjaan (misal: pengembangan aplikasi, maintenance).
Sampling factor memberikan pandangan mengenai ragam cara kerja
yang dilakukan dalam perusahaan. Untuk setiap sampling factor, perlu dipastikan apakah pengaturan yang berbeda atas faktor tersebut mempengaruhi cara kerja perusahaan. Jika ya, maka sampling factor tersebut relevan untuk digunakan. Namun, jika tidak, maka sampling
factor tersebut tidak relevan untuk digunakan.
Pemetaan proyek pengembangan aplikasi kepada sampling factor berguna untuk mendapatkan informasi jumlah subgroup yang ada.
Subgroup adalah sebuah cluster dari proyek yang saling memiliki
kesamaan nilai sampling factor dan menunjukkan penerapan proses yang sama (O’Toole, Pat., 2012).
Proses selanjutnya setelah mengetahui jumlah subgroup adalah memasukkan variabel – variabel terkait kedalam formula sampling dibawah untuk mengetahui berapa jumlah minimum sampel proyek yang dibutuhkan dalam melakukan pengukuran.
Gambar 2.8 Formula Sampling (SCAMPI Upgrade Team, 2011)
2.9 Pengukuran Kepatuhan Area Proses CMMI
Pengukuran kepatuhan tiap area proses terkait pada sampel proyek pengembangan aplikasi di Telkomsigma menggunakan pendekatan CMMI. CMMI telah mendefinisikan best practice yang diperlukan untuk setiap area proses agar dapat memenuhi tujuan dari area proses terkait. Pengukuran kepatuhan setiap area proses terhadap CMMI dapat dilakukan dengan meninjau implementasi proses pengembangan aplikasi yang dilakukan oleh organisasi dengan praktik terbaik (best practice) yang didefinisikan dalam CMMI. Suatu area proses dapat dikatakan memuaskan jika tujuan dari setiap area proses tersebut sudah terpenuhi.
Kriteria pengukuran yang digunakan untuk setiap proses pengembangan aplikasi dalam penelitian ini menggunakan kriteria SCAMPI (Standard CMMI Appraisal Method for Process Improvement) seperti yang ditunjukan pada tabel dibawah ini:
Tabel 2.1. Kriteria Pengukuran (SCAMPI Upgrade Team, 2011)
Kriteria Deskripsi
NY: not yet Unit dasar atau fungsi pendukung belum mencapai
tingkat dalam alur kerja, atau dari segi waktu dalam menerapkan praktik.
NI: not implemented
Sebagian atau seluruh data yang dibutuhkan tidak ditemukan atau dinilai sebagai tidak mencukupi, data yang diberikan tidak mendukung kesimpulan bahwa praktik telah diterapkan, dan satu atau lebih kelemahan ditemukan.
PI: partially implemented
Sebagian atau seluruh data yang dibutuhkan untuk penilaian tidak ditemukan atau dinilai sebagai tidak mencukupi, sebagian data tersedia dan memperlihatkan sebagian aspek dari praktik telah diterapkan, dan satu atau lebih kelemahan ditemukan.
LI: largely implemented
Bukti dan/atau afirmasi tersedia dan dinilai sebagai mencukupi untuk mendemonstrasikan penerapan praktik, dan satu atau lebih kelemahan ditemukan.
FI: fully implemented
Bukti dan/atau afirmasi tersedia dan dinilai sebagai mencukupi untuk mendemonstrasikan penerapan praktik, dan tidak ada kelemahan ditemukan.
Kajian terhadap dokumentasi proses, standar dan prosedur yang digunakan oleh organisasi sebagai landasan setiap proses pengembangan aplikasi terhadap kriteria area proses CMMI dilakukan untuk mengetahui apakah proses pengembangan aplikasi yang dilakukan oleh organisasi telah memenuhi tujuan area proses.
