HASIL DAN PEMBAHASAN
4.1 Penentuan Sampel Proyek
Untuk dapat menentukan sampel proyek yang akan digunakan dalam penelitian, sebelumnya perlu dilakukan konfirmasi dengan perusahaan atas sampling factor yang relevan untuk digunakan. Berdasarkan diskusi yang dilakukan, diketahui bahwa beberapa sampling factor yaitu lokasi, pelanggan dan ukuran proyek tidak relevan untuk digunakan. Sementara itu sampling factor lainnya seperti struktur organisasi dan jenis pekerjaan relevan untuk digunakan dalam penelitian. Berikut dibawah ini penjelasan atas konfirmasi sampling factor penelitian.
Tabel 4.1 Sampling Factor dalam Penelitian
No Sampling Factor Deskripsi
1 Lokasi
Tidak relevan.
Hanya terdapat satu lokasi (kantor pusat).
2 Pelanggan
Tidak relevan.
Cara kerja tidak berbeda berdasarkan jenis
pelanggan (misal: bank, perusahaan asuransi, dst).
3 Ukuran Proyek
Tidak relevan.
Cara kerja tidak berbeda berdasarkan ukuran proyek.
Finance and Non Banking Solution Business Unit (FNBS), Banking Solution Business Unit (BAS), Product dan Technology Business (PT)
Unit digambarkan pada struktur organisasi Telkomsigma. Proyek pengembangan aplikasi berasal dari tiga bisnis unit ini. Area proses CMMI yang terpengaruh adalah Engineering process area.
5 Jenis Pekerjaan
Relevan.
Cara kerja dilakukan berbeda berdasarkan tipe pekerjaan, yaitu project development, change request (CR), dan maintenance. Area proses CMMI yang terpengaruh adalah Project Management dan Engineering process area.
4.1.1 Pemetaan Sampel Proyek kepada Sampling Factor
Langkah selanjutnya setelah mengetahui sampling factor yang akan digunakan adalah memetakan daftar proyek yang ada dalam Telkomsigma kedalam sampling factor. Terdapat total 67 proyek yang dilakukan oleh ketiga bisnis unit pada periode April 2012 – Agustus 2013 (masa proyek penerapan CMMI). Pemetaan proyek yang dilakukan dapat dilihat pada Lampiran 1. Berdasarkan pemetaan yang dilakukan, dapat diketahui informasi subgroup (cluster) proyek atau proyek – proyek yang menunjukkan kesamaan. Karena struktur organisasi dan jenis pekerjaan merupakan samping factor yang dapat digunakan maka kemungkinan subgroup yang ada dalam proyek adalah:
Tabel 4.2 Subgroup Proyek yang Mungkin
No Sampling Factor Subgroup yang Mungkin Jumlah 1 Struktur Organisasi FNBS / BAS / PT 3 (i)
2 Jenis Pekerjaan Project development / CR / maintenance
3 (ii)
Total ( i x ii) 9
Berdasarkan Tabel 4.2, diketahui bahwa terdapat 9 subgroup proyek yang mungkin. Untuk dapat mengetahui jumlah subgroup aktual/sebenarnya dari proyek, langkah awal yang dilakukan adalah
mengkombinasikan antara proyek yang telah dipetakan dalam sampling factor (mengacu Lampiran 1) dengan subgroup yang mungkin, seperti tertera pada Tabel 4.3.
Tabel 4.3 Kombinasi antara Subgroup dengan Proyek yang telah dipetakan kedalam Sampling Factor
No Subgroup
Jumlah Proyek dalam Subgroup 1 BAS, Project 52 2 BAS, CR 1 3 BAS, Maintenance 1 4 FNBS, Project 5 5 FNBS, CR 0 6 FNBS, Maintenance 0 7 PT, Project 6 8 PT, CR 1 9 PT, Maintenance 1
Langkah berikutnya adalah mengidentifikasi subgroup yang tidak memiliki proyek (jumlah proyek dengan nilai sama dengan nol) pada Tabel 4.3 untuk mengetahui subgroup aktual. Seperti terlihat dalam tabel tersebut, terdapat 2 subgroup yang tidak memiliki proyek. Sehingga jumlah subgroup aktual adalah 7 subgroup.
4.1.2 Penentuan Jumlah Minimum Sampel Proyek
Jumlah minimum sampel dapat diketahui dengan menggunakan formula dibawah ini:
Gambar 4.1. Formula Perhitungan Minimum Sampel (SCAMPI Version 1.3, 2011)
Sebelumnya, telah diketahui bahwa jumlah total proyek adalah 67 proyek dan jumlah subgroup adalah 7 subgroup. Sehingga perhitungan menggunakan formula diatas dapat dilakukan seperti terlihat pada Tabel 4.4 berikut ini:
Tabel 4.4 Perhitungan Minimum Sampel
No Subgroup Jumlah Proyek dalam Subgroup Perhitungan Jumlah (#) Minimum Sampel Menggunakan Formula Minimum Sampel yang dibutuhkan
1 BAS, Project (BP) 52 #minimum BP = (7x52)/67 = 5.43 5 2 BAS, CR (BC) 1 # minimum BC = (7x1)/67 = 0.10 1 3 BAS, Maintenance (BM) 1 # minimum BM = (7x1)/67 = 0.10 1 4 FNBS, Project (FP) 5 # minimum FP = (7x5)/67 = 0.52 1 5 PT, Project (PP) 6 # minimum PP = (7x6)/67 = 0.60 1 6 PT, CR (PC) 1 # minimum PC = (7x1)/67 = 0.10 1 7 PT, Maintenance (PM) 1 # minimum PM = (7x1)/67 = 0.10 1
Nilai yang didapat dari perhitungan menggunakan formula dibulatkan, sehingga jumlah minimum sampel yang dibutuhkan untuk penelitian dapat ditemukan seperti tertera dalam tabel diatas.
4.1.3 Sampel Proyek Terpilih
Untuk dapat melakukan pengukuran dampak penerapan CMMI dalam Telkomsigma, diperlukan sampel proyek pengembangan aplikasi yang dilakukan sebelum CMMI diterapkan dan sesudah CMMI diterapkan, sehingga dapat dilakukan perbandingan. Berdasarkan diskusi yang dilakukan dengan pihak perusahaan, diketahui bahwa terdapat 2 buah sampel proyek yang sesuai dengan kriteria. Sampel tersebut adalah:
1. Proyek A – proyek pengembangan aplikasi ATM Interaction.
2. Proyek B – proyek pengembangan aplikasi ATM Simulator.
Proyek diatas dikerjakan oleh unit bisnis Finance and Non Banking Solution (FNBS) dengan jenis pekerjaan project development.
4.2 Latar Belakang Sampel Proyek
Proyek pertama yaitu proyek Proyek A – ATM Interaction, yang merupakan proyek pengembangan aplikasi ATM yang berfungsi untuk mensimulasikan interaksi ATM lewat user interface (UI). Sedangkan
proyek kedua yaitu proyek Proyek B – ATM Simulator, yaitu merupakan proyek pengembangan aplikasi simulator ATM serta mengembangkan alat yang berfungsi untuk mensimulasikan komunikasi antara aplikasi ATM dengan simulator ATM.
4.2.1 Proyek A – Proyek pengembangan aplikasi ATM Interaction
Proyek A dimulai pada September 2012 hingga November 2012. Proyek ini bertujuan untuk membangun aplikasi interaksi ATM yang akan digunakan untuk:
1. Menyediakan ATM User Interface (UI) Interaction yang akan digunakan untuk mensimulasikan interaksi ATM.
2. Merekam perintah pengguna dengan cara menyimpan data kedalam script file, script file tersebut dibuat dalam format tertentu (format aplikasi ATM).
3. Aplikasi dapat melakukan script auto-run untuk menjalankan perintah berdasarkan skenario yang ditentukan dalam script file.
Jumlah anggota tim Proyek A terdiri dari 5 orang anggota, yaitu:
a) 1 orang Project Manager (PM)
b) 1 orang Business Analyst (BA)
c) 1 orang System Analyst (SA)
e) 1 orang Software Tester
4.2.2 Proyek B – Proyek pengembangan aplikasi ATM Simulator
Proyek B dimulai pada Januari 2013 hingga April 2013. Proyek ini bertujuan untuk membangun aplikasi simulator ATM yang akan digunakan untuk:
1. Menyediakan aplikasi ATM yang berfungsi untuk mensimulasikan operasi perangkat keras di dalam ATM.
2. Mensimulasikan komunikasi antara aplikasi interaksi ATM dengan simulator ATM.
4. Merekam perintah pengguna dengan cara menyimpan data kedalam script file, script file tersebut dibuat dalam format tertentu (format aplikasi ATM).
5. Aplikasi dapat melakukan script auto-run untuk menjalankan perintah berdasarkan skenario yang ditentukan dalam script file.
Jumlah anggota tim Proyek B terdiri dari 7 orang anggota, yaitu:
a) 1 orang Project Manager (PM)
b) 1 orang Project Administrator (PA)
c) 1 orang Business Analyst (BA)
e) 1 orang Technical Leader (TL)
f) 1 orang Technical Member (TM)/Programmer, dan
g) 1 orang Software Tester
4.3 Gambaran Umum Proses
Proses pengukuran dampak penerapan CMMI pada sampel proyek pengembangan aplikasi di Telkomsigma dilakukan pada maturity level 2 dan maturity level 3. Untuk dapat melakukan pengukuran, peneliti melakukan kajian terhadap dokumentasi sampel proyek terkait dan konfirmasi dengan pihak Telkomsigma, kemudian memetakannya dengan tujuan dari setiap area proses CMMI agar diketahui apakah tujuan tiap area proses sudah terpatuhi/tercapai.
Terdapat beberapa tahapan yang perlu dilakukan dalam proses pengembangan aplikasi di Telkomsigma. Dalam melakukan pengembangan aplikasi tersebut tim proyek pengembangan aplikasi dan unit terkait lainnya perlu mengikuti standar prosedur dan operasi yang berguna dalam memberikan panduan dalam melakukan keseluruhan proyek mulai dari tahapan initiation hingga project tracking. Secara garis besar tahapan proses pengembangan aplikasi yang dilakukan di Telkomsigma dapat dilihat pada Gambar 4.2.
10.0 In
voice Track
ing
11.0 Project
Tracking
4.4 Pengukuran Area Proses CMMI Maturity Level 2
4.4.1 Requirement Management (REQM)
Pengelolaan kebutuhan dilakukan oleh Business Analyst (BA) dan Technical Leader (TL) untuk menggali kebutuhan pelanggan terkait aplikasi yang akan dikembangkan dengan berkomunikasi dengan pelanggan, pengguna sistem, serta pihak lain yang terlibat dalam pengembangan sistem. Berdasarkan hasil pengukuran kepatuhan yang dilakukan untuk area proses REQM, terlihat bahwa pada Proyek A terdapat sub area proses yang masih membutuhkan perbaikan (20% dari total praktik). Hal ini dikarenakan bidirectional traceability antara kebutuhan untuk mengetahui asosiasi antara kebutuhan yang satu dengan kebutuhan lain ketika TL membuat Requirement Verification Matrix (RVM) masih belum diidentifikasi secara lengkap. Berikut adalah hasil pengukuran area proses REQM.
Gambar.4.3 Hasil Pengukuran Area Proses REQM
Sementara berdasarkan analisa area proses REQM pada proyek B, pengelolaan bidirectional requirement antara kebutuhan yang satu dengan yang lain telah dilakukan. Secara umum, praktik – praktik yang dilakukan pada kedua proyek telah berjalan dengan baik seperti yang dapat dilihat pada tabel berikut.
Tabel 4.5 Hasil Pengukuran Area Proses REQM
Area Proses: Requirement Management (REQM)
No Deskripsi Praktik Proyek A Status Proyek B Status 1 Mengembangkan pemahaman dengan penyedia kebutuhan
Business Analyst (BA) terlibat dalam pengumpulan dan pengembangan kebutuhan dengan pelanggan. Kebutuhan didokumentasikan dalam Software Requirement Specification (SRS), Requirement Verification Matrix (RVM), dan Test Scenario.
FI
Business Analyst (BA) terlibat dalam
pengembangan kebutuhan. Dokumen terkait seperti SRS, RVM, dan Test Scenario telah didokumentasikan. FI 2 Mendapatkan komitmen atas kebutuhan
Internal Work Order (IWO) digunakan sebagai dokumen bukti komitmen inisiasi proyek. Dokumen juga telah disimpan dalam repositori proyek.
FI
IWO dan Quotation
digunakan sebagai dokumen bukti komitmen inisiasi proyek. Dokumen juga telah disimpan dalam repositori proyek. FI 3 Mengelola perubahan terhadap kebutuhan
Tidak terdapat permintaan
perubahan kebutuhan. FI
Tidak terdapat permintaan
perubahan kebutuhan. FI 4 Mengelola bidirectional traceability antara kebutuhan – kebutuhan dan work product
Pada Proyek A digunakan Requirement Verification Matrix (RVM) untuk mengelola bidirectional traceability antara
kebutuhan. Namun, terdapat informasi yang hilang dalam RVM (code package dan unit test yang terkait dengan kebutuhan) yang seharusnya dilengkapi oleh Technical Leader (TL).
LI
Pengelolaan bidirectional traceability pada Proyek B menggunakan RVM. Dikarenakan tidak terdapat permintaan perubahan dari klien, RVM tidak mengalami perubahan dari saat pertama kali dibuat.
Area Proses: Requirement Management (REQM) No Deskripsi Praktik Proyek A St at us Proyek B St at us 5 Memastikan penyelarasan antara kebutuhan dan aktivitas proyek Penyelarasan antara kebutuhan dan aktivitas terlihat dari adanya revisi dan pembaharuan pada jadwal dan estimasi upaya yang diperlukan dalam Proyek A.
FI
Jadwal proyek telah dibuat dalam Project Schedule Proyek B. Terdapat beberapa revisi jadwal proyek, hal ini terlihat dari beberapa update versi jadwal. Revisi tersebut memiliki dasar, karena beberapa hal:
- Penambahan jadwal kick-off meeting
- Pertimbangan untuk melakukan parallel task - Penambahan kalender hari libur
- Penambahan effort untuk periodik progress review
FI
4.4.2 Project Planning (PP)
Setelah proyek telah didapatkan, Project Manager (PM) harus membuat beberapa dokumen perencanaan yang terdiri dari jadwal keseluruhan proyek, project management plan, daftar risiko dan isu proyek, serta aset/tools yang akan digunakan. Berdasarkan observasi yang dilakukan, masih terdapat beberapa item yang memerlukan perbaikan dalam Proyek A dimana 36% praktik belum diterapkan (mengacu pada gambar 4.4), yaitu mencakup belum adanya perencanaan untuk aktivitas audit proyek, belum terdapat identifikasi dari stakeholder terkait, serta belum dilakukannya kajian terhadap perencanaan proyek.
Gambar.4.4 Hasil Pengukuran Area Proses PP
Sementara itu, sebanyak 36% praktik lainnya tidak sesuai dengan praktik yang diharapkan dikarenakan beberapa aktivitas seperti estimasi upaya, waktu dan biaya yang dibutuhkan, anggaran, identifikasi risiko proyek, rencana pengelolaan data, identifikasi kompetensi yang dibutuhkan, serta audit dan metrik pengukuran belum didefinisikan dengan tepat dalam Proyek A. Pada Proyek B, terdapat beberapa kelemahan minor terkait tidak diperbaharuinya ProcTail (untuk mengetahui anggaran dan biaya aktual proyek) dan Risk & Issue List (untuk mengetahui status risiko atau isu yang teridentifikasi) selama proyek berlangsung. Hasil pengukuran untuk area proses PP dapat dilihat pada tabel dibawah ini.
Tabel 4.6 Hasil Pengukuran Area Proses PP
Area Proses: Project Planning (PP)
No Deskripsi Praktik Proyek A Status Proyek B Status 1 Menetapkan Work Breakdown Structure (WBS) dan mengestimasi lingkup proyek
WBS telah ditetapkan dalam dokumen Project Schedule yang tersedia dalam bentuk .mpp (format Microsoft Project). Waktu yang digunakan untuk aktivitas audit belum dialokasikan.
PI
WBS telah ditetapkan dalam dokumen Project Schedule. Waktu yang digunakan untuk melakukan proyek, project status review (weekly/monthly meeting, client update meeting), deliverable review (review SRS, SAD, dst) dan audit telah dialokasikan.
FI
2 Mengestimasi produk kerja dan atribut tugas
Berdasarkan observasi, estimasi untuk produk kerja dan atribut tugas dalam Proyek A telah dibuat, namun estimasi tidak dibuat sesuai dengan metode estimasi organisasi (misal: Function Point Calculation).
PI
Estimasi produk kerja dan atribut tugas telah tersedia dalam bentuk Function Point Calculation (FPC) yang disiapkan oleh Account Manager. Estimasi yang dilakukan mencakup jenis kompleksitas proyek, aktivitas yang dilakukan dalam proyek, upaya, mandays serta biaya.
FI
3 Mendefinisikan siklus hidup proyek
Siklus hidup proyek A dibuat sesuai dengan panduan Project Lifecycle. Hal ini juga terlihat pada dokumen perencanaan proyek dan jadwal proyek.
FI
Siklus hidup proyek B dibuat sesuai dengan
panduan Project Lifecycle. FI
4 Mengestimasi upaya dan biaya proyek
Mengacu pada no.2.
NI Mengacu pada no.2. FI
5 Menetapkan dan mengelola jadwal dan anggaran proyek
Jadwal proyek dikelola dalam dokumen Project Schedule. Berdasarkan observasi, tidak ditemukan dokumentasi pengelolaan anggaran proyek selama proyek berlangsung.
NI
Jadwal proyek dikelola dalam dokumen Project Schedule, diketahui bahwa tidak terdapat perubahan jadwal proyek. Anggaran proyek dikelola
menggunakan ProcTail (Project Costing Detail) untuk mengetahui anggaran yang tersedia, biaya aktual dan anggaran yang tersisa. Namun biaya aktual tidak dokumentasikan sehingga tidak diketahui berapa jumlah biaya anggaran yang terpakai dan sisa anggaran.
Area Proses: Project Planning (PP) No Deskripsi Praktik Proyek A St a tus Proyek B St a tus 6 Mengidentifikasi dan menganalisa risiko proyek
Meskipun risiko telah diidentifikasi dan didokumentasikan dalam Risk & Issue List (RIL), namun berdasarkan observasi, tidak ditemukan adanya rencana manajemen risiko (misal: frekuensi untuk mengupdate RIL) untuk memitigasi risiko yang teridentifikasi dalam Proyek A.
NI
Rencana manajemen risiko telah dicakup dalam dokumen Project
Management Plan. Risiko dan isu yang teridentifikasi dalam proyek dicatat dalam Risk & Issue List yang diperbaharui setiap minggu sekali. Namun ditemukan bahwa RIL tidak
diperbaharui (status risiko masih 'In Progress' hingga proyek berakhir) LI 7 Merencanakan pengelolaan data (data management plan) proyek
Tidak ditemukan adanya rencana pengelolaan data pada Proyek A, misal: frekuensi untuk melakukan backup pada proyek data, kriteria untuk melakukan restore data, dan data security requirement.
NI
Rencana pengelolaan data proyek telah ditetapkan dalam Project Management Plan (frekuensi backup, media backup, lokasi backup). FI 8 Merencanakan sumber daya untuk melakukan proyek
Struktur tim proyek serta tugas tanggung jawab masing - masing telah tersedia serta
didokumentasikan dalam Project Management Plan.
FI
Struktur tim proyek telah ditetapkan dimana stakeholder terkait telah diidentifikasi serta tim proyek (Project Manager, Project Admin, Business Analyst, Technical Leader, System Analyst, Tester, dst) telah ditetapkan. FI 9 Merencanakan pengetahuan dan kompetensi yang dibutuhkan untuk melakukan proyek
Tidak ditemukan adanya perencanaan pengetahuan dan identifikasi kompetensi yang dibutuhkan dalam Proyek A.
NI
Untuk Proyek B, pengetahuan yang
dibutuhkan oleh tim proyek adalah pemahaman
mengenai proses implementasi proyek di Telkomsigma,
pemahamanan penggunaan version control tools untuk mengelola source code dan dokumentasi, serta
pengalaman dalam
pemrograman C++ dan C#. Berdasarkan identifikasi gap pengetahuan tim proyek dengan kebutuhan pengetahuan diatas, tidak terdapat kebutuhan untuk training.
Area Proses: Project Planning (PP) No Deskripsi Praktik Proyek A St a tus Proyek B St a tus 10 Merencanakan keterlibatan stakeholder yang teridentifikasi
Meskipun struktur tim proyek telah tersedia, namun keterlibatan setiap
stakeholder terkait dalam Proyek A belum
diidentifikasi. PI
Keterlibatan setiap
stakeholder dalam Proyek B telah diidentifikasi dengan menggunakan RACI (Responsible, Accountable, Consult, Inform) matrix. Sebagai contoh: dalam proses requirement gathering Business Analyst berstatus R dan A, sedangkan Project Manager berstatus I. FI 11 Menetapkan dan mengelola perencanaan proyek
Pengelolaan proyek sudah tersedia, dimana mencakup pengelolaan konfigurasi, review dan eskalasi, namun aktivitas audit serta metrik proyek belum ditetapkan.
PI
Pengelolaan proyek sudah tersedia, dimana mencakup pengelolaan konfigurasi, review dan eskalasi, serta metrik proyek (client satisfaction index, effort variance, UAT success rate) telah ditetapkan. FI 12 Mengkaji semua rencana yang mempengaruhi proyek
Kajian untuk rencana proyek telah dilakukan. Namun, kajian terhadap Project Management Plan tidak ditemukan.
PI
Kajian terhadap seluruh perencanaan proyek telah dilakukan. Kajian
dilaksanakan setiap minggu dan diikuti oleh seluruh anggota tim proyek terkait. Hal - hal yang dibahas termasuk risiko dan isu yang teridentifikasi, progress proyek, defect yang teridentifikasi, serta status deliverables. FI 13 Merubah project plan untuk merekonsiliasi dan mengestimasi sumber daya yang tersedia
Jadwal proyek dan rencana proyek telah direvisi sesuai
dengan kebutuhan proyek. FI
Jadwal proyek dan rencana proyek telah direvisi sesuai
dengan kebutuhan proyek. FI
14 Mendapatkan komitmen dari stakeholder terkait
Telah terdapat komitmen stakeholder. Seluruh tim proyek turut serta dalam kick-off meeting.
FI
Stakeholder (misal: tim QA) telah turut serta pada rapat - rapat penting (readiness meeting) sebagai bukti komitmennya terhadap proyek.
FI
Pada Proyek B, seluruh area proses PP telah berjalan dengan baik. Hal ini dikarenakan rencana yang mendefinisikan kegiatan
proyek meliputi atribut produk kerja dan tugas, sumber daya yang dibutuhkan, keterlibatan dan komitmen stakeholder hingga analisa risiko telah dilakukan secara menyeluruh.
4.4.3 Project Monitoring and Control (PMC)
PM bertanggung jawab untuk seluruh proses monitoring dan control proyek. Tujuan proses monitoring dan control yang dilakukan adalah untuk memberikan pemahaman atas kinerja proyek sehingga corrective action dapat dilakukan jika proyek tidak berjalan sesuai rencana. Untuk area proses PMC, praktik – praktik yang dilakukan pada Proyek A belum sepenuhnya dilakukan sesuai harapan. Pada Proyek A, beberapa komponen risiko proyek (misal: impact rate, occurrence probability, priority) masih belum diidentifikasi secara lengkap sehingga pengawasan terhadap risiko tidak dapat dilakukan secara maksimal. Selain itu, pengelolaan data proyek belum dilakukan secara konsisten.
Gambar. 4.5 Hasil Pengukuran Area Proses PMC
Peningkatan proses PMC dapat dilihat pada proyek B. Proses pengawasan pada Proyek B telah dilakukan dengan baik, dimana komponen – komponen risiko telah diidentifikasi dengan lengkap dan rencana pengelolaan data proyek telah ditetapkan dan dilakukan selama proyek berlangsung.
Tabel 4.7 Hasil Pengukuran Area Proses PMC
Area Proses: Project Monitoring and Control (PMC)
No Deskripsi Praktik Proyek A St a tus Proyek B St a tus 1 Memantau nilai aktual dari perencanaan proyek
Jadwal proyek dan timesheet tim proyek diperbaharui selama proyek. Meeting status proyek telah dilakukan sesuai rencana.
FI
Jadwal proyek dan timesheet tim proyek diperbaharui selama proyek. Meeting status proyek telah dilakukan sesuai rencana.
FI
2 Memantau komitmen
Weekly progress review reports yang dilaporkan kepada project steering commitee tersedia.
FI Weekly progress review reports yang dilaporkan
kepada project steering commitee.
FI
3 Memantau risiko Risiko dan isu yang
teridentifikasi dalam proyek dicatat dalam Risk & Issue List. Namun beberapa komponen risiko (misal: impact rate, occurrence probability, priority) tidak diidentifikasi pada proyek A.
PI
Rencana manajemen risiko telah dicakup dalam dokumen Project
Management Plan. Risiko dan isu yang teridentifikasi dalam proyek dicatat dalam Risk & Issue List yang diperbaharui setiap minggu sekali.
FI
4 Memantau pengelolaan data proyek
Tidak terdapat rencana
pengelolaan data proyek. NI
Pengelolaan data telah dilakukan sesuai dengan perencanaan proyek
FI
5 Memantau keterlibatan stakeholder
Stakeholder terlibat pada saat readiness meeting dan meeting status proyek.
FI Stakeholder terlibat pada saat readiness meeting dan
meeting status proyek.
FI
6 Mengkaji secara periodik kemajuan proyek, kinerja dan isu
Meeting status proyek telah dilakukan sesuai rencana proyek. Hasil meeting dicatat dalam minutes of meeting dan tersedia dalam
FI
Meeting status proyek telah dilakukan sesuai rencana proyek. Meeting status proyek mencakup pembahasan mengenai
Area Proses: Project Monitoring and Control (PMC) No Deskripsi Praktik Proyek A St a tus Proyek B St a tus
repositori proyek. kinerja proyek, status, serta
risiko dan isu yang
teridentifikasi selama proyek berlangsung.
7 Mengkaji
pencapaian proyek dan hasil
Jadwal proyek dikelola selama proyek berlangsung. Revisi dilakukan jika perlu.
FI Jadwal proyek dikelola selama proyek berlangsung.
Revisi dilakukan jika perlu.
FI 8 Mengumpulkan dan menganalisa isu dan menentukan corrective action
Isu yang teridentifikasi dibahas pada meeting status proyek untuk menentukan corrective action yang diperlukan.
FI
Isu yang teridentifikasi dibahas pada meeting status proyek untuk menentukan corrective action yang diperlukan.
FI
9 Melakukan corrective action pada isu yang teridentifikasi
Isu yang teridentifikasi dibahas pada meeting status proyek untuk menentukan corrective action yang diperlukan.
FI
Isu yang teridentifikasi dibahas pada meeting status proyek untuk menentukan corrective action yang diperlukan. FI 10 Mengelola corrective action hingga terselesaikan
Isu yang teridentifikasi dibahas pada meeting status proyek untuk menentukan corrective action yang diperlukan.
FI
Isu yang teridentifikasi dibahas pada meeting status proyek untuk menentukan corrective action yang diperlukan.
FI
4.4.4 Supplier Agreement Management (SAM)
Area proses SAM bertujuan mengelola akuisisi produk dan jasa dari pemasok. Berdasarkan observasi, tidak terdapat penggunaan pemasok (supplier) pada Proyek A maupun Proyek B dikarenakan aplikasi yang dikembangkan dibuat secara in-house.
Gambar. 4.6 Hasil Pengukuran Area Proses SAM
Seperti yang terlihat pada Gambar 4.6, kedua proyek telah memenuhi praktik yang diharapkan pada area proses SAM. Hal ini dikareakan organisasi telah memiliki prosedur penggunaan pemasok dan akuisisi produk untuk proyek pengembangan aplikasi yang menggunakan pemasok, yang mencakup prosedur pemilihan pemasok, tipe produk yang dapat akuisisi, serta prosedur penetapan perjanjian dengan pemasok. Agar lebih jelas, dapat dilihat pada tabel berikut ini.
Tabel 4.8 Hasil Pengukuran Area Proses SAM
Area Proses: Supplier Agreement Management (SAM)
No Deskripsi Praktik Proyek A Status Proyek B Status 1 Menentukan tipe akuisisi untuk tiap produk atau komponen produk yang akan diakuisisi
N/A. Tidak terdapat proses akusisi pada proyek A. Sebagai informasi, organisasi telah memiliki prosedur pengelolaan pemasok yang mengatur mengenai tipe produk atau komponen yang dapat diakuisisi dalam proyek yaitu:
- Sub sistem (misal: sistem navigasi/GPS module) - Software
- Hardware
- Dokumentasi (misal: manual instalasi, manual operator, manual user) - Bagian dan material (misal: switch, raw material)
FI
N/A. Tidak terdapat proses akusisi pada proyek B.
FI 2 Memilih pemasok berdasarkan evaluasi kemampuan mereka untuk dapat memenuhi kebutuhan yang ditentukan dan kriteria yang ditetapkan
N/A. Tidak terdapat penggunaan pemasok pada proyek A. Sebagai informasi, organisasi telah memiliki prosedur evaluasi pemasok yaitu mencakup tipe akuisisi yang akan dilakukan dan kriteria produk/komponen produk yang akan diakuisi (misal: harga, dukungan sistem, batasan, dsb). Evaluasi pemasok dilakukan oleh PM.
FI
N/A. Tidak terdapat penggunaan pemasok pada proyek B. FI 3 Menetapkan dan mempertahankan perjanjian pemasok (supplier agreement)
N/A. Tidak terdapat penggunaan pemasok pada proyek A. Sebagai informasi, organisasi telah memiliki Setelah kriteria yang diharapkan telah terpenuhi. Selanjutnya bagian Legal akan menetapkan perjanjian kerja dengan pemasok yang terpilih.
FI
N/A. Tidak terdapat penggunaan pemasok pada proyek B. FI 4 Melakukan aktivitas dengan pemasok seperti yang ditentukan dalam perjanjian pemasok
N/A. Tidak terdapat penggunaan pemasok pada
proyek A. FI
N/A. Tidak terdapat penggunaan pemasok pada
Area Proses: Supplier Agreement Management (SAM) No Deskripsi Praktik Proyek A Status Proyek B Status 5 Memastikan bahwa perjanjian pemasok memuaskan sebelum menerima produk yang diakuisisi
N/A. Tidak terdapat penggunaan pemasok pada
proyek A. FI
N/A. Tidak terdapat penggunaan pemasok pada
proyek B. FI
6 Memastikan transisi produk yang diakuisisi dari supplier
N/A. Tidak terdapat penggunaan pemasok pada proyek A.
FI N/A. Tidak terdapat penggunaan pemasok pada
proyek B.
FI
4.4.5 Measurement and Analysis (M&A)
Project Manager (PM) bertugas untuk mengukur pencapaian proyek sebagai bagian dari laporan progress proyek. Penetapan obyektif pengukuran dilakukan di awal proyek. Obyektif pengukuran yang dapat digunakan untuk proyek pengembangan aplikasi dalam organisasi adalah:
a) Client satisfaction index, disiapkan pada akhir fase proyek dengan target 70% index kepuasan pelanggan.
b) Effort variance, disiapkan setiap meeting status proyek dan pada fase akhir proyek dengan target dibawah 15% variance.
c) Defect density, disiapkan pada akhir fase proyek dengan target 2.25 defect/FP.
d) Schedule performance index, disiapkan setiap meeting status proyek dan pada fase akhir proyek dengan target 76% kinerja.
e) Client performance index, disiapkan setiap meeting status proyek dan pada fase akhir proyek dengan target 83% kinerja.
f) User Acceptance Test (UAT) success rate, disiapkan setelah UAT dilakukan dengan target 100%.
Gambar. 4.7 Hasil Pengukuran Area Proses M&A
Terdapat beberapa praktik pada Proyek A yang belum memenuhi harapan, salah satunya adalah terkait dengan belum adanya target obyektif pengukuran sehingga analisa pada obyektif pengukuran tidak bisa dilakukan dengan maksimal. Namun, perbaikan proses terlihat dimana praktik yang belum sesuai harapan pada Proyek A telah diperbaiki pada Proyek B. Berikut dibawah adalah hasil pengukuran pada area proses M&A.
Tabel 4.9 Hasil Pengukuran Area Proses M&A
Area Proses: Measurement & Analysis (M&A)
No Deskripsi Praktik Proyek A
Status Proyek B Status 1 Menetapkan dan mempertahankan objektif pengukuran
Pengukuran yang dilakukan terbatas pada pengukuran jumlah defect yang ditemukan saat review.Tidak terdapat obyektif/perencanaan pengukuran untuk metrik pengukuran lain pada Proyek A.
PI
Objektif pengukuran telah tersedia pada dokumentasi perencanaan proyek. Terdapat beberapa objektif pengukuran yaitu:
- Client Satisfaction Index (CSI)
- Effort Variance - UAT Success Rate Ketiga objektif pengukuran diatas diawasi oleh Project Manager selama proyek berlangsung dan
dilaporkan sebagai laporan kinerja proyek. FI 2 Menentukan pengukuran untuk mengakomodasi objektif pengukuran Tidak terdapat obyektif/perencanaan pengukuran pada Proyek A.
NI
Masing - masing objektif pengukuran telah memiliki target masing - masing, seperti dibawah ini: - Client Satisfaction Index (CSI), target: 85% - Effort Variance, target: 15%
- UAT Success Rate, target 100% FI 3 Menentukan bagaimana data pengukuran akan didapatkan dan disimpan Tidak terdapat obyektif/perencanaan pengukuran pada Proyek A.
NI
Pengukuran atas objektif pengukuran didapatkan melalui:
- Client Satisfaction Index (CSI), input/feedback dari pelanggan
- Effort Variance, membandingkan antara effort yang direncanakan pada IWO dengan effort actual
- UAT Success Rate, hasil UAT dimana tidak terdapat critical/major bugs. Data pengukuran disimpan dalam repositori proyek.
FI 4 Menentukan bagaimana data pengukuran akan dianalisa dan di komunikasikan Tidak terdapat obyektif/perencanaan
pengukuran pada Proyek A. NI
Organisasi telah menetapkan prosedur dalam melakukan analisa data. Hasil pengukuran data tersebut akan
Area Proses: Measurement & Analysis (M&A)
No Deskripsi Praktik Proyek A
Status Proyek B Status dikomunikasikan lewat diakhir proyek 5 Mendapatkan data pengukuran yang ditentukan
Data pengukuran defect tersedia dan hasil pengukuran dicatat pada Closing Project
Presentation.
FI
Data pengukuran tersedia dan hasil pengukuran dicatat pada Closing Project Presentation.
FI
6 Menganalisa dan menerjemahkan data pengukuran
Mengacu pada no.5.
FI Mengacu pada no.5. FI
7 Mengelola dan menyimpan data pengukuran
Data pengukuran defect tersedia dan hasil pengukuran dicatat pada Closing Project
Presentation.
FI
Data pengukuran tersedia
dalam repositori proyek B. FI
8 Mengkomunikasikan hasil pengukuran dan analisa
Data pengukuran defect tersedia dan hasil pengukuran dicatat pada Closing Project Presentation. FI Hasil pengukuran dikomunikasikan lewat Closing Project Presentation. FI
4.4.6 Process and Product Quality Assurance (PPQA)
Aktivitas audit pada proyek dilakukan oleh Quality Assurance (QA) dan Auditor untuk memastikan proses dan komponen produk yang dihasilkan pada proyek sesuai dengan kualitas yang diharapkan. PM bertanggung jawab untuk merencanakan jadwal audit selama proyek berlangsung. Ringkasan hasil pengukuran untuk area proses PPQA dapat dilihat pada gambar dibawah.
Gambar. 4.8 Hasil Pengukuran Area Proses PPQA
Beberapa praktik pada Proyek A masih belum memenuhi harapan dimana tidak ditemukan adanya perencanaan aktivitas audit untuk Proyek A. Selain itu audit untuk Software Requirement Specification (SRS) tidak dilakukan. Tabel 4.6 menunjukan hasil pengukuran untuk PPQA.
Tabel 4.10 Hasil Pengukuran Area Proses PPQA
Area Proses: Process and Product Quality Assurance (PPQA)
No Deskripsi Praktik Proyek A
Status Proyek B Status 1 Secara objektif mengevaluasi proses terpilih yang dilakukan dengan deskripsi proses, standar dan prosedur yang berlaku
Tidak ditemukan
perencanaan aktivitas audit untuk Proyek A. Audit yang dilakukan tidak mencakup deliverable penting (misal: SRS, SAD).
NI
Perencanaan aktivitas audit untuk proyek B telah ditetapkan. Audit yang dilakukan mencakup deliverable audit (misal: SRS, SAD).
FI
2 Secara objektif mengevaluasi produk kerja dan layanan terpilih dengan deskripsi proses, standar dan prosedur yang
Tidak ditemukan hasil audit untuk SRS.
PI
Mengacu pada no.1.
Area Proses: Process and Product Quality Assurance (PPQA)
No Deskripsi Praktik Proyek A
St at us Proyek B St at us berlaku 3 Mengkomunikasikan isu terkait kualitas dan memastikan penyelesaian atas isu ketidakpatuhan
Project Manager (PM) bertanggung jawab dalam pengawasan terhadap defect/finding terkait dengan deliverable. Setiap temuan dicatat dalam laporan audit dengan memasukkan sumber temuan, deskripsi, tipe, status, dan target penyelesaiannya.
FI
Setiap temuan telah dicatat dalam laporan audit dengan memasukkan sumber temuan, deskripsi, tipe, status, dan target
penyelesaiannya. FI
4 Menetapkan dan mengelola rekaman dari aktivitas quality assurance
Pada akhir proyek, rekaman atas aktivitas proyek dikumpulkan untuk menjadi sebuah lesson learn bagi organisasi. Lesson learn yang dikumpulkan diantaranya adalah efektifitas
metodologi siklus hidup proyek, kerjasama tim, komunikasi, aktivitas kajian mingguan, dan isu yang teridentifikasi selama proyek.
FI
Lesson learned telah didentifikasi dan didokumentasikan untuk menjadi pembelajaran bagi proyek serupa berikutnya.
FI
4.4.7 Configuration Management (CM)
PM bertanggung jawab dalam membuat configuration management plan diawal fase perencanaan proyek yang meliputi identifikasi konfigurasi, manajemen konfigurasi library, hak akses, version control, dan prosedur pengendalian perubahan dalam proyek. Akses ke anggota tim disediakan sesuai dengan kebutuhan dan dikelola oleh Configuration Librarian. Jenis akses yang diberikan dapat berupa Read Only, Read-Write, dan Read-Write-Delete.
Gambar. 4.9 Hasil Pengukuran Area Proses CM
Berdasarkan observasi, tidak terdapat configuration management plan pada Proyek A. Sementara itu, Proyek B telah menerapkan configuration management plan sesuai tujuan praktik. Berikut dibawah ini adalah observasi pada area proses CM.
Tabel 4.11 Hasil Pengukuran Area Proses CM
Area Proses: Configuration Management (CM)
No Deskripsi Praktik Proyek A Status Proyek B Status 1 Mengidentifikasi configuration item, komponen dan produk kerja terkait
Tidak ditemukan adanya configuration management plan dan identifikasi configuration item pada
proyek A. NY
Configuration item (CI) telah diidentifikasi pada proyek B. Berikut daftar configuration item pada Proyek B:
- Project Management Plan - Software Requirement and Specification (SRS) - Software Architecture Document (SAD) - Source code FI 2 Menetapkan dan mempertahankan manajemen konfigurasi dan manajemen
Tidak ditemukan adanya configuration management plan dan identifikasi configuration item pada proyek A.
NY
Configuration management plan untuk proyek B mencakup identifikasi CI, configuration management library, permission, version
Area Proses: Configuration Management (CM) No Deskripsi Praktik Proyek A Status Proyek B Status
perubahan control dan change control
dalam proyek. 3 Membuat atau
merilis baseline untuk penggunaan internal dan untuk penyampaian ke pelanggan
Tidak ditemukan adanya configuration management plan dan identifikasi configuration item pada
proyek A. NY
Beberapa kriteria untuk menetapkan baseline dan merevisi baseline CI telah ditetapkan yaitu:
- Setelah dilakukan kajian/review
- Setelah mendapatkan pengesahan dari pelanggan - Setelah dilakukan code review (untuk source code)
FI
4 Melakukan track permintaan perubahan atas configuration item
Tidak ditemukan adanya configuration management plan dan identifikasi configuration item pada proyek A.
NY
N/A. Tidak terdapat perubahan CI dalam proyek
B. FI
5 Mengendalikan perubahan atas configuration item
Tidak ditemukan adanya configuration management plan dan identifikasi configuration item pada proyek A.
NY
N/A. Tidak terdapat perubahan CI dalam proyek
B. FI
6 Menetapkan dan mengelola arsip configuration item
Tidak ditemukan adanya configuration management plan dan identifikasi configuration item pada proyek A.
NY
Organisasi telah menetapkan repositori proyek yang digunakan untuk menyimpan configuration item. Untuk dapat mengelola versi dokumen, organisasi menggunakan SVN (version control tools). FI 7 Melakukan audit konfigurasi untuk mempertahankan integritas atas baseline konfigurasi
Tidak ditemukan adanya configuration management plan dan identifikasi configuration item pada proyek A.
NY
N/A. Tidak terdapat perubahan CI dalam proyek
4.5 Pengukuran Area Proses CMMI Maturity Level 3
4.5.1 Requirement Development (RD)
Setelah seluruh kebutuhan pelanggan atas aplikasi yang akan dikembangkan telah teridentifikasi. BA bertanggung jawab dalam menyiapkan SRS yang berguna untuk memberikan pemahaman mengenai produk (hasil) yang akan diberikan dan tidak, termasuk manfaat dan tujuan dari produk yang akan dibuat, serta apakah produk merupakan modul tambahan, pengganti, atau produk baru. Berdasarkan observasi, Proyek A maupun Proyek B telah menjalankan praktik sesuai dengan tujuan dari praktik. Hal ini dapat dilihat pada gambar dibawah.
Gambar. 4.10 Hasil Pengukuran Area Proses RD
Berdasarkan pengukuran, kedua proyek telah memenuhi tujuan praktik. Kebutuhan dan harapan stakeholder, antar muka yang
dibutuhkan, skenario dan konsep operasional aplikasi serta validasi telah diakomodasi dengan baik.
Tabel 4.12 Hasil Pengukuran Area Proses RD
Area Proses: Requirement Development (RD)
No Deskripsi Praktik Proyek A Status Proyek B Status 1 Memperoleh kebutuhan, harapan stakeholder, batasan dan antar muka untuk seluruh fase siklus produk
Kebutuhan, harapan stakeholder, batasan dan antar muka produk telah diakomodasi dalam Software Requirement Specification (SRS) yang disiapkan oleh Business Analyst (BA) .
FI
Kebutuhan, harapan stakeholder, batasan dan antar muka produk telah diakomodasi dalam SRS yang disiapkan oleh BA .
FI
2 Mentransformasi kebutuhan stakeholder, harapan, batasan dan antar muka menjadi kebutuhan pelanggan
Pengembangan SRS telah mengikuti prosedur organisasi agar dapat mentransformasi kebutuhan pelanggan.Terdapat tiga level kebutuhan yaitu: - High, kebutuhan termasuk kategori penting dan harus diakomodasi pada saat rilis produk
- Medium, kebutuhan termasuk kategori penting namun dapat diakomodasi pada rilis produk berikutnya jika diperlukan
- Low, kebutuhan tidak termasuk kategor penting, lebih bersifat 'nice to have'. Revision history pada SRS selalu dicatat, sebagai bukti SRS telah direview dan baseline telah ditetapkan.
FI
SRS telah dibuat, revision history telah dikelola dengan baik dan baseline SRS telah ditetapkan. FI 3 Menetapkan dan mengelola kebutuhan produk dan komponen produk, dimana didasarkan atas kebutuhan pelanggan
Kebutuhan dibuat dalam beberapa bentuk yaitu kebutuhan domain aplikasi, teknologi, dan kebutuhan software. Jika terjadi perubahan setelah SRS di sign off, maka harus mengikuti prosedur change management.
FI
Kebutuhan dibuat dalam beberapa bentuk yaitu kebutuhan fungsional dan non fungsional, kebutuhan kinerja (performance) dan kebutuhan keamanan (security). Jika terjadi perubahan setelah SRS di sign off, maka harus mengikuti prosedur change management.
Area Proses: Requirement Development (RD) No Deskripsi Praktik Proyek A Stat u s Proyek B Stat u s 4 Mengalokasi kebutuhan untuk tiap komponen produk
Komponen produk yang dikembangkan dalam proyek A telah diidentifikasi. dua (2) komponen utama yang dikembangkan, yaitu: - ATM simulator with IE plugin, berfungsi untuk menerima perintah dari software ATM kemudian merespon kembali ke ATM hardware (misal:
memasukan/ mengeluarkan kartu ATM)
- ATM automatic operation software, berfungsi untuk menangkap dan merekam interaksi user dalam ATM software dan ATM simulator
FI
Komponen produk yang dikembangkan dalam proyek B telah diidentifikasi. Tiga (3) komponen utama yang dikembangkan, yaitu: - ATM software, berfungsi sebagai interaksi user dalam layar ATM
- ATM simulator with IE plugin, berfungsi untuk menerima perintah dari software ATM kemudian merespon kembali ke ATM hardware (misal:
memasukan/ mengeluarkan kartu ATM)
- ATM automatic operation software, berfungsi untuk menangkap dan merekam interaksi user dalam ATM software dan ATM simulator
FI
5 Mengidentifikasi kebutuhan antar muka
Identifikasi kebutuhan antar muka telah tersedia dalam Software Architecture Design (SAD). Antar muka pengguna dijelaskan dalam diagram alur navigasi antar muka.
FI
Kebutuhan antar muka dicatat dalam dokumentasi SAD. Antar muka yang dibutuhkan telah diidentifikasi oleh TL misalnya seperti antar muka untuk fungsi withdrawal, card deposit dan passbook deposit. FI 6 Menetapkan dan mengelola konsep operasional dan skenario terkait
Skenario operasional telah tersedia yang bertujuan untuk mengetahui interaksi pengguna dalam ATM. Skenario yang digunakan adalah:
- Record user command - Playback operation Setiap skenario diatas diuji untuk mengetahui apakah hasil yang dikeluarkan sesuai dengan harapan.
FI
Skenario operasional dibuat dalam bentuk use case diagram. Beberapa skenario yang digunakan adalah: - Card operation - Passbook operation - Banknotes operation - Receipt operation Setiap skenario diatas diuji untuk mengetahui apakah hasil yang dikeluarkan sesuai dengan harapan.
FI 7 Menetapkan dan mengelola definisi atas kebutuhan fungsionalitas dan atribut kualitas
Mengacu pada no. 6.
FI
Mengacu pada no. 6.
Area Proses: Requirement Development (RD) No Deskripsi Praktik Proyek A Stat u s Proyek B Stat u s 8 Menganalisa kebutuhan untuk memastikan bahwa mereka diperlukan dan mencukupi
Uji kinerja telah dilakukan untuk mengetahui apakah kinerja aplikasi telah berjalan sesuai harapan. Uji kinerja salah satunya dilakukan dengan
menjalankan fitur playback sebanyak 1000 kali perulangan untuk mengetahui apakah ditemukan error dalam proses.
FI
Untuk mengetahui apakah kebutuhan telah tercukupi, didalam Proyek B dilakukan uji kinerja produk. Uji kinerja dilakukan dengan menjalankan fitur playback sebanyak 1000 kali perulangan. FI 9 Menganalisa kebutuhan untuk menyeimbangkan kebutuhan stakeholder dan batasan - batasan
Batasan - batasan yang mungkin memiliki dampak pada arsitektur sistem telah diidentifikasi. Batasan tersebut seperti: - Sistem hanya dapat berjalan pada platform Windows
- Aplikasi web browser yang digunakan minimal
menggunakan Internet Explorer 6 atau versi selanjutnya.
FI
Batasan - batasan telah diidentifikasi pada Proyek B. Batasan yang ada dikategorikan dalam beberapa kategori, yaitu: - Hardware limitation (minimum hardware specification)
- System environment (OS, web browser)
- Interface to other applications
- Programming language requirement
- ATM software feature
FI 10 Memvalidasi kebutuhan untuk memastikan produk yang dihasilkan akan memberi kinerja seperti yang diharapkan di lingkungan pengguna
Validasi atas kebutuhan telah dilakukan dengan metode peer-review dan
didokumentasikan dalam Review Report (untuk SRS, Test Plan maupun Test Scenario).
FI
Validasi atas kebutuhan telah dilakukan dengan metode peer-review dan didokumentasikan dalam Review Report yang berguna untuk mengetahui apakah terdapat kekurangan atau modifikasi yang dibutuhkan.
FI
4.5.2 Technical Solution (TS)
Setelah SRS dibuat, dilakukan pemilihan metode pengembangan produk dalam proyek. Pemilihan metode diawali dengan identifikasi apakah produk yang akan dikembangkan dalam
proyek akan dibuat secara in-house, custom solution atau organisasi membeli commercial off-the-shelf solution (COTS). Jika produk akan dikembangkan secara in-house, maka solusi (produk) alternatif tidak dibutuhkan. Berdasarkan observasi, tidak terdapat kebutuhan penggunaan solusi alternatif pada Proyek A maupun Proyek B.
Gambar. 4.11 Hasil Pengukuran Area Proses TS
Setelah melakukan pengukuran pada praktik – praktik area proses TS terhadap kedua proses, disimpulkan bahwa seluruh tujuan praktik telah terpenuhi dengan baik. Desain aplikasi telah tersedia dalam dokumen Software Architecture Design (SAD) yang dibuat oleh TL.Selain itu instruksi instalasi serta user manual bagi pelanggan telah tersedia.
Tabel 4.13 Hasil Pengukuran Area Proses TS
Area Proses: Technical Solution (TS)
No Deskripsi Praktik Proyek A St at us Proyek B St at us 1 Membuat solusi alternatif dan kriteria pemilihan N/A. Berdasarkan
identifikasi di awal proyek, produk dalam Proyek A merupakan produk yang akan dikembangkan secara in-house sepenuhnya sehingga tidak dibutuhkan adanya solusi alternatif .
FI
N/A. Produk yang dikembangkan dalam Proyek B akan dibuat secara in-house sepenuhnya sehingga tidak dibutuhkan adanya solusi alternatif .
FI 2 Memilih solusi komponen produk berdasarkan kriteria pemilihan N/A. Berdasarkan
identifikasi di awal proyek, tidak dibutuhkan adanya solusi alternatif. Sebagai informasi, apabila terjadi penggunaan solusi alternatif, beberapa kriteria pemilihan akan digunakan seperti: - Cost, termasuk pengukuran biaya, biaya awal pembelian, dukungan operasi, dsb - Access to specific
packages, komponen teknik apa yang tersedia bagi developer in-house, - Ownership, kepemilikan software
FI
N/A. Berdasarkan
identifikasi di awal proyek, tidak dibutuhkan adanya solusi alternatif.
FI
3 Membuat desain produk atau komponen produk
Desain produk telah dilbuat dan didokumentasikan dalam Software Architecture Design (SAD) yang dibuat oleh Technical Leader (TL). SAD mencakup representasi arsitektur software, sasaran dan batasan arsitektur, logical view dan deployment view.
FI
Desain produk telah dilbuat dan didokumentasikan dalam Software Architecture Design (SAD) yang dibuat oleh Technical Leader (TL). SAD mencakup representasi arsitektur software, sasaran dan batasan arsitektur, logical view dan deployment view.
FI
4 Menetapkan dan mengelola paket data teknis
Pengelolaan paket data telah dilakukan dalam bentuk Entity Relationship Diagram (ERD) untuk
menggambarkan model database. Deskripsi tabel data telah tersedia (misal: field name, field type dan constraint).
FI
Pengelolaan paket data telah dilakukan dalam bentuk Entity Relationship Diagram (ERD) untuk
menggambarkan model database. Deskripsi tabel data telah tersedia (misal: field name, field type dan constraint).
Area Proses: Technical Solution (TS) No Deskripsi Praktik Proyek A Stat u s Proyek B Stat u s 5 Mendesain antar muka komponen produk menggunakan kriteria yang telah ditetapkan
Antar muka produk telah tersedia dan
didokumentasikan dalam SAD.
FI
Antar muka produk telah tersedia dan didokumentasikan dalam SAD. FI 6 Mengevaluasi apakah komponen produk perlu dibuat, dibeli atan di gunakan kembali (reuse) berdasarkan kriteria yang telah ditetapkan
N/A. Berdasarkan
identifikasi di awal proyek, tidak dibutuhkan adanya solusi alternatif. Sebagai informasi, organisasi telah memiliki prosedur apabila diperlukan adanya solusi alternatif yaitu dengan melakukan analisa make/buy/reuse untuk mengetahui apakah diperlukan implementasi commercial-off-the-shelf (COTS) atau diputuskan untuk mengembangkan solusi sendiri .
FI
N/A. Berdasarkan
identifikasi di awal proyek, tidak dibutuhkan adanya solusi alternatif.
FI
7 Mengimplementasi desain komponen produk
Desain komponen produk yang diimplementasi telah didokumentasikan dalam SAD.
FI Desain komponen produk yang diimplementasi telah
didokumentasikan dalam SAD. FI 8 Membuat dan mempertahankan dokumentasi end-use
Dokumentasi end-use telah dibuat dan
didokumentasikan dalam bentuk instruksi instalasi dan user manual.
FI
Dokumentasi end-use telah dibuat dan
didokumentasikan dalam bentuk instruksi instalasi dan user manual.
FI
4.5.3 Product Integration (PI)
Apabila rancangan arsitektur aplikasi telah tersedia dan komponen – komponen aplikasi telah dibuat. Programmer bertanggung jawab merencanakan dan melakukan integration test untuk memastikan komponen – komponen aplikasi telah terintegrasi dan setiap fungsi berjalan bersama dengan benar. Komponen – komponen tersebut dapat berupa kode, modul, aplikasi individual,
aplikasi client dan server dalam sebuah jaringan, dsb. Integration test yang dilakukan meliputi eksekusi setiap use case, use case flow, atau fungsi, menggunakan valid atau invalid data agar dapat mengetahui apakah notifikasi maupun pesan error muncul seperti yang diharapkan. Setelah tes dilakukan, programmer mendokumentasikannya pada Test Result, kemudian mengukur apakah seluruh tes yang direncanakan telah dilakukan dan apakah defect yang teridentifikasi telah diremediasi.
Gambar. 4.12 Hasil Pengukuran Area Proses PI
Berdasarkan pengukuran pada praktik – praktik yang dilakukan pada Proyek A dan Proyek B untuk area proses PI, diketahui bahwa seluruh tujuan praktik telah terpenuhi. Berikut dibawah dapat terlihat hasil pengukuran area proses PI.
Tabel 4.14 Hasil Pengukuran Area Proses PI
Area Proses: Product Integration (PI)
No Deskripsi Praktik Proyek A St at us Proyek B St at us 1 Menetapkan dan mempertahankan strategi integrasi produk
Test plan dan test script telah dibuat, dimana digunakan untuk melakukan integration testing.
FI Test plan dan test script telah tersedia. FI
2 Menetapkan dan mempertahankan lingkungan yang dibutuhkan untuk mendukung integrasi dari komponen produk
Sebelum digunakan, test plan direview terlebih dahulu oleh TL kemudian
didokumentasikan dalam Test Plan Review Report untuk mengetahui apakah test plan telah mencakup seluruh fungsi dan kebutuhan yang perlu diuji.
FI
Test Plan Review Report telah tersedia untuk
mengetahui apakah test plan telah mencakup seluruh fungsi dan kebutuhan yang perlu diuji. FI 3 Menetapkan dan mempertahankan prosedur dan kriteria untuk integrasi komponen produk
Prosedur dan kriteria untuk melakukan integrasi komponen produk telah tersedia. Prosedur pembuatan test plan dan test script, yang mencakup:
- lingkup test - jadwal test - persiapan test
- tools yang digunakan dalam test
- testing deliverables
FI
Prosedur dan kriteria untuk melakukan integrasi komponen produk telah tersedia. FI 4 Mengkaji deskripsi antar muka untuk cakupan dan kelengkapan
Hasil test didokumentasikan pada Test Result, kemudian dilakukan analisa apakah terdapat hasil bug/isu yang ditemukan pada komponen antar muka produk.
FI
Test Result sebagai hasil tes antar muka telah tersedia.
FI 5 Mengelola definisi antar muka internal dan eksternal, desain dan perubahan untuk produk dan komponen produk
Mengacu pada no. 1.
FI
Mengacu pada no. 1.
FI
6 Mengkonfirmasi, sebelum
pemasangan
Sebelum pemasangan, dilakukan evaluasi status bug yang ditemukan terlebih dahulu berdasarkan Test Result untuk mengetahui apakah seluruh bug telah diperbaiki.
FI
Konfimasi atas bug yang ditemukan pada fase tes telah dilakukan dan ditindak
Area Proses: Product Integration (PI) No Deskripsi Praktik Proyek A Stat u s Proyek B Stat u s 7 Memasang komponen produk sesuai dengan strategi integrasi produk dan prosedur
Prosedur integrasi produk tersedia dan mencakup: - Integration plan - Integration schedule - Integration practices, dan - Success criteria
FI
Prosedur integrasi produk telah tersedia. FI 8 Mengevaluasi komponen produk terpasang untuk kompabilitas antar muka
Mengacu pada no. 4
FI
Mengacu pada no. 4
FI
9 Memaketkan produk yang telah terpasang atau komponen produk dan
mengirimkannya ke pelanggan
Komponen produk yang telah lulus uji, dipaketkan dalam bentuk source code untuk
dikirimkan ke pelanggan. FI
Komponen produk yang telah lulus uji, dipaketkan dalam bentuk source code untuk dikirimkan ke pelanggan.
FI
4.5.4 Verification (VER)
Aktivitas review dilakukan pada seluruh fase pengembangan aplikasi. Seluruh deliverables harus melewati proses review sebelum dikirimkan ke pelanggan.Terdapat beberapa tipe review yang dapat dilakukan dalam proyek:
a) Peer review, dilakukan oleh peer roles. Sebagai contoh BA dalam proyek A menyiapkan dokumen SRS A, kemudian SRS tersebut akan direview oleh BA lain (peer) yang terlibat dalam proyek B.
b) Walkthrough, membutuhkan pihak yang direview untuk menjelaskan hasil kerja kepada reviewer.
c) Automated code review, dilakukan menggunakan tools automatis yang dijalankan pada source code.
Jika ditemukan defect pada review yang dilakukan, defect tersebut harus dilaporkan pada Review Report. Beberapa tipe defect yang dapat dilaporkan adalah:
a) Unclear, dimana reviewer tidak dapat menentukan arti/maksud dari item yang direview.
b) Incorrect, item yang direview telah diimplementasikan namun tidak sesuai atau baru sebagian diimplementasi.
c) Missing, item yang direview tidak tersedia.
Berdasarkan observasi pada area proses VER, terdapat 12% praktik yang belum sepenuhnya memenuhi tujuan dalam Proyek A, sedangkan praktik – praktik yang dijalankan dalam Proyek B telah dilakukan dengan baik.
Gambar. 4.13 Hasil Pengukuran Area Proses VER
Secara keseluruhan, praktik – praktik yang dijalankan pada kedua proyek untuk area proses VER dapat terbilang sudah memenuhi tujuan walaupun ada sedikit kelemahan pada Proyek A namun pada Proyek B kelemahan tersebut sudah tidak muncul lagi. Hasil pengukuran untuk area proses VER dapat dilihat pada Tabel 4.11 berikut ini.
Tabel 4.15 Hasil Pengukuran Area Proses VER
Area Proses: Verification (VER)
No Deskripsi Praktik Proyek A Status Proyek B Status 1 Memilih produk kerja untuk diverifikasi dan metode verifikasi yang biasa digunakan
Perencanaan review telah dibuat pada Project Management Plan. Review dilakukan pada item berikut: - Progress dan jadwal proyek - SRS
- SAD
-Test plan & test script - Source code
- Milestone
Aktivitas review yang dilakukan juga telah
FI
Produk kerja yang
diverifikasi dalam proyek B serta frekuensi verifikasi telah tersedia dan didokumentasikan dalam
Area Proses: Verification (VER) No Deskripsi Praktik Proyek A Status Proyek B Status
dijadwalkan dalam jadwal proyek. 2 Menetapkan dan mengelola lingkungan yang dibutuhkan untuk mendukung verifikasi Lingkungan (environment) verifikasi yang diperlukan telah ditetapkan dalam prosedur review. Hasil review didokumentasikan dalam Review Report.
FI
Lingkungan (environment) verifikasi yang diperlukan
telah tersedia. FI 3 Menetapkan dan mengelola prosedur dan kriteria verifikasi untuk produk kerja terpilih
Prosedur dan kriteria
verifikasi mengikuti panduan review organisasi yang bertujuan untuk memastikan setiap deliverable telah dibuat sesuai obyektif deliverable.
FI
Prosedur dan kriteria verifikasi aplikasi yang
dikembangkan telah tersedia. FI
4 Menyiapkan peer review untuk produk kerja terpilih
Mengacu pada no.1.
FI Mengacu pada no.1. FI
5 Melakukan peer review pada produk kerja terpilih dan mengidentifikasi isu yang ditemukan dari peer review Berdasarkan observasi, review telah dilakukan sesuai rencana dan jadwal namun tidak
didokumentasikan pada laporan review, yaitu: - Review proposal - Review jadwal proyek
PI
Review pada produk kerja telah dilakukan sesuai rencana dan jadwal serta
didokumentasikan. FI
6 Menganalisa data mengenai persiapan, eksekusi dan hasil dari peer review
Laporan hasil review dan isu yang ditemukan telah
didokumentasikan. FI
Laporan hasil review dan isu yang ditemukan telah
didokumentasikan. FI
7 Melakukan verifikasi dari produk kerja terpilih
Verifikasi telah dilakukan berdasarkan laporan hasil review dan isu yang telah ditemukan.
FI Verifikasi telah dilakukan berdasarkan laporan hasil
review dan isu yang telah ditemukan.
FI
8 Menganalisa hasil dari seluruh aktivitas verifikasi
Hasil seluruh aktivitas verifikasi telah dibuat pada laporan hasil review. Sebagai tambahan, isu yang teridentifikasi juga dicatat pada dokumentasi lesson learn untuk mengetahui root cause dari isu yang
ditemukan, sehingga tidak terjadi lagi pada proyek serupa.
FI
Laporan hasil review mencakup seluruh hasil aktivitas verifikasi.
4.5.5 Validation (VAL)
Validasi yang dilakukan pada proyek pengembangan aplikasi di organisasi mencakup aktivitas testing. Testing adalah aktivitas mengeksekusi program dengan tujuan untuk menemukan bugs. Setiap test, yang akan dilakukan harus disertakan dengan test script (misalnya: performance test script, security test script, dsb). Hasil testing harus didokumentasikan oleh tester dalam Validation Report untuk memberikan ringkasan seluruh validasi yang dilakukan pada proyek. Tester perlu mendeskripsikan kategori bug yang ditemukan dalam laporan, namun kategori bug perlu dicek dan disahkan terlebih dahulu oleh PM sebelum laporan tersebut dikirimkan kepada software developer. Berdasarkan observasi, praktik – praktik pada Proyek A maupun Proyek B telah dilakukan sesuai dengan tujuan.
Gambar. 4.14 Hasil Pengukuran Area Proses VAL
Seperti yang terlihat pada Gambar 4.13, kedua proyek mendapat nilai persentase penuh (100%) untuk area proses VAL. Hal ini menunjukkan bahwa proses validasi dalam organisasi telah dilakukan dengan baik. Untuk dapat melihat praktik yang dilakukan dengan lebih jelas, mengacu pada tabel dibawah ini.
Tabel 4.16 Hasil Pengukuran Area Proses VAL
Area Proses: Validation (VAL)
No Deskripsi Praktik Proyek A S tat u s Proyek B S tat u s 1 Memilih produk dan komponen produk untuk divalidasi dan metode validasi yang akan digunakan
Produk kerja telah divalidasi dalam proyek A. Komponen produk yang divalidasi termasuk: ATM Simulator, Recording Feature dan Playback Feature
FI
Produk kerja telah divalidasi dalam proyek B. Komponen produk yang divalidasi termasuk: ATM Software, ATM Simulator, Recording Feature dan Playback Feature FI 2 Menetapkan dan mempertahankan lingkungan yang dibuthkan untuk mendukung validasi Lingkungan (environment) validasi yang diperlukan telah ditetapkan pada tahap persiapan test. Dikarenakan aplikasi yang dikembangkan merupakan aplikasi desktop sederhana, hanya dibutuhkan lingkungan test yang
sederhana untuk
dipersiapkan. Lingkungan yang diperlukan terdiri dari: - hardware (misal: PC, LAN connectivity, IP address untuk PC)
- software (misal: OS, web browser, text editor) - test data (dummy data)
FI
Lingkungan (environment) validasi yang diperlukan telah ditetapkan pada tahap persiapan test. Lingkungan validasi yang dibutuhkan serupa dengan Proyek A.
FI
3 Menetapkan dan mempertahankan prosedur dan kriteria validasi
Prosedur dan kriteria validasi menggunakan panduan organisasi. Tujuannya untuk
memastikan produk yang dibuat telah sesuai dengan kebutuhan yang ditetapkan dalam SRS.
FI
Prosedur dan kriteria validasi telah tersedia yaitu menggunakan panduan
Area Proses: Validation (VAL) No Deskripsi Praktik Proyek A Status Proyek B Status 4 Melakukan validasi pada produk dan komponen produk terpilih
Validasi telah dilakukan pada Proyek A. Validasi yang dilakukan telah sesuai dengan test strategy, yaitu mencakup:
- Unit test
- System integration test (SIT)
- User acceptance test (UAT) Hasil test telah
didokumentasikan dan tersedia pada repositori proyek.
FI
Validasi telah dilakukan sesuai dengan test strategy yang mencakup:
- Unit test
- System integration test (SIT)
- User acceptance test (UAT) Hasil test telah
didokumentasikan dan tersedia pada repositori proyek.
FI
5 Menganalisa hasil dari aktivitas validasi
Hasil seluruh aktivitas validasi telah dibuat pada laporan hasil validasi. Sebagai tambahan, isu atau bug yang teridentifikasi juga dicatat pada dokumentasi lesson learn untuk
mengetahui root cause dari isu yang ditemukan, sehingga tidak terjadi lagi pada proyek serupa.
FI
Laporan hasil validasi mencakup seluruh hasil aktivitas validasi.
FI
4.5.6 Organizational Process Focus (OPF)
Area proses OPF bertujuan untuk memastikan organisasi telah merencanakan, mengimplementasi dan menyebarkan peningkatan proses (organizational process improvement) berdasarkan kekuatan dan kelemahan proses dan asset proses organisasi. Dalam Proyek A (sebelum menerapkan CMMI), beberapa praktik masih belum memenuhi tujuan terkait dengan belum adanya deskripsi atas kebutuhan proses dan obyektif organisasi dalam kaitannya dengan proyek pengembangan aplikasi.
