BAB IV HASIL DAN PEMBAHASAN

Transkripsi

1 BAB IV 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). Tidak relevan. 2 Pelanggan Cara kerja tidak berbeda berdasarkan jenis pelanggan (misal: bank, perusahaan asuransi, dst). Tidak relevan. 3 Ukuran Proyek Cara kerja tidak berbeda berdasarkan ukuran proyek. 4 Struktur Organisasi Relevan. 65

2 66 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. Relevan. Cara kerja dilakukan berbeda berdasarkan tipe 5 Jenis Pekerjaan pekerjaan, yaitu project development, change request (CR), dan maintenance. Area proses CMMI yang terpengaruh adalah Project Management dan Engineering process area.

3 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 / 3 (ii) CR / maintenance 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

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

5 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 Jumlah Perhitungan Jumlah (#) Minimum No Subgroup Proyek dalam Minimum Sampel Menggunakan Sampel yang Subgroup Formula dibutuhkan 1 BAS, Project (BP) 52 #minimum BP = (7x52)/67 = BAS, CR (BC) 1 # minimum BC = (7x1)/67 = BAS, Maintenance (BM) 1 # minimum BM = (7x1)/67 = FNBS, Project (FP) 5 # minimum FP = (7x5)/67 = PT, Project (PP) 6 # minimum PP = (7x6)/67 = PT, CR (PC) 1 # minimum PC = (7x1)/67 = PT, Maintenance (PM) 1 # minimum PM = (7x1)/67 =

6 70 Nilai yang didapat dari perhitungan menggunakan formula dibulatkan, sehingga jumlah minimum sampel yang dibutuhkan untuk penelitian dapat ditemukan seperti tertera dalam tabel diatas 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 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

7 71 proyek kedua yaitu proyek ATM Simulator, yaitu merupakan proyek pengembangan aplikasi simulator ATM serta mengembangkan alat yang berfungsi untuk mensimulasikan komunikasi antara aplikasi ATM dengan simulator ATM Proyek A Proyek pengembangan aplikasi ATM Interaction Proyek A dimulai pada September 2012 hingga November 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. yaitu: Jumlah anggota tim Proyek A terdiri dari 5 orang anggota, a) 1 orang Project Manager (PM) b) 1 orang Business Analyst (BA) c) 1 orang System Analyst (SA) d) 1 orang Programmer, dan

8 72 e) 1 orang Software Tester Proyek pengembangan aplikasi ATM Simulator dimulai pada Januari 2013 hingga April 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. yaitu: Jumlah anggota tim terdiri dari 7 orang anggota, a) 1 orang Project Manager (PM) b) 1 orang Project Administrator (PA) c) 1 orang Business Analyst (BA) d) 1 orang System Analyst (SA)

9 73 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 Project Tracking 10.0 Invoice Tracking Gambar 4.2 Siklus Pengembangan Aplikasi di Telkomsigma

11 Pengukuran Area Proses CMMI Maturity Level 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.

12 76 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 1 Mengembangkan Business Analyst (BA) pemahaman terlibat dalam pengumpulan dengan penyedia dan pengembangan kebutuhan kebutuhan dengan pelanggan. Kebutuhan didokumentasikan dalam Software Requirement Specification (SRS), Requirement Verification Matrix (RVM), dan Test Scenario. 2 Mendapatkan komitmen atas kebutuhan 3 Mengelola perubahan terhadap kebutuhan 4 Mengelola bidirectional traceability antara kebutuhan kebutuhan dan work product Internal Work Order (IWO) digunakan sebagai dokumen bukti komitmen inisiasi proyek. Dokumen juga telah disimpan dalam repositori proyek. Tidak terdapat permintaan perubahan kebutuhan. 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 Business Analyst (BA) terlibat dalam pengembangan kebutuhan. Dokumen terkait seperti SRS, RVM, dan Test Scenario telah didokumentasikan. IWO dan Quotation digunakan sebagai dokumen bukti komitmen inisiasi proyek. Dokumen juga telah disimpan dalam repositori proyek. Tidak terdapat permintaan perubahan kebutuhan. Pengelolaan bidirectional traceability pada menggunakan RVM. Dikarenakan tidak terdapat permintaan perubahan dari klien, RVM tidak mengalami perubahan dari saat pertama kali dibuat.

13 77 Area Proses: Requirement Management (REQM) No Deskripsi Praktik Proyek A 5 Memastikan Penyelarasan antara Jadwal proyek telah dibuat penyelarasan kebutuhan dan aktivitas dalam Project Schedule antara kebutuhan terlihat dari adanya revisi. Terdapat beberapa dan aktivitas dan pembaharuan pada revisi jadwal proyek, hal ini proyek jadwal dan estimasi upaya terlihat dari beberapa update yang diperlukan dalam versi jadwal. Revisi tersebut Proyek A. memiliki dasar, karena beberapa hal: - Penambahan jadwal kickoff meeting - Pertimbangan untuk melakukan parallel task - Penambahan kalender hari libur - Penambahan effort untuk periodik progress review 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.

14 78 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, 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.

15 79 Tabel 4.6 Hasil Pengukuran Area Proses PP Deskripsi No Praktik 1 Menetapkan Work Breakdown Structure (WBS) dan mengestimasi lingkup proyek 2 Mengestimasi produk kerja dan atribut tugas 3 Mendefinisikan siklus hidup proyek 4 Mengestimasi upaya dan biaya proyek Area Proses: Project Planning (PP) Proyek A WBS telah ditetapkan dalam dokumen Project Schedule yang tersedia dalam bentuk.mpp (format Microsoft Project). Waktu yang digunakan untuk aktivitas audit belum dialokasikan. 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). Siklus hidup proyek A dibuat sesuai dengan panduan Project Lifecycle. Hal ini juga terlihat pada dokumen perencanaan proyek dan jadwal proyek. Mengacu pada no.2. PI PI NI 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. 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. Siklus hidup proyek B dibuat sesuai dengan panduan Project Lifecycle. Mengacu pada no.2. 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. LI

16 80 No Deskripsi Praktik 6 Mengidentifikasi dan menganalisa risiko proyek 7 Merencanakan pengelolaan data (data management plan) proyek 8 Merencanakan sumber daya untuk melakukan proyek 9 Merencanakan pengetahuan dan kompetensi yang dibutuhkan untuk melakukan proyek Area Proses: Project Planning (PP) Proyek A 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. 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. Struktur tim proyek serta tugas tanggung jawab masing - masing telah tersedia serta didokumentasikan dalam Project Management Plan. Tidak ditemukan adanya perencanaan pengetahuan dan identifikasi kompetensi yang dibutuhkan dalam Proyek A. NI NI 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) Rencana pengelolaan data proyek telah ditetapkan dalam Project Management Plan (frekuensi backup, media backup, lokasi backup). 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. Untuk, 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. LI

