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.