Upload
vuonghuong
View
215
Download
0
Embed Size (px)
Citation preview
BAB II
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
9
10
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.
11
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
12
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).
13
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)
14
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,
sehingga memberikan organisasi sebuah toolset yang terintegrasi.
15
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
staged perusahaan dapat mengetahui maturity level mereka. Model
16
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
17
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)
18
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
19
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
20
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
21
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
22
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
23
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.
24
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
maturity level.
25
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.
26
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,
27
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
12) Mengkaji semua rencana yang mempengaruhi proyek
28
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
7) Mengkaji pencapaian proyek dan hasil
29
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
30
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
31
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
6) Menetapkan dan mengelola arsip configuration item
32
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
33
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
34
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:
1) Membuat solusi alternatif dan kriteria pemilihan
35
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:
36
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
37
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
8) Menganalisa hasil dari seluruh aktivitas verifikasi
38
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
39
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
40
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
5) Menetapkan dan mengelola perpustakaan aset proses organisasi
41
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
7) Menilai efektifitas program pelatihan organisasi
42
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
43
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:
44
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
45
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
Organizational Process Performance memungkinkan organisasi
46
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
47
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
48
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
6) Memvalidasi peningkatan yang terpilih
49
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:
50
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
51
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.
52
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:
53
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.
54
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.