17 81 Deskripsi No Praktik 10 Merencanakan keterlibatan stakeholder yang teridentifikasi 11 Menetapkan dan mengelola perencanaan proyek 12 Mengkaji semua rencana yang mempengaruhi proyek 13 Merubah project plan untuk merekonsiliasi dan mengestimasi sumber daya yang tersedia 14 Mendapatkan komitmen dari stakeholder terkait Area Proses: Project Planning (PP) Proyek A Meskipun struktur tim proyek telah tersedia, namun keterlibatan setiap stakeholder terkait dalam Proyek A belum diidentifikasi. Pengelolaan proyek sudah tersedia, dimana mencakup pengelolaan konfigurasi, review dan eskalasi, namun aktivitas audit serta metrik proyek belum ditetapkan. Kajian untuk rencana proyek telah dilakukan. Namun, kajian terhadap Project Management Plan tidak ditemukan. Jadwal proyek dan rencana proyek telah direvisi sesuai dengan kebutuhan proyek. Telah terdapat komitmen stakeholder. Seluruh tim proyek turut serta dalam kick-off meeting. PI PI PI Keterlibatan setiap stakeholder dalam 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. Pengelolaan proyek sudah tersedia, dimana mencakup pengelolaan konfigurasi, review dan eskalasi, serta metrik proyek (client satisfaction index, effort variance, UAT success rate) telah ditetapkan. 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. Jadwal proyek dan rencana proyek telah direvisi sesuai dengan kebutuhan proyek. Stakeholder (misal: tim QA) telah turut serta pada rapat - rapat penting (readiness meeting) sebagai bukti komitmennya terhadap proyek. Pada, seluruh area proses PP telah berjalan dengan baik. Hal ini dikarenakan rencana yang mendefinisikan kegiatan

18 82 proyek meliputi atribut produk kerja dan tugas, sumber daya yang dibutuhkan, keterlibatan dan komitmen stakeholder hingga analisa risiko telah dilakukan secara menyeluruh 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.

19 83 Gambar. 4.5 Hasil Pengukuran Area Proses PMC Peningkatan proses PMC dapat dilihat pada proyek B. Proses pengawasan pada 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 No Deskripsi Praktik 1 Memantau nilai aktual dari perencanaan proyek 2 Memantau komitmen Area Proses: Project Monitoring and Control (PMC) Proyek A Jadwal proyek dan timesheet tim proyek diperbaharui selama proyek. Meeting status proyek telah dilakukan sesuai rencana. Weekly progress review reports yang dilaporkan kepada project steering commitee tersedia. 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. 4 Memantau pengelolaan data proyek Tidak terdapat rencana pengelolaan data proyek. PI NI Jadwal proyek dan timesheet tim proyek diperbaharui selama proyek. Meeting status proyek telah dilakukan sesuai rencana. Weekly progress review reports yang dilaporkan kepada project steering commitee. 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. Pengelolaan data telah dilakukan sesuai dengan perencanaan proyek 5 Memantau keterlibatan stakeholder Stakeholder terlibat pada saat readiness meeting dan meeting status proyek. Stakeholder terlibat pada saat readiness meeting dan meeting status proyek. 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 Meeting status proyek telah dilakukan sesuai rencana proyek. Meeting status proyek mencakup pembahasan mengenai

20 84 No Deskripsi Praktik Area Proses: Project Monitoring and Control (PMC) Proyek A 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. Jadwal proyek dikelola selama proyek berlangsung. Revisi dilakukan jika perlu. 8 Mengumpulkan dan menganalisa isu dan menentukan corrective action 9 Melakukan corrective action pada isu yang teridentifikasi 10 Mengelola corrective action hingga terselesaikan Isu yang teridentifikasi dibahas pada meeting status proyek untuk menentukan corrective action yang diperlukan. Isu yang teridentifikasi dibahas pada meeting status proyek untuk menentukan corrective action yang diperlukan. Isu yang teridentifikasi dibahas pada meeting status proyek untuk menentukan corrective action yang diperlukan. Isu yang teridentifikasi dibahas pada meeting status proyek untuk menentukan corrective action yang diperlukan. Isu yang teridentifikasi dibahas pada meeting status proyek untuk menentukan corrective action yang diperlukan. Isu yang teridentifikasi dibahas pada meeting status proyek untuk menentukan corrective action yang diperlukan 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 dikarenakan aplikasi yang dikembangkan dibuat secara in-house.

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

22 86 Tabel 4.8 Hasil Pengukuran Area Proses SAM No Area Proses: Supplier Agreement Management (SAM) Deskripsi Proyek A Praktik 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 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) 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. 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. N/A. Tidak terdapat penggunaan pemasok pada proyek A. N/A. Tidak terdapat proses akusisi pada proyek B. N/A. Tidak terdapat penggunaan pemasok pada proyek B. N/A. Tidak terdapat penggunaan pemasok pada proyek B. N/A. Tidak terdapat penggunaan pemasok pada proyek B.

23 87 No Area Proses: Supplier Agreement Management (SAM) Deskripsi Proyek A Praktik 5 Memastikan bahwa perjanjian pemasok memuaskan sebelum menerima produk yang diakuisisi 6 Memastikan transisi produk yang diakuisisi dari supplier N/A. Tidak terdapat penggunaan pemasok pada proyek A. N/A. Tidak terdapat penggunaan pemasok pada proyek A. N/A. Tidak terdapat penggunaan pemasok pada proyek B. N/A. Tidak terdapat penggunaan pemasok pada proyek B 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.

24 88 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. Berikut dibawah adalah hasil pengukuran pada area proses M&A.

25 89 Tabel 4.9 Hasil Pengukuran Area Proses M&A Area Proses: Measurement & Analysis (M&A) No Deskripsi Praktik Proyek A 1 Menetapkan dan mempertahankan objektif pengukuran 2 Menentukan pengukuran untuk mengakomodasi objektif pengukuran 3 Menentukan bagaimana data pengukuran akan didapatkan dan disimpan 4 Menentukan bagaimana data pengukuran akan dianalisa dan di komunikasikan Pengukuran yang dilakukan terbatas pada pengukuran jumlah defect yang ditemukan saat review.tidak terdapat obyektif/perencanaan pengukuran untuk metrik pengukuran lain pada Proyek A. Tidak terdapat obyektif/perencanaan pengukuran pada Proyek A. Tidak terdapat obyektif/perencanaan pengukuran pada Proyek A. Tidak terdapat obyektif/perencanaan pengukuran pada Proyek A. PI NI NI NI 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. 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% 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. Organisasi telah menetapkan prosedur dalam melakukan analisa data. Hasil pengukuran data tersebut akan

26 90 Area Proses: Measurement & Analysis (M&A) No Deskripsi Praktik Proyek A dikomunikasikan lewat diakhir proyek 5 Mendapatkan data pengukuran yang ditentukan 6 Menganalisa dan menerjemahkan data pengukuran Data pengukuran defect tersedia dan hasil pengukuran dicatat pada Closing Project Presentation. Mengacu pada no.5. Data pengukuran tersedia dan hasil pengukuran dicatat pada Closing Project Presentation. Mengacu pada no.5. 7 Mengelola dan menyimpan data pengukuran 8 Mengkomunikasikan hasil pengukuran dan analisa Data pengukuran defect tersedia dan hasil pengukuran dicatat pada Closing Project Presentation. Data pengukuran defect tersedia dan hasil pengukuran dicatat pada Closing Project Presentation. Data pengukuran tersedia dalam repositori proyek B. Hasil pengukuran dikomunikasikan lewat Closing Project Presentation 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.

27 91 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 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 Tidak ditemukan perencanaan aktivitas audit untuk Proyek A. Audit yang dilakukan tidak mencakup deliverable penting (misal: SRS, SAD). Tidak ditemukan hasil audit untuk SRS. NI PI Perencanaan aktivitas audit untuk proyek B telah ditetapkan. Audit yang dilakukan mencakup deliverable audit (misal: SRS, SAD). Mengacu pada no.1.

28 92 Area Proses: Process and Product Quality Assurance (PPQA) No Deskripsi Praktik Proyek A berlaku 3 Mengkomunikasikan isu terkait kualitas dan memastikan penyelesaian atas isu ketidakpatuhan 4 Menetapkan dan mengelola rekaman dari aktivitas quality assurance 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. 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. Setiap temuan telah dicatat dalam laporan audit dengan memasukkan sumber temuan, deskripsi, tipe, status, dan target penyelesaiannya. Lesson learned telah didentifikasi dan didokumentasikan untuk menjadi pembelajaran bagi proyek serupa berikutnya 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.

29 93 Gambar. 4.9 Hasil Pengukuran Area Proses CM Berdasarkan observasi, tidak terdapat configuration management plan pada Proyek A. Sementara itu, 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 1 Mengidentifikasi Tidak ditemukan adanya Configuration item (CI) configuration configuration management telah diidentifikasi pada item, komponen plan dan identifikasi proyek B. Berikut daftar dan produk kerja configuration item pada configuration item pada terkait proyek A. : - Project Management Plan - Software Requirement and Specification (SRS) - Software Architecture Document (SAD) - Source code 2 Menetapkan dan Tidak ditemukan adanya Configuration management mempertahankan configuration management plan untuk proyek B manajemen plan dan identifikasi mencakup identifikasi CI, konfigurasi dan configuration item pada configuration management manajemen proyek A. library, permission, version NY NY

30 94 No Deskripsi Praktik perubahan Area Proses: Configuration Management (CM) Proyek A control dan change control dalam proyek. 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 7 Melakukan audit konfigurasi untuk mempertahankan integritas atas baseline konfigurasi Tidak ditemukan adanya configuration management plan dan identifikasi configuration item pada proyek A. Tidak ditemukan adanya configuration management plan dan identifikasi configuration item pada proyek A. Tidak ditemukan adanya configuration management plan dan identifikasi configuration item pada proyek A. Tidak ditemukan adanya configuration management plan dan identifikasi configuration item pada proyek A. Tidak ditemukan adanya configuration management plan dan identifikasi configuration item pada proyek A. NY NY NY NY 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) N/A. Tidak terdapat perubahan CI dalam proyek B. N/A. Tidak terdapat perubahan CI dalam proyek B. Organisasi telah menetapkan repositori proyek yang digunakan untuk menyimpan configuration item. Untuk dapat mengelola versi dokumen, organisasi menggunakan SVN (version control tools). N/A. Tidak terdapat perubahan CI dalam proyek B.

31 Pengukuran Area Proses CMMI Maturity Level 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 telah menjalankan praktik sesuai dengan tujuan dari praktik. Hal ini dapat dilihat pada gambar dibawah. Gambar Hasil Pengukuran Area Proses RD Berdasarkan pengukuran, kedua proyek telah memenuhi tujuan praktik. Kebutuhan dan harapan stakeholder, antar muka yang

32 96 dibutuhkan, skenario dan konsep operasional aplikasi serta validasi telah diakomodasi dengan baik. Tabel 4.12 Hasil Pengukuran Area Proses RD Deskripsi No Praktik 1 Memperoleh kebutuhan, harapan stakeholder, batasan dan antar muka untuk seluruh fase siklus produk 2 Mentransformasi kebutuhan stakeholder, harapan, batasan dan antar muka menjadi kebutuhan pelanggan Area Proses: Requirement Development (RD) Proyek A Kebutuhan, harapan stakeholder, batasan dan antar muka produk telah diakomodasi dalam Software Requirement Specification (SRS) yang disiapkan oleh Business Analyst (BA). 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'. Kebutuhan, harapan stakeholder, batasan dan antar muka produk telah diakomodasi dalam SRS yang disiapkan oleh BA. SRS telah dibuat, revision history telah dikelola dengan baik dan baseline SRS telah ditetapkan. 3 Menetapkan dan mengelola kebutuhan produk dan komponen produk, dimana didasarkan atas kebutuhan pelanggan Revision history pada SRS selalu dicatat, sebagai bukti SRS telah direview dan baseline telah ditetapkan. 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. 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.

33 97 Deskripsi No Praktik 4 Mengalokasi kebutuhan untuk tiap komponen produk 5 Mengidentifikasi kebutuhan antar muka 6 Menetapkan dan mengelola konsep operasional dan skenario terkait 7 Menetapkan dan mengelola definisi atas kebutuhan fungsionalitas dan atribut kualitas Area Proses: Requirement Development (RD) Proyek A 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 Identifikasi kebutuhan antar muka telah tersedia dalam Software Architecture Design (SAD). Antar muka pengguna dijelaskan dalam diagram alur navigasi antar muka. 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. Mengacu pada no. 6. 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 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. 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. Mengacu pada no. 6.

34 98 No Deskripsi Praktik 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 Area Proses: Requirement Development (RD) Proyek A 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. 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. Validasi atas kebutuhan telah dilakukan dengan metode peer-review dan didokumentasikan dalam Review Report (untuk SRS, Test Plan maupun Test Scenario). Untuk mengetahui apakah kebutuhan telah tercukupi, didalam dilakukan uji kinerja produk. Uji kinerja dilakukan dengan menjalankan fitur playback sebanyak 1000 kali perulangan. 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 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 Technical Solution (TS) Setelah SRS dibuat, dilakukan pemilihan metode pengembangan produk dalam proyek. Pemilihan metode diawali dengan identifikasi apakah produk yang akan dikembangkan dalam

35 99 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. Gambar 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.

36 100 Tabel 4.13 Hasil Pengukuran Area Proses TS Deskripsi No Praktik 1 Membuat solusi alternatif dan kriteria pemilihan 2 Memilih solusi komponen produk berdasarkan kriteria pemilihan 3 Membuat desain produk atau komponen produk 4 Menetapkan dan mengelola paket data teknis Area Proses: Technical Solution (TS) Proyek A 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. 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 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. 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). N/A. Produk yang dikembangkan dalam akan dibuat secara in-house sepenuhnya sehingga tidak dibutuhkan adanya solusi alternatif. N/A. Berdasarkan identifikasi di awal proyek, tidak dibutuhkan adanya solusi alternatif. 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. 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).

37 101 Deskripsi No Praktik 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 enduse Area Proses: Technical Solution (TS) Proyek A Antar muka produk telah tersedia dan didokumentasikan dalam SAD. 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. Desain komponen produk yang diimplementasi telah didokumentasikan dalam SAD. Dokumentasi end-use telah dibuat dan didokumentasikan dalam bentuk instruksi instalasi dan user manual. Antar muka produk telah tersedia dan didokumentasikan dalam SAD. N/A. Berdasarkan identifikasi di awal proyek, tidak dibutuhkan adanya solusi alternatif. Desain komponen produk yang diimplementasi telah didokumentasikan dalam SAD. Dokumentasi end-use telah dibuat dan didokumentasikan dalam bentuk instruksi instalasi dan user manual 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,

38 102 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 Hasil Pengukuran Area Proses PI Berdasarkan pengukuran pada praktik praktik yang dilakukan pada Proyek A dan untuk area proses PI, diketahui bahwa seluruh tujuan praktik telah terpenuhi. Berikut dibawah dapat terlihat hasil pengukuran area proses PI.

39 103 Tabel 4.14 Hasil Pengukuran Area Proses PI Deskripsi No Praktik 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 Area Proses: Product Integration (PI) Proyek A Test plan dan test script telah dibuat, dimana digunakan untuk melakukan integration testing. 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. 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 Hasil test didokumentasikan pada Test Result, kemudian dilakukan analisa apakah terdapat hasil bug/isu yang ditemukan pada komponen antar muka produk. Mengacu pada no. 1. Sebelum pemasangan, dilakukan evaluasi status bug yang ditemukan terlebih dahulu berdasarkan Test Result untuk mengetahui apakah seluruh bug telah diperbaiki. Test plan dan test script telah tersedia. Test Plan Review Report telah tersedia untuk mengetahui apakah test plan telah mencakup seluruh fungsi dan kebutuhan yang perlu diuji. Prosedur dan kriteria untuk melakukan integrasi komponen produk telah tersedia. Test Result sebagai hasil tes antar muka telah tersedia. Mengacu pada no. 1. Konfimasi atas bug yang ditemukan pada fase tes telah dilakukan dan ditindak lanjuti.

40 104 No Deskripsi Praktik 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 Area Proses: Product Integration (PI) Proyek A Prosedur integrasi produk tersedia dan mencakup: - Integration plan - Integration schedule - Integration practices, dan - Success criteria Mengacu pada no. 4 Komponen produk yang telah lulus uji, dipaketkan dalam bentuk source code untuk dikirimkan ke pelanggan. Prosedur integrasi produk telah tersedia. Mengacu pada no. 4 Komponen produk yang telah lulus uji, dipaketkan dalam bentuk source code untuk dikirimkan ke pelanggan 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.

41 105 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 telah dilakukan dengan baik.

42 106 Gambar 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 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 Deskripsi No Praktik 1 Memilih produk kerja untuk diverifikasi dan metode verifikasi yang biasa digunakan Area Proses: Verification (VER) Proyek A 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 Produk kerja yang diverifikasi dalam proyek B serta frekuensi verifikasi telah tersedia dan didokumentasikan dalam Project Management Plan.

43 107 No Deskripsi Praktik Area Proses: Verification (VER) Proyek A dijadwalkan dalam jadwal proyek. 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 Lingkungan (environment) verifikasi yang diperlukan telah ditetapkan dalam prosedur review. Hasil review didokumentasikan dalam Review Report. Prosedur dan kriteria verifikasi mengikuti panduan review organisasi yang bertujuan untuk memastikan setiap deliverable telah dibuat sesuai obyektif deliverable. Mengacu pada no.1. Berdasarkan observasi, review telah dilakukan sesuai rencana dan jadwal namun tidak didokumentasikan pada laporan review, yaitu: - Review proposal - Review jadwal proyek Laporan hasil review dan isu yang ditemukan telah didokumentasikan. Verifikasi telah dilakukan berdasarkan laporan hasil review dan isu yang telah ditemukan. 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. PI Lingkungan (environment) verifikasi yang diperlukan telah tersedia. Prosedur dan kriteria verifikasi aplikasi yang dikembangkan telah tersedia. Mengacu pada no.1. Review pada produk kerja telah dilakukan sesuai rencana dan jadwal serta didokumentasikan. Laporan hasil review dan isu yang ditemukan telah didokumentasikan. Verifikasi telah dilakukan berdasarkan laporan hasil review dan isu yang telah ditemukan. Laporan hasil review mencakup seluruh hasil aktivitas verifikasi.

44 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 telah dilakukan sesuai dengan tujuan. Gambar Hasil Pengukuran Area Proses VAL

45 109 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 Deskripsi No Praktik 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 Area Proses: Validation (VAL) Proyek A Produk kerja telah divalidasi dalam proyek A. Komponen produk yang divalidasi termasuk: ATM Simulator, Recording Feature dan Playback Feature 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) Prosedur dan kriteria validasi menggunakan panduan organisasi. Tujuannya untuk memastikan produk yang dibuat telah sesuai dengan kebutuhan yang ditetapkan dalam SRS. Produk kerja telah divalidasi dalam proyek B. Komponen produk yang divalidasi termasuk: ATM Software, ATM Simulator, Recording Feature dan Playback Feature Lingkungan (environment) validasi yang diperlukan telah ditetapkan pada tahap persiapan test. Lingkungan validasi yang dibutuhkan serupa dengan Proyek A. Prosedur dan kriteria validasi telah tersedia yaitu menggunakan panduan organisasi.

46 110 Deskripsi No Praktik 4 Melakukan validasi pada produk dan komponen produk terpilih 5 Menganalisa hasil dari aktivitas validasi Area Proses: Validation (VAL) Proyek A 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. 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. 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. Laporan hasil validasi mencakup seluruh hasil aktivitas validasi 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.

47 111 Gambar Hasil Pengukuran Area Proses OPF Perencanaan aktivitas audit yang dibutuhkan untuk menilai proses dalam organisasi juga tidak ditemukan pada Proyek A. Selain itu, tidak terdapat implementasi Process Action Plan (PAP) yang bertujuan untuk meningkatkan proses dalam organisasi dalam periode dilaksanakannya Proyek A. Hasil pengukuran yang dilakukan dapat dilihat pada Gambar Tabel 4.17 Hasil Pengukuran Area Proses OPF No Deskripsi Praktik 1 Menetapkan dan mengelola deskripsi kebutuhan proses dan objektif untuk organisasi Area Proses: Organizational Process Focus (OPF) Proyek A Deskripsi kebutuhan proses dan objektif organisasi belum ditetapkan. NI Kebutuhan dan objektif proses untuk organisasi telah ditetapkan dalam kebijakan Quality Policy & Manual, Process Improvement Procedure, dan CMMI-Based Improvement Policy yang menyatakan bahwa organisasi telah menetapkan kebijakan dan prosedur terkait untuk mendukung

48 112 No Deskripsi Praktik Area Proses: Organizational Process Focus (OPF) Proyek A peningkatan proses pengembangan aplikasi. 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 process action plan untuk mengikutsertakan peningkatan dalam proses dan aset proses organisasi 5 Mengimplementasi action plan proses 6 Menyebarkan aset proses organisasi pada seluruh organisasi Perencanaan audit proses belum tersedia. Identifikasi peningkatan proses dalam organisasi telah tersedia. Identifikasi peningkatan didapat lewat saran, lesson learned, hasil audit dan komplain dari pelanggan. Selain itu, seluruh ide akan dicatat pada Process Improvement Logbook untuk mengetahui peningkatan mana yang bersifat major/minor dan peningkatan apa yang harus diprioritaskan oleh perusahaan. Organisasi telah menengesahkan Process Action Plan (PAP) dalam prosedur SOP Process Improvement. PAP akan digunakan jika peningkatan yang dibutuhkan akan dieksekusi sebagai proyek. Berdasarkan observasi, belum terdapat implementasi action plan proses untuk peningkatan dalam bentuk proyek selama periode penelitian. Aset proses organisasi ditempatkan pada repositori organisasi yang dapat diakses oleh seluruh karyawan terkait. NI PI Proses organisasi dinilai secara periodik berdasarkan standar internasional (misal: ISO 9001) oleh tim Internal Audit (IA). Perencanaan audit proses ditetapkan oleh tim IA setiap awal tahun. Identifikasi peningkatan proses dalam organisasi telah tersedia. Process Action Plan (PAP) untuk peningkatan proses telah tersedia. Implementasi process action plan telah dilakukan untuk proyek pengembangan aplikasi lain (misal: Project.Net) dalam organisasi. Aset proses organisasi ditempatkan pada repositori organisasi yang dapat diakses oleh seluruh karyawan terkait.

49 113 No Deskripsi Praktik 7 Menyebarkan kumpulan proses standar organisasi di awal proyek dan menyebarkan perubahan pada proyek pada siklus proyek 8 Memantau implementasi kumpulan proses standar organisasi dan penggunaan aset proses pada seluruh proyek 9 Mengkombinasikan produk kerja terkait proses, pengukuran serta informasi yang diturunkan dari perencanaan dan melakukan proses menggunakan aset proses organisasi. Area Proses: Organizational Process Focus (OPF) Proyek A Training mengenai proses pengembangan aplikasi direncanakan sesuai dengan jadwal training organisasi. Training juga dilakukan bagi karyawan baru sebelum masuk kedalam proyek. Implementasi proses dan penggunaan aset proses pada proyek pengembangan aplikasi dipantau oleh QA secara periodik. Lesson learned telah tersedia untuk mengetahui peluang peningkatan proses pada Proyek A. Training khusus proses direncanakan sesuai dengan jadwal training organisasi. Selain itu, saat ini seluruh proyek memiliki QA yang diikutsertakan dalam proyek untuk mendukung implementasi proses. Implementasi proses dan penggunaan aset proses pada proyek pengembangan aplikasi dipantau oleh QA secara periodik. Lesson learned telah tersedia untuk mengetahui peluang peningkatan proses pada. Selain itu QA diikutsertakan dalam proyek untuk mendukung implementasi proses. Keterlibatan QA termasuk pada saat readiness review, kick off meeting, serta verifikasi dan validasi Organizational Process Definition (OPD) Berdasarkan observasi untuk area OPD, diketahui bahwa organisasi telah memiliki kebijakan dan prosedur yang digunakan oleh organisasi dalam melakukan proses pengembangan aplikasi. Praktik praktik yang dibutuhkan telah tersedia pada saat Proyek A dilakukan, dan belum terdapat perubahan proses OPD sampai saat ini. Sehingga tidak terdapat perbedaan antara hasil pengukuran pada Proyek A maupun.

50 114 Gambar Hasil Pengukuran Area Proses OPD Pengukuran yang dilakukan pada area proses OPD untuk Proyek A maupun memberi informasi bahwa praktik yang dilakukan pada area proses ini sudah memenuhi tujuan praktik. Tabel 4.18 Hasil Pengukuran Area Proses OPD No Area Proses: Organizational Process Definition (OPD) Deskripsi Proyek A Praktik 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 telah menetapkan dan mendokumentasikan kebijakan, prosedur, dan instruksi kerja terkait proses pengembangan aplikasi. Siklus hidup telah dibuat dan disahkan dalam bentuk SOP Project Lifecycle. Kriteria dan panduan tailoring proses pengembangan aplikasi telah ditetapkan dalam bentuk prosedur Tailoring Process. Organisasi telah menetapkan dan mendokumentasikan kebijakan, prosedur, dan instruksi kerja terkait proses pengembangan aplikasi. Siklus hidup telah dibuat dan disahkan dalam bentuk SOP Project Lifecycle. Kriteria dan panduan tailoring proses pengembangan aplikasi telah ditetapkan dalam bentuk prosedur Tailoring Process.

51 115 No Area Proses: Organizational Process Definition (OPD) Deskripsi Praktik Proyek A organisasi 4 Menetapkan dan mempertahankan repositori pengukuran organisasi 5 Menetapkan dan mengelola perpustakaan aset proses organisasi 6 Menetapkan dan mengelola standar lingkungan kerja 7 Menetapkan dan mengelola peraturan dan panduan organisasi untuk struktur, formasi dan operasi tim Folder unit Proses dalam repositori proyek digunakan sebagai repositori/database pengukuran. Beberapa dokumen yang dikelola dalam repositori adalah: - Process Improvement Logbook, yang digunakan untuk mencatat ide/status peningkatan proses - Process Performance Baseline, digunakan untuk mengukur data proses organisasi secara keseluruhan - Lesson Learned, digunakan untuk mencatat lesson learned, best practice, strength/weaknessess yang ditemukan dalam proyek. Mengacu pada no.4. Standar lingkungan kerja dalam organisasi telah ditetapkan dalam kebijakan Quality Policy and Manual. Organisasi telah menetapkan panduan Team Formation, yang memberikan arahan mengenai bagaimana membentuk struktur tim proyek. Folder unit Proses dalam repositori proyek digunakan sebagai repositori/database pengukuran. Beberapa dokumen yang dikelola dalam repositori adalah: - Process Improvement Logbook, yang digunakan untuk mencatat ide/status peningkatan proses - Process Performance Baseline, digunakan untuk mengukur data proses organisasi secara keseluruhan - Lesson Learned, digunakan untuk mencatat lesson learned, best practice, strength/weaknessess yang ditemukan dalam proyek. Mengacu pada no.4. Standar lingkungan kerja dalam organisasi telah ditetapkan dalam kebijakan Quality Policy and Manual. Organisasi telah menetapkan panduan Team Formation, yang memberikan arahan mengenai bagaimana membentuk struktur tim proyek Organizational Training (OT) Organisasi telah memiliki kebijakan dan prosedur yang digunakan terkait pengelolaan training dalam organisasi. Secara garis besar, training dalam organisasi terbagi atas dua jenis yaitu:

52 116 a) Internal training, yaitu training yang dilakukan oleh organisasi. b) External training, yaitu training yang dilakukan bukan oleh organisasi. Setiap tahun, training staff membuat kurikulum training untuk setahun kedepan. Namun, jika terdapat kebutuhan untuk training pada proyek pengembangan aplikasi, PM dapat membuat permintaan training kemudian memberikannya kepada training staff. Training staff akan menentukan apakah training tersebut dapat akan dilakukan secara eksternal atau internal. Pada tahap akhir, seluruh permintaan training akan diperiksa dan disahkan oleh unit head. Seusai training selesai dilakukan, setiap trainee harus mengisi training feedback form dan trainer harus mengisi laporan training dan training feedback summary kemudian memberikannya ke training staff sebagai bahan pengukuran training. Berdasarkan observasi, praktik praktik yang dibutuhkan telah tersedia pada saat Proyek A dilakukan, dan belum terdapat perubahan proses OT sampai saat ini. Sehingga, tidak tidak terdapat perbedaan antara hasil pengukuran pada Proyek A maupun

53 117 Gambar. 4.17Hasil Pengukuran Area Proses OT Pengukuran yang dilakukan pada area proses OT untuk Proyek A maupun memberi informasi bahwa praktik yang dilakukan pada area proses ini sudah memenuhi tujuan praktik. Tabel 4.19 Hasil Pengukuran Area Proses OT Deskripsi No Praktik 1 Menetapkan dan mengelola kebutuhan pelatihan strategis organisasi 2 Menentukan kebutuhan pelatihan mana yang menjadi tanggung jawab Area Proses: Organizational Training (OT) Proyek A Secara keseluruhan pelatihan organisasi dikelola oleh unit Training. Anggaran untuk pelatihan tahunan dan anggaran training proyek ditetapkan diawal tahun. Kebutuhan untuk training internal dan training terkait proyek dikomunikasikan lewat PM terkait, sedangkan training eksternal diidentifikasi berdasarkan skill assessment. Training spesifik untuk proyek menjadi tanggung jawab PM proyek, sedangkan training lainnya dikelola oleh unit Training. Secara keseluruhan pelatihan organisasi dikelola oleh unit Training. Anggaran untuk pelatihan tahunan dan anggaran training proyek ditetapkan diawal tahun. Kebutuhan untuk training internal dan training terkait proyek dikomunikasikan lewat PM terkait, sedangkan training eksternal diidentifikasi berdasarkan skill assessment. Training spesifik untuk proyek menjadi tanggung jawab PM proyek, sedangkan training lainnya dikelola oleh unit Training.

54 118 Area Proses: Organizational Training (OT) No Deskripsi Praktik Proyek A organisasi dan mana yang dapat menjadi tanggung jawab proyek individual atau grup pendukung 3 Menetapkan dan Rencana training dan Rencana training dan mengelola kurikulum training terkait kurikulum training terkait rencana taktis ditetapkan diawal tahun. ditetapkan diawal tahun. pelatihan organisasi 4 Menetapkan dan Instruktur training yang akan Instruktur training yang akan mengelola digunakan diseleksi dan digunakan diseleksi dan kapabilitas diidentifikasi oleh unit diidentifikasi oleh unit pelatihan untuk Training. Materi training Training. Materi training mengakomodasi disimpan dalam repositori disimpan dalam repositori kebutuhan unit Training. unit Training. pelatihan organisasi 5 Memberikan Materi training, training Materi training, training pelatihan sesuai feedback, training attendace feedback, training attendace rencana taktis list telah dikelola oleh unit list telah dikelola oleh unit pelatihan Training. Training. organisasi 6 Menetapkan dan Mengacu pada no. 7. Mengacu pada no. 7. mengelola catatan pelatihan organisasi 7 Menilai efektifitas program pelatihan organisasi Efektifitas training didokumentasikan dalam Training Effectiveness Form dan dikelola oleh unit Training. Efektifitas training didokumentasikan dalam Training Effectiveness Form dan dikelola oleh unit Training Integrated Project Management (IPM) Berdasarkan observasi pada area proses IPM untuk proyek A dan proyek B, diketahui terdapat peningkatan proses yang cukup signifikan berkat penerapan CMMI pada organisasi. Area proses IPM bertujuan untuk memastikan organisasi telah menetapkan proses proses pengembangan proyek aplikasi mulai dari awal

55 119 proyek melewati siklus hidup proyek menggunakan proses yang telah didefinisikan dalam mengelola proyek. Mengacu pada Gambar 4.17, dalam proyek A terdapat beberapa praktik yang belum sepenuhnya memenuhi tujuan sebanyak 10%, dan 40% praktik belum diterapkan sesuai dengan tujuan organisasi. Gambar Hasil Pengukuran Area Proses IPM Sedangkan pada proyek B, dapat terlihat bahwa praktik praktik pada area proses IPM telah memenuhi tujuan. Hal ini memperlihatkan bahwa proses pengembangan aplikasi untuk area proses IPM telah meningkat.

56 120 Tabel 4.20 Hasil Pengukuran Area Proses IPM No Area Proses: Integrated Project Management (IPM) Deskripsi Praktik Proyek A Proses dan siklus hidup Proses dan siklus hidup proyek telah ditetapkan proyek telah ditetapkan sesuai dengan prosedur sesuai dengan prosedur organisasi dan organisasi dan didokumentasikan dalam didokumentasikan dalam perencanaan proyek. perencanaan proyek. Namun, rencana untuk keterlibatan stakeholder, aktivitas audit, configuration management plan, dan pengukuran/metrik tidak tersedia. 1 Menetapkan dan mengelola proses proyek 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 Mengintegrasikan rencana proyek dan rencana lainnya yang mempengaruhi proyek untuk menggambarkan proses proyek terdefinisi 5 Mengelola proyek menggunakan rencana proyek, rencana lainnya yang mempengaruhi proyek dan proses proyek terdefinisi Estimasi telah tersedia untuk mengetahui upaya, waktu dan biaya namun tidak menggunakan aset proses organisasi (misal: Function Point Calculation (FPC), Project Costing Detail (ProcTail)). Pengelolaan lingkungan kerja proyek (misal: tools yang digunakan, laporan kinerja proyek, dukungan, dsb) telah tercakup dalam Project management plan. Rencana proyek telah tercakup dalam Project management plan dan jadwal proyek telah ditetapkan. Pembaharuan pada dokumen diatas dilakukan sesuai revisi/perubahan yang terjadi. Mengacu pada no. 4. PI NI Estimasi telah dibuat untuk mengukur upaya, waktu serta biaya yang dibutuhkan dalam melakukan proyek. Estimasi dibuat dalam bentuk estimasi bentuk FPC. Anggaran proyek dikelola menggunakan ProcTail. Pengelolaan lingkungan kerja proyek (misal: tools yang digunakan, laporan kinerja proyek, dukungan, dsb) telah tercakup dalam Project management plan. Rencana proyek telah tercakup dalam Project management plan dan jadwal proyek telah ditetapkan. Pembaharuan pada dokumen diatas dilakukan sesuai revisi/perubahan yang terjadi. Mengacu pada no. 4.

57 121 No Area Proses: Integrated Project Management (IPM) Deskripsi Praktik Proyek A Struktur tim proyek telah Struktur tim proyek telah tercakup dalam Project tercakup dalam Project management plan. Tugas management plan. Tugas dan tanggung jawab telah dan tanggung jawab telah tim proyek telah tersedia. tim proyek telah tersedia. 6 Menetapkan dan mengelola tim 7 Mengkontribusikan pengalaman terkait proses kedalam 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 Lesson learned digunakan untuk mencatat ide - ide peningkatan terhadap aset proses organisasi. Tidak dilakukan identifikasi terhadap keterlibatan stakeholder terkait. Tidak dilakukan identifikasi terhadap keterlibatan stakeholder terkait. Tidak dilakukan identifikasi terhadap keterlibatan stakeholder terkait. NI NI NI Lesson learned digunakan untuk mencatat ide - ide peningkatan terhadap aset proses organisasi. RACI (Responsible, Accountable, Consult, & Inform) matrix digunakan untuk mengidentifikasi keterlibatan stakeholder. Keterlibatan dipantau lewat aktivitas meeting status proyek dan progress review. Hasil review yang dilakukan dengan stakeholder terkait (TL, QA) telah tersedia. Identifikasi risiko dan isu telah dilakukan dan dimonitor hingga penyelesaian. Mengacu pada no Risk Management (RSKM) Area proses RSKM bertujuan untuk memastikan masalah yang mungkin timbul dapat diidentifikasi sedini mungkin sebelum masalah tersebut muncul pada proyek sehingga dapat dilakukan tindakan penanganan risiko seperti yang dibutuhkan. Proses identifikasi risiko dan isu pada proyek pengembangan aplikasi dilakukan dengan menggunakan Risk and Issue List (RIL). Risiko dan isu diidentifikasi mulai dari kick off meeting, dan diperbaharui

58 122 statusnya selama proyek berlangsung. RIL digunakan untuk mengidentifikasi risiko dan isu, memperbaharui statusnya, dan merencanakan tindakan mitigasi dan mengetahui dampak risiko dan isu. Terdapat beberapa komponen risiko yang dapat digunakan dalam proyek pengembangan aplikasi, salah satunya berdasarkan kemungkinan munculnya (occurrence probability) seperti dibawah ini: a) Very unlikely to happen, contoh: kerusakan pada server dikarenakan serangan virus. b) Sometimes happen and predictable, contoh: perubahan terhadap kebutuhan dalam fase konstruksi. c) Likely to occur and predictable, contoh: satu atau lebih pekerjaan diberikan kepada tim proyek yang kurang berpengalaman sehingga berisiko pada terlambat memenuhi deadline. d) Most likely to happen, repetitive but rarely predictable, contoh: terdapat tim proyek yang sakit/mengundurkan diri.

59 123 Gambar Hasil Pengukuran Area Proses RSKM Berdasarkan observasi, sebelum menerapkan CMMI terdapat kelemahan pada area proses RSKM seperti yang terlihat di Proyek A, dimana sebesar 57% praktik masih belum diterapkan sesuai tujuan praktik. Hal ini dikarenakan belum tersedianya penetapan rencana manajemen risiko diawal proyek, tidak diidentifikasinya beberapa komponen risiko serta tidak diidentifikasinya kategori risiko pada proyek A. Sedangkan setelah penerapan CMMI, terlihat bahwa area proses RSKM telah meningkat seperti yang ditunjukkan pada hasil pengukuran untuk, namun masih ditemukan kelemahan minor yakni tidak diperbaharuinya status risiko dalam proyek.

60 124 Tabel 4.21 Hasil Pengukuran Area Proses RSKM Area Proses: Risk Management (RSKM) No Deskripsi Praktik Proyek A 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 Risk and Issue List (RIL) telah dibuat dan dikelola selama Proyek A berlangsung. Sumber risiko dan isu telah diidentifikasi. Analisa terhadap isu dilakukan untuk mengetahui mitigasi dan follow-up yang perlu dilakukan. Paramater risiko telah didefinisikan dalam RIL. RIL dibuat pada saat risk identification session di kick-off meeting, yang mencakup identifikasi risiko, analisa risiko dan prioritisasi risiko. Tidak terdapat risk management plan (perencanaan manajemen risiko) pada proyek A. Beberapa komponen risiko (misal: impact rate, occurrence probability, priority) tidak diidentifikasi pada proyek A. Kategori risiko (misal: high, medium atau low) belum diidentifikasi. Tidak terdapat risk management plan (perencanaan manajemen risiko) pada proyek A. NI NI NI NI Risk and Issue List (RIL) telah dibuat dan dikelola selama berlangsung. Sumber risiko dan isu telah diidentifikasi. Analisa terhadap isu dilakukan untuk mengetahui mitigasi dan follow-up yang perlu dilakukan. Paramater risiko telah didefinisikan dalam RIL. RIL dibuat pada saat risk identification session di kick-off meeting, yang mencakup identifikasi risiko, analisa risiko dan prioritisasi risiko. Strategi yang digunakan untuk manajemen risiko mengacu pada panduan manajemen risiko proyek. Risiko telah teridentifikasi dan didokumentasikan dalam RIL. Berdasarkan analisa, risiko yang teridentifikasi dikategorikan dalam cost/budget risk dan tidak termasuk pada high priority risk. Rencana mitigasi telah tersedia

61 125 Area Proses: Risk Management (RSKM) No Deskripsi Praktik Proyek A 7 Memantau status dari setiap risiko secara periodik dan mengimplementasikan rencana mitigasi risikodengan sesuai risiko telah dimonitor namun berdasarkan observasi, risiko terkait tidak muncul pada proyek. Berdasarkan observasi, status dari risiko belum diperbaharui dalam dokumen RIL. LI Decision Analysis and Resolution (DAR) Area proses DAR bertujuan untuk memastikan terdapat prosedur pengukuran secara formal untuk untuk pengambilan keputusan terhadap masalah tertentu yang menjadi subyek pengukuran. Sebelum menerapkan CMMI, organisasi belum memiliki prosedur pengukuran formal untuk pengambilan keputusan. Hal ini terlihat pada Gambar 4.19, dimana Proyek A sama sekali belum memenuhi tujuan praktik (100% not yet). Gambar Hasil Pengukuran Area Proses DAR

62 126 Saat ini organisasi telah menetapkan prosedur dan panduan proses pengukuran formal yang dimulai dari identifikasi keputusan alternatif, menetapkan kriteria kriteria pengukuran masalah, pemilihan keputusan, identifikasi risiko atas keputusan yang diambil hingga komunikasi atas hasil pengukuran. Proses pengukuran dilakukan dengan menggunakan Formal Evaluation Form. Penggunaan prosedur pengukuran formal ini tidak hanya terbatas pada pengukuran masalah dan pengambilan keputusan pada proses pengembangan aplikasi, namun dapat digunakan juga untuk proses dan unit lain diluar pengembangan aplikasi yang membutuhkan. Tabel 4.22 Hasil Pengukuran Area Proses DAR No Area Proses: Decision Analysis and Resolution (DAR) Deskripsi Proyek A Praktik 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 Tidak terdapat panduan untuk menentukan item apa yang perlu menjadi subyek evaluasi formal dalam Proyek A. Tidak terdapat panduan untuk menentukan item apa yang perlu menjadi subyek evaluasi formal dalam Proyek A. Tidak terdapat panduan untuk menentukan item apa yang perlu menjadi subyek evaluasi formal dalam Proyek A. NY NY NY Panduan evaluasi formal telah tersedia dalam Project management plan. Subyek yang dievaluasi adalah terkait penggunaan bahasa pemrograman C++ & C# sesuai permintaan klien di RFP. Kriteria evaluasi yang digunakan sesuai dengan yang tercantum dalam prosedur Formal Evaluation. Berdasarkan observasi, tidak diperlukan solusi alternatif dikarenakan sumber daya yang dimiliki dalam perusahaan telah menguasai bahasa pemrograman terkait.

63 127 No Area Proses: Decision Analysis and Resolution (DAR) Deskripsi Proyek A Praktik 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 Tidak terdapat panduan untuk menentukan item apa yang perlu menjadi subyek evaluasi formal dalam Proyek A. Tidak terdapat panduan untuk menentukan item apa yang perlu menjadi subyek evaluasi formal dalam Proyek A. Tidak terdapat panduan untuk menentukan item apa yang perlu menjadi subyek evaluasi formal dalam Proyek A. NY NY NY Metode evaluasi yang digunakan adalah dengan pembobotan terhadap kriteria evaluasi. Mengacu pada no.3. Mengacu pada no Ringkasan Hasil Pengukuran Berdasarkan pengukuran dampak penerapan CMMI yang dilakukan pada proyek A dan B, dapat terlihat bahwa terdapat peningkatan proses pengembangan aplikasi yang terjadi setelah organisasi menerapkan CMMI. Ringkasan hasil pengukuran yang dilakukan dapat dilihat pada Tabel dibawah. Sementara itu, peningkatan proses sebelum penerapan CMMI dapat terlihat pada Gambar dan Gambar yang menunjukkan peningkatan proses pada maturity level 2 dan 3. Hal ini disebabkan karena Telkomsigma telah menetapkan dan mengelola proses pengembangan aplikasi mereka berdasarkan CMMI best practices sesuai dengan proses terkait.

64

65 1 128 Tabel Ringkasan Hasil Pengukuran Seluruh Area Proses pada Proyek A dan Maturity Level ML 2 ML3 Area Jumlah % Kepatuhan Proyek A % Kepatuhan Proses Praktik LI PI NI NY LI PI NI NY REQM 5 80% 20% 0% 0% 0% 100% 0% 0% 0% 0% PP 14 29% 0% 36% 36% 0% 86% 14% 0% 0% 0% PMC 10 80% 0% 10% 10% 0% 100% 0% 0% 0% 0% SAM 6 100% 0% 0% 0% 0% 100% 0% 0% 0% 0% M&A 8 50% 0% 13% 38% 0% 100% 0% 0% 0% 0% PPQA 4 50% 0% 25% 25% 0% 100% 0% 0% 0% 0% CM 7 0% 0% 0% 0% 100% 100% 0% 0% 0% 0% RD % 0% 0% 0% 0% 100% 0% 0% 0% 0% TS 8 100% 0% 0% 0% 0% 100% 0% 0% 0% 0% PI 9 100% 0% 0% 0% 0% 100% 0% 0% 0% 0% VER 8 88% 0% 13% 0% 0% 100% 0% 0% 0% 0% VAL 5 100% 0% 0% 0% 0% 100% 0% 0% 0% 0% OPF 9 67% 0% 11% 22% 0% 100% 0% 0% 0% 0% OPD 7 100% 0% 0% 0% 0% 100% 0% 0% 0% 0% OT 7 100% 0% 0% 0% 0% 100% 0% 0% 0% 0% IPM 10 50% 0% 10% 40% 0% 100% 0% 0% 0% 0% RSKM 7 43% 0% 0% 57% 0% 86% 14% 0% 0% 0% DAR 6 0% 0% 0% 0% 100% 100% 0% 0% 0% 0%

66

67 129 Gambar Hasil Pengukuran pada Maturity Level 2 Seperti yang ditunjukan pada gambar 4.21 (a), beberapa proses area di Maturity Level 2 seperti REQM, PP, M&A, PPQA dan CM memiliki beberapa kelemahan mayor sebelum Telkomsigma menerapkan CMMI. Hal ini dikarenakan pada area area tersebut masih terdapat beberapa proses yang belum dilakukan dengan maksimal. Sebagai contoh pada proses REQM belum terdapat identifikasi bidirectional traceability antara kebutuhan untuk mengetahui asosiasi antara kebutuhan yang satu dengan kebutuhan lain ketika TL membuat Requirement Verification Matrix (RVM). Sementara itu pada proses lain seperti PP, belum adanya perencanaan untuk aktivitas audit proyek, belum terdapat identifikasi dari stakeholder terkait, serta belum dilakukannya kajian terhadap perencanaan proyek membuat area proses ini masih membutuhkan beberapa perbaikan. Hal yang serupa juga terjadi pada proses area lain yaitu tidak maksimalnya proses pengembangan aplikasi yang dilakukan. Setelah Telkomsigma

68 130 menerapkan CMMI, mayoritas area proses pada Maturity Level 2 telah mengalami peningkatan seperti yang ditunjukan pada gambar 4.21 (b). Gambar Hasil Pengukuran pada Maturity Level 3 Pada gambar 4.22 (a) diatas, sebelum Telkomsigma menerapkan CMMI, proses area Maturity Level 3 seperti VER, OPF, IPM, RSKM dan DAR memiliki kelemahan mayor. Serupa dengan Maturity Level 2, masih terdapat beberapa proses yang tidak dilakukan sesuai dengan best practice. Misalnya area proses VER, ditemukan tidak didokumentasikannya laporan hasil peer review. Kemudian pada OPF belum terdapat deskripsi kebutuhan proses dan objektif organisasi serta Perencanaan audit proses belum tersedia. Peningkatan proses dapat dilihat pada gambar 4.23 (b) diatas, dimana hampir seluruh proses area sudah tidak memiliki kelemahan mayor.