UNIVERSITAS INDONESIA

(1)

UNIVERSITAS INDONESIA

PERANCANGAN KERANGKA PENILAIAN KAPASITAS

PENYEDIA JASA KONSULTANSI PERANGKAT LUNAK

YANG MENGACU PADA CMMI-DEV :

STUDI KASUS KEMENTERIAN SEKRETARIAT NEGARA

KARYA AKHIR

Diajukan sebagai salah satu syarat untuk memperoleh gelar Magister Teknologi Informasi

HERU MARTIN SAPUTRA

1206302560

FAKULTAS ILMU KOMPUTER

PROGRAM STUDI MAGISTER TEKNOLOGI INFORMASI

JAKARTA

(2)

Karya Akhir ini adalah hasil karya saya sendiri, dan semua sumber baik yang dikutip maupun dirujuk

telah saya nyatakan dengan benar.

Nama : Heru Martin Saputra

NPM : 1206302560

Tanda tangan :

(3)

iii Universitas Indonesia HALAMAN PENGESAHAN

Karya Akhir ini diajukan oleh :

Nama : Heru Martin Saputra

NPM : 1206302560

Program Studi : Magister Teknologi Informasi

Judul Karya Akhir : Perancangan Kerangka Penilaian Kapasitas Penyedia Jasa Konsultansi Perangkat Lunak yang Mengacu pada CMMI-Dev : Studi Kasus Kementerian Sekretariat Negara

Telah berhasil dipertahankan di hadapan Dewan Penguji dan diterima sebagai bagian persyaratan yang diperlukan untuk memperoleh gelar Magister Teknologi Informasi pada Program Studi Magister Teknologi Informasi, Fakultas Ilmu Komputer, Universitas Indonesia.

DEWAN PENGUJI

Pembimbing : Alex Ferdinansyah M.Kom. (…...……...)

Penguji : Dr. Eko K. Budiardjo (…...……...)

Penguji : Yudho Giri Sucahyo, Ph.D. (…...……...)

Ditetapkan di : Jakarta

Tanggal :

(4)

KATA PENGANTAR

Segala puji dan syukur penulis panjatkan kehadirat Allah SWT, yang telah melimpahkan rahmat, taufik, nikmat, dan hidayah-Nya, sehingga Karya Akhir ini dapat penulis selesaikan. Penulisan Karya Akhir ini dilakukan dalam rangka memenuhi salah satu syarat untuk mencapai gelar Magiter Teknologi Informasi pada Program Studi Magister Teknologi Informasi, Fakultas Ilmu Komputer, Universitas Indonesia. Penulis menyadari bahwa, bantuan dan bimbingan dari berbagai pihak, dari masa perkuliahan sampai pada penyusunan karya akhir ini, sangat berarti bagi penulis dalam menyelesaikan karya akhir ini.

Dalam kesempatan yang baik ini penulis ingin menyampaikan penghargaan yang setinggi-tingginya dan terima kasih yang sedalam-dalamnya kepada semua pihak yang telah memberikan perhatian, dukungan, dan bantuannya dalam penyelesaian karya akhir ini, diantaranya adalah:

1. Bapak Alex Ferdinansyah M.Kom. selaku dosen pembimbing yang telah menyediakan waktu, tenaga, dan pikiran untuk mengarahkan penulis dalam penyusunan karya akhir ini.

2. Bapak Dr. Eko K. Budiardjo dan Bapak Yudho Giri Sucahyo, Ph.D. selaku dosen penguji yang telah memberikan masukan, saran, dan kritikan demi penyempurnaan karya akhir ini.

3. Seluruh Dosen MTI Universitas Indonesia, yang telah memberikan pembelajaran, bimbingan, dan pencerahan yang sangat bermanfaat bagi penulis dalam meningkatkan wawasan keilmuan dan kualitas kepribadian. 4. Bapak Dr. Drs. Cecep Sutiawan, M.Si., Deputi Bidang Sumber Daya Manusia

Kementerian Sekretariat Negara, yang telah memberikan kesempatan dan motivasi dalam menyelesaikan tugas belajar ini.

5. Kementerian Komunikasi dan Informatika RI sebagai instansi pemberi beasiswa Government Chief Information Officer (GCIO).

(5)

v Universitas Indonesia selaku Kepala Biro Administrasi Pejabat Negara, dan Bapak Andrie Syahriza, S.Kom., M.Si. selaku Asisten Deputi Dukungan Data Kebijakan dan Informatika.

7. Bapak dan Ibu, orang tua tercinta, yang selalu mendoakan, memberikan dukungan, bimbingan, nasihat, serta menjadi suri tauladan yang baik.

8. Istri tercinta dan buah hati tersayang, yang telah menjadi semangat bagi penulis dalam menjalani pendidikan ini.

9. Adik-adik penulis atas dukungan dan doanya.

10.Seluruh Pejabat dan Pegawai di Asisten Deputi Dukungan Data Kebijakan dan Informatika, PT. Belant Persada, PT. Malloci Software Solution, dan CV. Torche Indonesia yang telah memberikan data dan informasi yang sangat berguna untuk kesempurnaan karya akhir ini.

11.Seluruh Pejabat dan Pegawai di Biro Administrasi Pejabat Negara yang telah memberikan dukungannya.

12.Bapak dan Ibu di Sekretariat MTI untuk pelayanan yang diberikan selama penulis belajar di MTI.

13.Seluruh sahabat di kelas 2012SA yang telah menjadi bagian dari perjalanan perjuangan dalam menempuh pendidikan dan pembelajaran di MTI UI.

14.Semua pihak yang telah berkenan membantu dalam penyelesaian karya akhir yang tidak dapat penulis sebutkan, semoga Allah SWT membalas semua kebaikan kalian.

Jakarta, 17 Januari 2014

(6)

HALAMAN PERNYATAAN PERSETUJUAN PUBLIKASI KARYA AKHIR UNTUK KEPENTINGAN AKADEMIS

Sebagai sivitas akademik Universitas Indonesia, saya yang bertanda tangan di bawah ini:

Nama : Heru Martin Saputra NPM : 1206302560

Program Studi : Magister Teknologi Informasi Fakultas : Ilmu Komputer

Jenis Karya : Karya Akhir

Demi pengembangan ilmu pengetahuan, menyetujui untuk memberikan kepada Universitas Indonesia Hak Bebas Royalti Nonekslusif (Non-exclusive Royalty-Free Right) atas karya ilmiah saya yang berjudul :

Perancangan Kerangka Penilaian Kapasitas Penyedia Jasa Konsultansi Perangkat Lunak yang Mengacu pada CMMI-Dev : Studi Kasus Kementerian Sekretariat Negara

Beserta perangkat yang ada (jika diperlukan). Dengan Hak Bebas Royalti Non-ekskutif ini Universitas Indonesia berhak menyimpan, mengalihmedia/formatkan, mengelola dalam bentuk pangkalan data (database). Merawat, dan mempublikasikan karya akhir saya tanpa meminta izin dari saya selama tetap mencantumkan saya sebagai penulis/pencipta dan sebagai pemilik Hak Cipta.

Demikian pernyataan ini saya buat dengan sebenarnya. Dibuat di : Jakarta

Pada tanggal : 17 Januari 2014 Yang menyatakan

(7)

vii Universitas Indonesia ABSTRAK

Nama : Heru Martin Saputra

Program Studi : Magister Teknologi Informasi

Judul : Perancangan Kerangka Penilaian Kapasitas Penyedia Jasa Konsultansi Perangkat Lunak yang Mengacu pada CMMI-Dev : Studi Kasus Kementerian Sekretariat Negara

Teknologi informasi (TI) telah menjadi bagian strategi bagi Kementerian Sekretariat Negara dalam rangka meningkatkan pelayanan dan kinerja. Hal ini dituangkan pada beberapa Peraturan Menteri Sekretaris Negara sebagai kebijakan dari organisasi yang ingin mengoptimalkan kinerja dengan dukungan TI di lingkungan Kementerian Sekretariat Negara. Perangkat lunak pun dibangun dan dikembangkan dalam menunjang kegiatan dari unit-unit kerja yang ada. Pengembangan dilakukan melalui lelang atau swakelola. Terlibatnya pihak luar dalam pengembangan perangkat lunak melalui lelang memerlukan pengawasan dan kontrol, karena kadang terjadi masalah dalam pengembangan perangkat lunak, seperti gagal dalam membangun atau pembangunan terlambat (tidak sesuai jadwal). Dalam rangka mendapatkan penyedia yang lebih berkualitas maka dilakukan kajian penilaian kapasitas penyedia perangkat lunak. Penilaian kapasitas dari penyedia dilakukan untuk mengetahui kualitas dari penyedia sehingga dapat mengurangi kesalahan atau kelemahan yang sering terjadi pada pengembangan melalui lelang. Capability Maturity Model Integration for Development (CMMI-DEV) representasi Continuous dan Standard CMMI Appraisal Method for Process Improvement (SCAMPI) digunakan sebagai bahan dalam merancang kerangka penilaian kapasitas penyedia. Rancangan kerangka penilaian kapasitas penyedia digunakan untuk dua hal, yaitu untuk menilai kapasitas peserta lelang sebagai calon penyedia, dan menilai penyedia pada saat pemeriksaan pekerjaan. Dengan adanya rancangan kerangka penilaian kapasitas penyedia diharapkan dapat memilih penyedia yang lebih baik lagi, dan sebagai pembelajaran bagi tenaga teknis di Unit Kerja TI Kementerian Sekretariat Negara dalam mengembangkan perangkat lunak secara swakelola.

Kata kunci : Kerangka Penilaian, CMMI-DEV, SCAMPI, model, tingkat kapasitas, area proses, specific practice, generic practice

(8)

ABSTRACT

Name : Heru Martin Saputra

Study program : Master of Information Technology

Title : Framework Designing of Capacity Assessment for Software Consultancy Provider Referring to CMMI-Dev: A Case Study in the Ministry of State Secretariat

Information technology ( IT ) has become a part of the strategy of the Ministry of State Secretariat in order to improve its services and performance. This matter is stated in some of the Regulations of the Ministry of State Secretary as the policies of the organization who wants to optimize the performance of the IT support at the Ministry of State Secretariat. The software is built and developed to support the activities of the available working units. The development process is performed through an auction or a self-management. The involvement of external parties in the development of software through an auction requires supervision and control, because sometimes there are problems in software development, such as building failure or late construction (behind schedule). In order to get a higher quality provider, then a capacity assessment study on software provider should be conducted. Assessment of the capacity of providers is conducted to know the quality of providers so that the errors or weaknesses that frequently occur in the development process through auction could be minimized. Capability Maturity Model Integration for Development (CMMI-DEV) Continuous representation and Standard CMMI Appraisal Method for Process Improvement (SCAMPI) are used as the materials in designing a framework for assessing the capacity of providers. The framework design of provider capacity assessment is used for two objectives, namely to assess the capacity of the prospective bidders as the candidates of the future providers, and to assess the provider when examining the work performed. With the framework design of provider capacity assessment, it is expected that a better provider can be chosen, and it is also expected that the technical personnel in the IT Work Unit of the Ministry of State Secretariat will be able to learn how to develop software by a self-management.

Keywords : Assessment Framework, CMMI-DEV, SCAMPI, the model, the level of capacity, process areas, specific practices, generic practice

(9)

ix Universitas Indonesia DAFTAR ISI

HALAMAN JUDUL ...i

HALAMAN PERNYATAAN ORISINALITAS ... ii

HALAMAN PENGESAHAN ... iii

KATA PENGANTAR ... iv

HALAMAN PERNYATAAN PERSETUJUAN PUBLIKASI ... vi

ABSTRAK ... vii

ABSTRACT ... viii

DAFTAR ISI ... ix

DAFTAR TABEL ... xiii

DAFTAR GAMBAR ... xv

DAFTAR LAMPIRAN ... xvi

BAB 1 PENDAHULUAN ... 1

1.1 Latar Belakang ... 1

1.2 Perumusan Masalah ... 3

1.3 Tujuan ... 8

1.4 Manfaat Penelitian ... 8

1.5 Ruang Lingkup Penelitian ... 8

BAB 2 KAJIAN PUSTAKA ... 10

2.1 Rekayasa Perangkat Lunak... 10

2.2 Manajemen Proyek TI ... 11

2.3 CMMI-DEV ... 12

2.3.1 Process Area ... 13

2.3.2 Representasi Continuous ... 15

2.3.3 Hubungan Antara Area Proses ... 19

2.3.4 Standard CMMI Appraisal Method for Process Improvement ... 22

2.4 Kerangka Standar Kompetensi Berbasis Kinerja dari GAPPS... 24

2.5 Projects in a Controlled Environment ... 26

2.6 PMBOK Guide ... 28

2.7 Perbandingan Manajemen Proyek ... 31

2.8 Penelitian Sebelumnya ... 32

(10)

BAB 3 METODOLOGI PENELITIAN ... 40

3.1 Tahapan Penelitian ... 40

3.2 Metode Pengumpulan Data ... 42

3.3 Metode Analisis Data ... 43

BAB 4 PROFILE ORGANISASI ... 44

4.1 Kementerian Sekretariat Negara... 44

4.1.1 Kedudukan, Tugas dan Fungsi Kementerian Sekretariat Negara ... 45

4.1.2 Struktur Organisasi Kementerian Sekretariat Negara ... 47

4.2 PT. Belant Persada ... 52

4.3 PT. Malloci Software Solution ... 53

4.3.1 Produk ... 54

4.3.2 Layanan ... 56

4.4 CV. Torche Indonesia ... 56

BAB 5 ANALISA DAN PEMBAHASAN ... 59

5.1 Pemilihan Proyek ... 59

5.2 Pemilihan Representasi CMMI ... 63

5.3 Pemilihan Area Proses ... 63

5.4 Proses Penilaian SCAMPI C ... 65

5.4.1 Plan and Prepare for Appraisal... 65

5.4.2 Conduct Appraisal ... 77

5.4.3 Report Results ... 77

5.5 Hasil Penilaian Penyedia 1 ... 78

5.5.1 Penilaian REQM Penyedia 1 ... 78

5.5.1.1 REQM Capability Level 1 Penyedia 1 ... 79

5.5.2 Penilaian PP Penyedia 1 ... 81

5.5.2.1 PP Capability Level 1 Penyedia 1 ... 82

5.5.3 Penilaian PMC Penyedia 1 ... 87

5.5.3.1 PMC Capability Level 1 Penyedia 1 ... 88

(11)

xi Universitas Indonesia

5.5.4 Penilaian SAM Penyedia 1 ... 91

5.6.1.2 REQM Capability Level Level 2 Penyedia 2 ... 93

5.8 Profil Capability Level ... 111

5.9 Verifikasi Kebutuhan Penilaian ... 113

5.10 Analisis Hubungan Masalah, Hasil Penilaian, dan Hasil Verifikasi ... 116

5.10.1 Keterhubungan Data Dalam REQM ... 119

5.10.2 Keterhubungan Data Dalam PP ... 122

5.10.3 Keterhubungan Data Dalam PMC ... 126

5.10.4 Keterhubungan Data Dalam SAM ... 129

(12)

5.12 Rekomendasi Kerangka Penilaian Kapasitas Penyedia ... 132

BAB 6 KESIMPULAN DAN SARAN ... 136 DAFTAR PUSTAKA ... 140

(13)

xiii Universitas Indonesia DAFTAR TABEL

Tabel 1.1 Kebutuhan Pendanaan Sistem Informasi ... 2

Tabel 2.1 Unit Kompetensi ... 25

Tabel 2.2 Penelitian Sebelumnya ... 36

Tabel 5.1 Skala Karakter Penilaian ... 66

Tabel 5.2 Persiapan Penilaian Proyek 1 ... 66

Tabel 5.5 Rencana Penilaian ... 71

Tabel 5.6 Daftar Dokumen ... 72

Tabel 5.7 Penilaian REQM CL 1 Penyedia 1 ... 79

Tabel 5.9 Penilaian PP CL 1 Penyedia 1 ... 83

Tabel 5.10 Penilaian PP CL 2 Penyedia 1... 85

Tabel 5.11 Penilaian PMC CL 1 Penyedia 1... 88

Tabel 5.25 Verifikasi REQM ... 114

Tabel 5.26 Verifikasi PP ... 114

Tabel 5.27 Verifikasi PMC ... 115

(14)

Tabel 5.29 Data Masalah... 117

Tabel 5.30 Skala Karakter Rekomendasi ... 118

Tabel 5.31 Keterhubungan Data Dalam REQM ... 121

Tabel 5.32 Keterhubungan Data Dalam PP ... 125

Tabel 5.33 Keterhubungan Data Dalam PMC ... 128

Tabel 5.34 Keterhubungan Data Dalam SAM ... 130

Tabel 6.1 Penilaian pada Area Proses REQM ... 137

Tabel 6.2 Penilaian pada Area Proses PP ... 137

(15)

xv Universitas Indonesia DAFTAR GAMBAR

Gambar 1.1 Fishbone Analysis ... 4

Gambar 2.1 CMMI Model Components... 14

Gambar 2.2 Basic Project Management Process Areas ... 21

Gambar 2.3 Theoretical Framework ... 39

Gambar 3.1 Tahapan Penelitian ... 42

Gambar 4.1 Struktur Organisasi Kementerian Sekretariat Negara ... 48

(16)

DAFTAR LAMPIRAN

Lampiran 1 : Wawancara Lampiran 2 : Administrasi

Lampiran 3 : Keterangan Goals dan Practices dari Process Area

Lampiran 4 : Rancangan Penilaian Kapasitas Penyedia

Lampiran 5 : Rancangan Formulir Penilaian Kapasitas Penyedia

(17)

1 Universitas Indonesia BAB 1

PENDAHULUAN

1.1 Latar Belakang

Berdasarkan Peraturan Presiden Republik Indonesia Nomor 58 Tahun 2010, Kementerian Sekretariat Negara berada di bawah dan bertanggung jawab kepada Presiden yang dipimpin oleh Menteri Sekretaris Negara. Kementerian Sekretariat Negara mempunyai tugas memberikan dukungan teknis dan administrasi serta analisis kepada Presiden dan Wakil Presiden dalam menyelenggarakan kekuasaan negara.

Sebagai kementerian yang berada di bawah Presiden, Kementerian Sekretariat Negara memiliki tugas yang sangat vital. Karena dukungan teknis, administrasi, dan analisis dari Kementerian Sekretariat Negara akan langsung terhubung ke Presiden dan Wakil Presiden yang akan mempengaruhi kinerja Presiden dan Wakil Presiden. Dalam rangka memberikan pelayanan prima kepada Presiden dan Wakil Presiden, serta meningkatkan kualitas dan kapasitas kinerja, Kementerian Sekretariat Negara memanfaatkan sistem informasi/teknologi informasi (SI/TI) agar ketatalaksanaan organisasi dapat dilakukan dengan efektif dan efisien mengacu pada kebutuhan, skala prioritas, pengurangan duplikasi (tumpang tindih) kegiatan, serta perlunya pengendalian dan pengawasan kinerja organisasi.

Pemanfaatan SI/TI menjadi penting bagi Kementerian Sekretariat Negara, ini dapat dilihat dimana SI/TI sudah dituangkan pada beberapa peraturan menteri. Pada Rencana Strategis (Renstra) yang tertuang dalam Peraturan Menteri Sekretaris Negara Nomor 2 Tahun 2010 tentang Rencana Strategis Sekretariat Negara Republik Indonesia tahun 2010-2014 yang disempurnakan pada Peraturan Menteri Sekretaris Negara Nomor 7 Tahun 2011 tentang Penyempurnaan Rencana Strategis Kementerian Sekretariat Negara Republik Indonesia tahun 2010-2014, SI/TI menjadi salah satu program Renstra, yaitu program dukungan manajemen dan pelaksanaan tugas teknis lainnya Kementerian Sekretariat Negara dengan

(18)

salah satu outcome-nya meningkatnya kualitas analisis dan kecepatan dalam memberikan dukungan informatika. Pada tabel 1.1 dapat dilihat anggaran yang dialokasikan untuk penerapan dan pengembangan sistem informasi di Kementerian Sekretariat Negara dari tahun 2010 sampai 2014. Anggaran tersebut merupakan investasi pada bidang sistem informasi dalam rangka meningkatkan kualitas analisis dan kecepatan dalam memberikan dukungan informatika. Dengan anggaran tersebut diharapkan dapat mewujudkan ketersediaan sistem aplikasi, layanan infrastruktur jaringan dan layanan data dan informasi dukungan kebijakan yang dapat memaksimalkan kinerja Kementerian Sekretariat Negara.

Tabel 1.1 Kebutuhan Pendanaan Sistem Informasi Tahun Anggaran Anggaran (Rp)

2010 5.260.782.000 2011 3.377.251.000 2012 6.969.000.000 2013 7.270.000.000 2014 8.704.000.000

Sumber : Peraturan Menteri Sekretaris Negara Republik Indonesia Nomor 7 Tahun 2011

Peraturan Menteri Sekretaris Negara Republik Indonesia Nomor 9 Tahun 2011 tentang Road Map Reformasi Birokrasi Kementerian Sekretariat Negara Republik Indonesia tahun 2010-2014, selain memaparkan capaian Reformasi Birokrasi gelombang I Tahun 2005-2010 pada Bidang Sistem Informasi Manajemen juga mencantumkan rencana program Reformasi Birokrasi gelombang II yang menargetkan peningkatan penggunaan Teknologi Informasi (TI) dalam proses penyelenggaraan manajemen pemerintahan di Kementerian Sekretariat Negara dengan kegiatan pembangunan proses manajemen pemerintahan menggunakan TI. Dan pada Peraturan Menteri Sekretaris Negara Nomor 14 Tahun 2011 tentang

(19)

Sistem Informasi Kementerian Sekretariat Negara (SIKSN) untuk tahun 2011-2014 adalah: ”Tersedianya dukungan data dan informasi serta ketatalaksanaan berbasis TIK yang terintegrasi dalam rangka memujudkan layanan teknis dan administrasi yang prima kepada Presiden dan Wakil Presiden”.

Tiga kebijakan yang ada diharapkan dapat menguatkan dan memperjelas arah implementasi dan pengembangan SI/TI di Kementerian Sekretariat Negara yang saat ini bukan saja menjadi pendukung proses bisnis unit-unit kerja tetapi diharapkan menjadi bagian dari proses bisnis pada unit-unit kerja yang membutuhkannya. Berdasarkan hasil rapat-rapat koordinasi aplikasi pada tahun 2011 antara unit-unit kerja di Kementerian Sekretariat Negara yang mengajukan dukungan SI dengan Asisten Deputi Dukungan Data Kebijakan dan Informatika (unit kerja pengelola TI di Kementerian Sekretariat Negara), disimpulkan 9 (sembilan) unit kerja mengajukan dukungan SI untuk mendukung proses bisnisnya dengan jumlah pengajuan sebanyak 16 (enam belas) aplikasi. Adanya semangat dari unit-unit kerja yang ingin mengimplementasikan SI harus segera ditindaklanjuti oleh unit kerja TI untuk menjaga gairah penerapan SI yang memang membutuhkan kecepatan dan ketepatan.

1.2 Perumusan Masalah

Berdasarkan Peraturan Menteri Sekretaris Negara Republik Indonesia Nomor 7 Tahun 2011, Peraturan Menteri Sekretaris Negara Republik Indonesia Nomor 9 Tahun 2011, dan Peraturan Menteri Sekretaris Negara Republik Indonesia Nomor 14 Tahun 2011 serta observasi dari penulis, dapat diketahui sejak tahun 2010 Kementerian Sekretariat Negara memiliki rencana pengembangan 18 (delapan belas) perangkat lunak. Saat ini 6 (enam) perangkat lunak yang sudah terimplementasi, 5 (lima) perangkat lunak masih proses pembangunan, dan 7 (tujuh) perangkat lunak belum dilaksanakan. Belum terimplementasinya perangkat lunak yang sudah direncanakan tentu akan menjadi masalah, bahkan untuk pengembangan yang dilakukan melalui proses lelang apabila gagal dikembangkan akan berdampak pada penundaan pengembangan atau hilang pada perencanaan pengembangan pada tahun berikutnya. Walaupun ini memiliki solusi dengan pengalihan pengembangan menjadi swakelola, namun bertambahnya

(20)

antrian pengembangan dengan swakelola akan menyebabkan penundaan implementasi program dalam waktu yang cukup lama.

Dari masalah pengembangan perangkat lunak yang merujuk pada kebijakan-kebijakan yang ada, dan kebutuhan-kebutuhan dukungan perangkat lunak yang terus muncul menjadi bahan evaluasi dalam strategi peningkatan kualitas proses pengembangan perangkat lunak di Kementerian Sekretariat Negara kedepannya. Berdasarkan observasi penulis dan wawancara kepada pejabat dan tenaga teknis unit kerja TI di Kementerian Sekretariat Negara, ada beberapa hal yang menjadi kendala sehingga belum terimplementasinya perangkat lunak yang sudah direncanakan. Kendala-kendala yang ada tergambar pada gambar 1.1 tentang

Fishbone Analysis dari belum terimplementasi perangkat lunak yang sudah direncanakan.

(21)

Dari gambar fishbone analysis di atas dapat dilihat 3 (tiga) kelompok kendala yang membuat belum terimplementasinya perangkat lunak yang sudah direncanakan. Berikut penjabaran kendala-kendala yang ada:

A. Pengguna

Berdasarkan hasil wawancara, pemahaman pengguna terhadap kebutuhannya menjadi permasalahan dalam pengembangan perangkat lunak. Pengguna yang tidak paham terhadap kebutuhannya akan menyebabkan scope perkerjaan menjadi berubah-ubah, sehingga mempengaruhi waktu pengerjaan menjadi bertambah panjang. Terlebih apabila pengembangan dilakukan melalui pelelangan, dimana waktu dan biaya tidak dapat berubah (wawancara dengan Asisten Deputi Dukungan Data Kebijakan dan Informatika pada tanggal 13 Agustus 2013). Untuk itu dibutuhkan diskusi yang lebih terhadap pengguna untuk lebih memahami kebutuhannya, karena hal ini juga terkait dengan kesiapan pengguna dalam mengimplementasi perangkat lunak tersebut. Implementasi perangkat lunak akan merubah pola kerja pengguna, selama ini yang dilakukan secara manual akan berubah dengan lebih banyak berinteraksi dengan komputer. Ada sebagian pengguna yang belum siap, sehingga membutuhkan waktu yang lebih lama dalam menggunakan aplikasi tersebut (wawancara dengan Kepala Bidang Pengembangan Sistem pada tanggal 13 Agustus 2013).

B. Swakelola

Pengembangan perangkat lunak di Kementerian Sekretariat Negara dilakukan dengan dua cara. Cara pertama dengan pelelangan, dimana pekerjaan akan dilelang, pengembangan perangkat lunak akan dilakukan oleh perusahaan luar yang terikat kontrak dengan Kementerian Sekretariat Negara. Dan yang kedua dengan swakelola, dimana pengembangan perangkat lunak akan dilakukan oleh pranata komputer Kementerian Sekretariat Negara. Dalam pengembangan perangkat lunak dengan swakelola terdapat beberapa kendala terkait implementasi perangkat lunak. Berdasarkan wawancara dan observasi, kegiatan pengembangan perangkat lunak secara swakelola saat ini belum terdokumentasi dengan baik. Dokumentasi dibutuhkan sebagai dasar dari pengembangan dan integrasi perangkat lunak kedepannya. Selain

(22)

dokumentasi, control dan monitoring terhadap pekerjaan swakelola dirasa masih kurang, karena hanya mengandalkan inisiatif dari tim swakelola untuk melaporkan perkembangannya kepada pengguna (wawancara dengan Pranata Komputer, 13 Agustus 2013).

Untuk jumlah tenaga teknis, saat ini Asdep DDKI didukung 8 (delapan) pranata komputer sebagai tenaga ahli yang mengerjakan pengembangan perangkat lunak secara swakelola. Kemampuan pranata komputer yang ada tidak merata membutuhkan pembagian tugas sebaik mungkin (wawancara dengan Asisten Deputi Dukungan Data Kebijakan dan Informatika pada tanggal, 13 Agustus 2013). Sedangkan jumlah permintaan akan dukungan perangkat lunak terus bertambah tidak sebanding dengan jumlah pranata komputer yang melakukan pengembangan perangkat lunak. Dengan jumlah permintaan yang terus bertambah juga membuat pengerjaan menjadi tidak fokus. Karena kadang datang permintaan yang harus segera diselesaikan. Selain itu (wawancara Pranata Komputer pada tanggal 31 Agustus 2013). C. Pelelangan

Berdasarkan Peraturan Presiden Nomor 70 Tahun 2012, pengadaan barang/jasa adalah kegiatan untuk memperoleh Barang/Jasa oleh Kementerian/Lembaga/Satuan Kerja Perangkat Daerah/Institusi yang prosesnya dimulai dari perencanaan kebutuhan sampai diselesaikannya seluruh kegiatan untuk memperoleh Barang/Jasa. Jasa pengembangan perangkat lunak masuk pada pengadaan jasa konsultansi, jasa konsultansi adalah jasa layanan profesional yang membutuhkan keahlian tertentu diberbagai bidang keilmuan yang mengutamakan adanya olah pikir (brainware).

Keberhasilan pengembangan perangkat lunak dengan pelelangan sangat penting, karena kegagalan pengembangan perangkat lunak yag dilakukan melalui proses lelang akan menyebabkan implementasi perangkat lunak yang sudah direncanakan menjadi terhambat. Program yang gagal akan sangat sulit untuk masuk ke usulan rencana anggaran tahun berikutnya, solusinya program dikerjakan dengan swakelola. Namun program tersebut harus masuk antrian

(23)

untuk proram tersebut dapat diimplementasikan. Berdasarkan Petunjuk Operasional Kegiatan Asdep DDKI dan observasi penulis, diketahui tahun 2011 Kementerian Sekretariat Negara memiliki 4 (empat) kegiatan pengembangan perangkat lunak yang dilelang dengan hasil 3 (tiga) kegiatan berhasil dan 1 (satu) gagal (surat berita acara pemeriksaan nomor BA-1/BAPP/PPB/12/2011). Untuk tahun 2012 dari 2 (dua) kegiatan yang dilelang, 1 (satu) kegiatan mengalami keterlambatan (surat berita acara restitusi/denda nomor BARD-01/PPBJ-PUUN/12/2012). Ada beberapa hal yang membuat kegiatan melalui pelelangan mengalami keterlambatan maupun kegagalan, diantaranya kerangka acuan kerja yang dibuat masih bersifat umum sehingga penyedia jasa konsultansi perlu mendalami keinginan dan kebutuhan dari pengguna. Hal ini kadang tidak dilakukan oleh penyedia, sehingga penyedia kurang memahami keinginan dan kebutuhan pengguna. Ini berakibat pada pelaksanaan yang tidak sesuai jadwal, bahkan kadang fungsi dari aplikasi belum siap disaat waktu pengerjaan sudah habis. Selama ini pemilihan penyedia melalui pelelangan dinilai berdasarkan administrasi, teknis (pengalaman perusahaan, metodologi, dan kualifikasi tenaga ahli), dan harga. Belum pernah dilakukan penilaian kapasitas teknis pengembangan perangkat lunak yang mengacu pada standar internasional (wawancara dengan Kepala Subbidang Aplikasi Otomasi Perkantoran pada tanggal 13 dan 27 Agustus 2013 dan Kepala Subbagian Informasi dan Dokumentasi Kepegawaian, Biro Kepegawaian pada tanggal 28 Agustus 2013).

Dari masalah-masalah yang ada, penulis tertarik untuk meneliti bagaimana meningkatkan proses pemilihan penyedia jasa konsultansi dengan menilai kapasitas penyedia dalam mengembangkan perangkat lunak yang mengacu pada CMMI-DEV sebagai bahan penyusunan kerangka penilaian kapasitas terhadap penyedia untuk meningkatkan kualitas pemilihan penyedia jasa konsultasi perangkat lunak. Hal ini dilakukan untuk mengurangi kesalahan atau kelemahan dalam pengembangan perangkat lunak oleh penyedia, dan mendapatkan penyedia yang memiliki kualitas semakin baik, sehingga semakin ada peningkatan dalam menyelesaikan pekerjaan pengembangan perangkat lunak di Kementerian Sekretariat Negara. Diharapkan juga dari model-model pengembangan terbaik

(24)

yang ada akan menjadi bahan pembelajaran bagi pranata komputer dalam mengembangkan perangkat lunak secara swakelola.

Berkaitan dengan hal tersebut, penulis mencoba mengkaji proses pengembangan perangkat lunak yang mengacu pada kerangka kerja CMMI-DEV dalam rangka menyusun rancangan kerangka penilaian kapasitas penyedia perangkat lunak pada proses lelang sehingga dapat meningkatkan kualitas pemilihan penyedia jasa konsultansi pada Kementerian Sekretariat Negara. Maka ditarik pertanyaan penelitian “Bagaimana rancangan kerangka penilaian kapasitas penyedia

jasa konsultansi perangkat lunak yang mengacu pada CMMI-DEV di Kementerian Sekretariat Negara?”

1.3 Tujuan

Tujuan dari penelitian ini adalah untuk merancang kerangka penilaian kapasitas penyedia perangkat lunak yang akan digunakan memilih penyedia pada proses lelang dan menilai pekerjaan dari penyedia yang telah melaksanakan pekerjaannya di Kementerian Sekretariat Negara. Pembuatan rancangan penilaian kapasitas penyedia mengacu pada CMMI Dev, sebagai bahan pengkajian model kerangka penilaian kapasitas penyedia perangkat lunak.

1.4 Manfaat Penelitian

Manfaat yang diharapkan dari penelitian ini adalah:

a. Penelitian ini dapat menjadi referensi Kementerian Sekretariat Negara dalam melakukan penilaian kapasitas penyedia pada proses lelang dan penilaian pekerjaan penyedia pada proses penerimaan pekerjaan.

b. Penelitian ini dapat menjadi referensi atau pembanding akademik dalam mengukur kapasitas penyedia jasa konsultansi perangkat lunak.

1.5 Ruang Lingkup Penelitian

Penelitian ini akan mengkaji penilaian kapasitas para penyedia jasa konsultansi perangkat lunak yang sedang mengerjakan proyek pengembangan perangkat lunak

(25)

kerja CMMI-DEV V 1.3 representasi Continuous dengan proses area Requirements Management, Project Planning, Project Monitoring And Control dan Supplier Agreement Management.

(26)

BAB 2

KAJIAN PUSTAKA

2.1 Rekayasa Perangkat Lunak

Perangkat lunak merupakan program komputer, dokumentasi, dan konfigurasi yang diperlukan untuk membuat program tersebut dapat beroperasi dengan benar. Suatu perangat lunak biasanya terdiri dari beberapa bagian program yang terpisah, seperti file-file konfigurasi yang digunakan untuk membuat program, dokumentasi sistem yang menggambarkan struktur dari sistem, dan dokumentasi untuk pengguna yang menjelaskan bagaimana mengoperasikan perangkat lunak tersebut (Sommerville, 2007).

Perangkat lunak terbagi dua jenis, yang pertama generic products, produk yang sudah jadi dan dipakai banyak orang karena fungsinya yang bersifat umum. yang kedua customised products, produk khusus dimana fungsinya disesuaikan pada suatu kebutuhan yang lebih spesifik.

Rekayasa perangkat lunak merupakan disiplin rekayasa yang berkaitan dengan semua aspek produksi perangkat lunak dari tahap awal spesifikasi sistem sampai merawat sistem ketika sudah digunakan (Sommerville, 2007).

Dalam mengembangkan perangkat lunak terdapat empat proses dasar yang umum digunakan, yaitu:

1. Software specification, dimana pengguna dan penganalisa sistem mendefinisikan perangkat lunak yang akan dibangun.

2. Software development, dimana perangkat lunak dirancang dan diprogram. 3. Software validation, dimana perangkat lunak diperiksa untuk memastikan

sesuai dengan kebutuhan pengguna.

4. Software evolution, dimana perangkat lunak dimodifikasi sehingga dapat beradaptasi dengan perubahan dari pelanggan dan kebutuhan pasar.

(27)

Adapun kebanyakan model proses perangkat lunak yang didasarkan pada salah satu dari tiga model umum atau paradigma pengembangan perangkat lunak :

1. The waterfall approach, terdiri dari beberapa kegiatan yang diwakilkan dalam fase proses terpisah seperti spesifikasi kebutuhan, desain, implementasi, pengujian dan seterusnya. Setelah setiap tahap didefinisikan dan selesai, pengembangan pergi ke tahap berikut.

2. Iterative development, pendekatan ini terdiri dari kegiatan penspesifikasian, pengembangan dan validasi. Awal dari sistem dengan cepat dikembangkan dari spesifikasi yang sangat abstrak. Hal ini kemudian disempurnakan dengan masukan pengguna untuk menghasilkan sistem yang memenuhi kebutuhan pengguna. Sistem ini kemudian dapat digunakan. Atau, mungkin disempurnakan lagi menggunakan pendekatan yang lebih terstruktur untuk menghasilkan sistem yang lebih kuat dan terjaga.

3. Component-based software engineering (CBSE), teknik ini mengasumsikan bahwa bagian-bagian dari sistem sudah ada. Proses pengembangan sistem berfokus pada mengintegrasikan bagian-bagian pengembangan dari awal.

(Sommerville, 2007)

2.2 Manajemen Proyek TI

Dalam mengembangkan perangkat lunak dibutuhkan manajemen untuk menjaga pengembangan itu dapat berjalan sesuai dengan yang direncanakan sehinga pengembangan itu dapat mencapai target. Dalam buku Information Technology Project Management (ITPM) (Marchewka, 2010), merujuk pada penelitian dari

CHAOS (West Yarmouth, MA, 1995) menyebutkan faktor-faktor yang membuat proyek TI menjadi gagal adalah requirements yang tidak lengkap atau jelas, kurangnya keterlibatan pengguna, kurangnya sumber daya, harapan yang tidak realistis, perubahan kebutuhan dan spesifikasi, kurangnya perencanaan, produk tidak dibutuhkan lagi, kurangnya manajemen TI, dan teknologi yang kurang

(28)

literatur. Faktor-faktor ini tentu akan menjadi perhatian dalam meningkatkan kualitas mengelola pengembangan perangkat lunak.

Marchewka menjelaskan dalam buku ITPM, manajemen proyek merupakan penerapan pengetahuan, keterampilan, peralatan, dan teknik dalam kegiatan proyek untuk memenuhi kebutuhan stakeholder dan harapan dari proyek. Adapun manajemen proyek meliputi:

- Mengidentifikasi kebutuhan

- Menetapkan tujuan yang jelas dan dapat dicapai

- Menyeimbangkan permintaan yang bersaing pada kualitas, ruang lingkup, waktu, dan biaya

- Beradaptasi dengan spesifikasi, rencana, dan pendekatan terhadap masalah yang berbeda dan harapan dari berbagai pemangku kepentingan

(Marchewka, 2010)

2.3 CMMI-DEV

CMMI (Capability Maturity Model Integration) model merupakan model yang terdiri dari praktik-praktik terbaik yang digunakan untuk membantu organisasi dalam meningkatkan proses mereka. Model ini dikembangkan oleh tim produk dengan anggota dari industri, pemerintah, dan Software Engineering Institute

(SEI). CMMI for Development (CMMI-DEV), merupakan model terpadu komprehensif digunakan sebagai pedoman dalam mengembangkan produk dan jasa. CMMI-DEV digunakan untuk berbagai industri, diantaranya ruang angkasa, perbankan, perangkat keras komputer, perangkat lunak, pertahanan, manufaktur mobil, dan telekomunikasi. CMMI-DEV mengandung praktik yang mencakup manajemen proyek, manajemen proses, rekayasa sistem, rekayasa perangkat keras, rekayasa perangkat lunak, dan proses pendukung lainnya yang digunakan dalam pengembangan dan pemeliharaan.

CMMI-DEV terdiri dari praktek-praktek terbaik dimana kegiatan pembangunan diterapkan untuk produk dan jasa. Praktik-praktik yang mencakup siklus hidup

(29)

pekerjaan yang diperlukan untuk membangun dan memelihara produk secara keseluruhan.

CMMI-DEV berisi 22 area proses, yang terbagi 16 area proses inti, 1 area proses bersama, dan 5 pengembangan area proses tertentu. Semua CMMI-DEV model praktek fokus pada kegiatan organisasi pengembangan. Lima area proses berfokus pada praktek khusus untuk pembangunan: menangani kebutuhan pengembangan, solusi teknis, integrasi produk, verifikasi, dan validasi.

Kerangka kerja CMMI menghasilkan model CMMI yang terdiri dari tujuan dan praktek-praktek. Dan model CMMI mengandung 16 area proses inti yang meliputi proses konsep dasar sebagai proses perbaikan pada setiap area yang terkait (Software Engineering Institute, 2010).

2.3.1 Process Area

Sebuah area proses merupakan sekelompok praktek terkait di daerah yang sedang diimplementasikan secara kolektif, dengan memenuhi serangkaian tujuan dianggap penting untuk membuat perbaikan di daerah itu. Berikut ini merupakan 22 area proses yang diurutkan berdasarkan abjad:

- Causal Analysis and Resolution (CAR) - Configuration Management (CM)

- Decision Analysis and Resolution (DAR) - Integrated Project Management (IPM) - Measurement and Analysis (MA)

- Organizational Process Definition (OPD) - Organizational Process Focus (OPF)

- Organizational Performance Management (OPM) - Organizational Process Performance (OPP) - Organizational Training (OT)

- Product Integration (PI)

- Project Monitoring and Control (PMC) - Project Planning (PP)

(30)

- Quantitative Project Management (QPM) - Requirements Development (RD)

- Requirements Management (REQM) - Risk Management (RSKM)

- Supplier Agreement Management (SAM) - Technical Solution (TS)

- Validation (VAL) - Verification (VER)

Gambar 2.1 CMMI Model Components

Sumber: CMMI Product Team, Software Engineering Institute, Carnegie Mellon University (2010)

Pada Gambar 2.1 dapat terlihat CMMI terdiri dari model komponen-komponen yang dikelompokkan menjadi tiga kategori, yaitu required (yang diperlukan),

expected (yang diharapkan) dan informative (informatif). Komponen required

merupakan komponen CMMI yang penting dalam mencapai perbaikan proses pada area proses. Pemenuhan komponen ini harus tampak diterapkan dalam proses di organisasi. Komponen required dalam CMMI adalah specific goals dan

(31)

CMMI. Komponen expected memandu dalam melaksanakan perbaikan atau penilaian. Komponen expected CMMI adalah specific practices dan generic practices. Komponen informative merupakan komponen CMMI yang membantu pengguna model memahami komponen required dan komponen expected CMMI. Konponen informative dapat berupa kotak contoh, rincian penjelasan, atau informasi lain yang berguna. Subpractices, notes, references, goal titles, practice titles, sources, example work products, dan generic practice elaborations

merupakan komponen model informative.

Sebuah area proses terdiri dari Specific Goals dan Generic Goals. Dimana

Specific Goal terdiri dari beberapa Specific Practice yang sebagian memiliki

Example Work Product dan Subpractices. Generic Goal terdiri dari Generic Practice yang sebagian memiliki Subpractices dan Generic Practice Elaborators.

Specific Goal menggambarkan karakteristik unik yang ada untuk memenuhi area proses. Specific Goal adalah model komponen yang diperlukan dan digunakan dalam penilaian untuk membantu menentukan apakah suatu area proses terpenuhi.

Generic Goal menggambarkan karakteristik yang ada untuk melembagakan proses yang menerapkan area proses. Generic Goal adalah model komponen yang diperlukan dan digunakan dalam penilaian untuk menentukan apakah suatu area proses terpenuhi. Specific practice merupakan deskripsi dari suatu kegiatan yang dianggap penting dalam mencapai specific goal. Specific practice

menggambarkan kegiatan yang diharapkan dapat mencapai specific goal dari area proses. Subpractice merupakan penjelasan rinci yang memandu untuk menafsirkan dan menerapkan specific practice atau generic practice. Generic practice terkait dengan generic goal, menggambarkan kegiatan yang dianggap penting dalam mencapai generic goal dan berkontribusi terhadap pelembagaan proses yang terkait dengan area proses (Software Engineering Institute, 2010).

2.3.2 Representasi Continuous

CMMI-DEV menggunakan level (tingkatan) untuk menggambarkan jalur evolusi yang direkomendasikan untuk sebuah organisasi yang ingin meningkatkan proses yang digunakan untuk mengembangkan produk atau jasa. Level juga dapat menjadi hasil dari kegiatan pemeringkatan dalam penilaian. Penilaian dapat

(32)

berlaku untuk seluruh organisasi atau kelompok-kelompok kecil seperti kelompok proyek atau divisi.

CMMI mendukung dua jalur perbaikan dengan menentukan level. Satu jalur memungkinkan organisasi untuk secara bertahap meningkatkan proses sesuai dengan area proses individu (atau kelompok area proses) yang dipilih oleh organisasi. Jalur lain memungkinkan organisasi untuk meningkatkan serangkaian proses terkait dengan bertahap secara berturut-turut dalam paket area proses. Kedua jalur perbaikan terkait dengan dua jenis tingkat: capability levels dan

maturity levels. Level ini sesuai dengan dua pendekatan untuk perbaikan proses yang disebut "Representations". Kedua representasi disebut "continuous” dan

“staged". Menggunakan representasi continuous memungkinkan untuk mencapai "capability levels". Menggunakan representasi staged memungkinkan untuk mencapai "maturity levels".

Untuk mencapai tingkat tertentu, sebuah organisasi harus memenuhi semua tujuan area proses atau paket area proses yang ditargetkan untuk perbaikan, terlepas dari apakah itu adalah capability atau maturity level. Kedua representasi menyediakan cara untuk meningkatkan proses dalam mencapai tujuan bisnis, dan keduanya menyediakan konten penting yang sama dan menggunakan model komponen yang sama.

Representasi continuous menggunakan capability level untuk mencirikan keadaan proses organisasi ke area proses individu. Representasi continuous berfokus pada

capability area proses yang diukur dengan capability level. Capability level

berlaku untuk proses peningkatan prestasi organisasi dalam area proses individu. Tingkatan ini merupakan sarana untuk secara bertahap meningkatkan proses sesuai dengan area proses. Empat tingkat kemampuan diberi nomor 0 sampai 3. Representasi continuous fokus pada meningkatkan area proses dan meningkatkan kemampuan pada area proses yang diinginkan. Dalam konteks ini, apakah proses dilakukan atau tidak lengkap adalah penting. Oleh karena itu, nama "Incomplete" diberikan kepada representasi continuous pada titik awal.

(33)

Untuk mendukung mereka yang menggunakan representasi continuous, semua model CMMI mencerminkan capability levels dalam desain dan konten mereka. Empat capability levels, masing-masing lapisan dalam dasar bagi perbaikan proses yang sedang berlangsung, yang ditunjuk oleh angka 0 sampai 3:

0. Incomplete 1. Performed 2. Managed 3. Defined

Capability levels untuk area proses dicapai ketika semua generic goals terpenuhi sampai ke tingkat itu. Kenyataan bahwa tingkat kemampuan 2 dan 3 menggunakan istilah yang sama sebagai generic goals 2 dan 3 adalah disengaja karena masing-masing generic goals dan practices goals mencerminkan arti dari tujuan dan praktek capability levels. Penjelasan singkat dari setiap tingkat kemampuan berikut.

Capability Level 0: Incomplete

Sebuah proses yang tidak lengkap adalah sebuah proses yang tidak dilakukan atau sebagian dilakukan. Satu atau lebih dari specific goals dari area proses tidak terpenuhi dan tidak ada generic goals untuk tingkat ini karena tidak ada alasan untuk melembagakan proses parsial.

Capability Level 1: Performed

Proses capability level 1 ditandai sebagai proses yang dilakukan. Sebuah proses yang dilakukan adalah proses yang menyelesaikan pekerjaan yang diperlukan untuk menghasilkan work products, dan dapat terpenuhinya specific goals dari area proses.

Meskipun hasil capability level 1 di perbaikan penting, perbaikan-perbaikan dapat hilang dari waktu ke waktu jika mereka tidak dilembagakan. Penerapan pelembagaan membantu untuk memastikan bahwa perbaikan dapat dipertahankan.

(34)

Capability Level 2: Managed

Proses capability level 2 dicirikan sebagai proses yang dikelola. Sebuah proses yang dikelola adalah proses yang direncanakan dan dilaksanakan sesuai dengan kebijakan; mempekerjakan orang-orang terampil dengan sumber daya yang memadai untuk menghasilkan output terkendali, melibatkan stakeholder yang relevan; dipantau, dikendalikan, dan terpantau, dan dievaluasi untuk kepatuhan terhadap deskripsi prosesnya.

Proses disiplin tercermin pada capability level 2 akan membantu untuk memastikan bahwa praktek-praktek yang ada dipertahankan selama masa-masa sulit.

Capability Level 3: Defined

Proses capability level 3 ditandai sebagai proses yang terdefinisi. Proses yang terdefinisi adalah proses yang dikelola yang disesuaikan dari proses standar dari organisasi proses standar sesuai dengan pedoman organisasi, memiliki gambaran proses yang dapat dipertahankan, dan memberikan kontribusi terkait pengalaman proses organisasi .

Perbedaan penting antara tingkat kemampuan 2 dan 3 adalah ruang lingkup standar, deskripsi proses, dan prosedur. Pada capability level 2, standar, deskripsi proses, dan prosedur bisa sangat berbeda dalam setiap contoh spesifik dari proses. Pada capability level 3, standar, deskripsi proses, dan prosedur untuk proyek dirancang dari set organisasi proses standar sesuai dengan suatu proyek tertentu atau unit organisasi dan oleh karena itu lebih konsisten, kecuali untuk perbedaan yang diizinkan oleh pedoman pemadu.

Perbedaan penting yang lain adalah bahwa pada capability level 3 proses biasanya digambarkan lebih ketat daripada di capability level 2. Proses yang didefinisikan dengan jelas menyatakan tujuan, masukan, kriteria masuk, kegiatan, peran, langkah-langkah, langkah-langkah verifikasi, output, dan kriteria keluar. Pada

(35)

tentang keterkaitan kegiatan proses dan langkah-langkah rinci proses serta produk kerjanya (Software Engineering Institute, 2010).

2.3.3 Hubungan Antara Area Proses

Dalam CMMI-DEV dijelaskan keterhubungan antara area proses untuk membantu dalam pengorganisasian dari perbaikan proses dan bagaimana area proses saling terhubung dan bergantung pada pelaksanaan area proses yang lain. Berikut ini kelompok area proses yang saling terhubung:

- Keterhubungan area proses pada Basic Process Management Process Areas

menyediakan pengorganisasian dengan kemampuan untuk mendokumentasikan dan berbagi praktik terbaik, organisasi aset proses, dan pembelajaran seluruh organisasi. Adapun area proses yang terhubung adalah

Organizational Process Focus (OPF), Organizational Process Definition

(OPD), dan Organizational Training (OT).

- Keterhubungan area proses pada Advanced Process Management Process Areas menyediakan pengorganisasian dengan kemampuan yang lebih baik untuk mencapai tujuan kuantitatif untuk kualitas dan kinerja proses. Adapun area proses yang terhubung adalah Organizational Performance Management (OPM) dan Organizational Process Performance (OPP).

- Keterhubungan area proses pada Basic Project Management Process Areas

untuk mengatasi kegiatan yang berkaitan dengan membangun dan mempertahankan rencana proyek, membangun dan mempertahankan komitmen, pemantauan kemajuan terhadap rencana, mengambil perjanjian tindakan korektif, dan mengelola pemasok. Adapun area proses yang terhubung adalah Requirements Management (REQM), Project Planning

(PP), Project Monitoring and Control (PMC), dan Supplier Agreement Management (SAM).

- Keterhubungan area proses pada Advanced Project Management Process Areas untuk menangani kegiatan seperti membangun proses yang didefinisikan dan disesuaikan dari himpunan standar proses organisasi, membangun lingkungan kerja proyek dari standar lingkungan kerja organisasi, koordinasi dan bekerja sama dengan stakeholder terkait,

(36)

membentuk dan mempertahankan tim untuk melakukan proyek, secara kuantitatif mengelola proyek, dan mengelola risiko. Adapun area proses yang terhubung adalah Quantitative Project Management (QPM), Integrated Project Management (IPM), dan Risk Management (RSKM).

- Keterhubungan area proses pada Engineering meliputi pengembangan dan pemeliharaan kegiatan yang dibagi di seluruh disiplin ilmu teknik. Area proses engineering ditulis menggunakan terminologi engineering umum sehingga setiap disiplin teknis yang terlibat dalam proses pengembangan produk (misalnya, rekayasa perangkat lunak, teknik mesin) dapat menggunakannya untuk perbaikan proses. Adapun area proses yang terhubung adalah Product Integration (PI), Requirements Development (RD),

Technical Solution (TS), Validation (VAL), dan Verification (VER).

- Keterhubungan area proses pada Basic Support Process Areas untuk menangani fungsi dukungan fundamental yang digunakan oleh semua area proses. Meskipun semua bidang proses support mengandalkan pada area proses lain untuk input, Basic Support Process Areas memberikan fungsi pendukung yang juga membantu melaksanakan beberapa praktek generik. Adapun area proses yang terhubung adalah Measurement and Analysis (MA), Process and Product Quality Assurance (PPQA), dan Configuration Management (CM).

- Keterhubungan area proses pada Advanced Support Process Areas

menyediakan proyek dan organisasi dengan kemampuan dukungan ditingkatkan. Masing-masing daerah proses ini bergantung pada input tertentu atau praktek dari area proses lainnya. Adapun area proses yang terhubung adalah Causal Analysis and Resolution (CAR) dan Decision Analysis and Resolution (DAR) .

Berkaitan dengan permasalahan yang ada di Kementerian Sekretariat Negara untuk pengembangan perangkat lunak yang melibatkan penyedia. Basic Project Management Process Areas sangat dekat dengan permasalahan project management yang ada. Gambar 2.2 memberikan gambaran mengenai interaksi antara proses area Basic Project Management dengan proses area yang lain.

(37)

pengembangan rencana proyek, pelibatan pemangku kepentingan yang relevan, memperoleh komitmen terhadap rencana, dan menjaga rencana.

Gambar 2.2 Basic Project Management Process Areas

Sumber: CMMI Product Team, Software Engineering Institute, Carnegie Mellon University (2010)

Perencanaan dimulai dengan persyaratan yang menentukan produk dan proyek (“What to Build” pada Gambar 2.2). Rencana proyek meliputi berbagai kegiatan

pengelolaan dan pengembangan yang dilakukan pada proyek. Proyek mengulas rencana lain yang mempengaruhi proyek dari berbagai pemangku kepentingan yang relevan dan komitmen untuk kontribusi mereka terhadap proyek.

Area proses Project Monitoring and Control berisi praktek pemantauan dan pengendalian kegiatan dan mengambil tindakan korektif. Rencana proyek menentukan frekuensi tinjauan kemajuan dan langkah-langkah yang digunakan untuk memantau kemajuan. Kemajuan ditentukan dengan membandingkan proyek status rencana. Ketika status sebenarnya menyimpang secara signifikan dari nilai-nilai yang diharapkan, tindakan korektif yang dapat diambil adalah perencanaan ulang, yang mengharuskan menggunakan praktek Project Planning.

(38)

Area proses Requirements Management menjaga kebutuhan. Ini menggambarkan kegiatan untuk memperoleh dan mengendalikan perubahan kebutuhan dan memastikan bahwa rencana lain yang relevan dan data tetap tersimpan. Disini tersedia penelusuran terhadap kebutuhan pelanggan terhadap kebutuhan dari produk.

Requirements Management memastikan bahwa perubahan kebutuhan dapat terlihat pada rencana proyek, kegiatan, dan produk. Siklus perubahan dapat mempengaruhi area proses Engineering. Requirements Management merupakan urutan dinamis dan sering rekursif peristiwa. Area proses Requirements Management adalah fundamental bagi proses rekayasa terkendali dan disiplin. Area proses Supplier Agreement Management menunjukan kebutuhan proyek untuk memperoleh bagian-bagian dari pekerjaan yang diproduksi oleh pemasok. Sumber produk dapat digunakan untuk memenuhi kebutuhan proyek proaktif yang diidentifikasi. Pemasok yang dipilih, dan perjanjian pemasok dibuat untuk mengelola pemasok.

Kemajuan dan kinerja pemasok dilacak sebagaimana ditentukan dalam perjanjian pemasok, dan perjanjian pemasok dapat direvisi dan disesuaikan. Ulasan penerimaan dan tes dilakukan pada pemasok komponen produk. Untuk keterangan mengenai goals dan practices dari kelompok keterhubungan area proses Basic Project Management Process Areas dapat dilihat pada lampiran 3.

2.3.4 Standard CMMI Appraisal Method for Process Improvement

Standard CMMI Appraisal Method for Process Improvement (SCAMPI) merupakan kelanjutan penilaian CMM-Based Assessment for Internal Process Improvement (CBA-IPI), metode yang ditetapkan untuk CMM. Dengan bantuan sebuah penilaian, organisasi dapat mengetahui tingkat CMMI dan mendapatkan rekomendasi tentang bagaimana untuk lebih meningkatkan proses pembangunan, serta mendapat pernyataan tentang kematangan prosesnya. Penilaian CMMI akan lebih menekankan pada perbaikan proses.

(39)

SCAMPI merupakan metode penilaian yang didefinisikan oleh SEI. Untuk membedakan kelengkapan dari metode, SCAMPI dibagi menjadi SCAMPI A, B dan C. SEI membedakan dua macam penilaian berdasarkan tujuan mereka:

- Untuk perbaikan proses internal dengan tujuan mengevaluasi diri dan mengidentifikasi peluang dalam melakukan peningkatan.

- Untuk mengevaluasi proses kematangan (calon) pemasok sebelum kontrak, sebagai dasar untuk pengambilan keputusan tentang pemasok, atau untuk memantau dukungan dari pemasok.

Ini merupakan alasan awal yang utama untuk pengembangan CMM dan CMMI-Departemen Pertahanan Amerika Serikat ingin dasar yang lebih baik untuk keputusan dalam pemberian kontrak kepada pemasok perangkat lunak.

Terlepas dari metode yang telah didefinisikan oleh SEI, setiap organisasi dapat menentukan metode penilaian sendiri yang mungkin lebih baik disesuaikan dengan spesifik organisasi, khususnya untuk pengecekan yang lebih rendah. Dalam rangka mencapai tingkat minimum tertentu dengan keseragaman dan kualitas penilaian, SEI telah mendefinisikan Appraisal Requirements for CMMI (ARC), yang mendefinisikan tiga kelas metode penilaian dengan berbagai paket persyaratan minimum.

Appraisal Requirements for CMMI mendefinisikan tiga kelas metode penilaian yang berbeda dalam ketelitian dan upaya yang dilakukan.

- Kelas A

Metode penilaian kelas A yang dioptimalkan untuk hasil yang dapat diandalkan dan benar, tetapi membutuhkan usaha yang paling besar. Metode yang paling penting dalam kelas ini adalah SCAMPI A (kelas A metode yang didefinisikan oleh SEI). Hanya kelas A penilaian yang diperbolehkan menggunakan rating untuk melaporkan tingkat kematangan terntentu dari profil kemampuan, dan SEI hanya akan menerima penilaian SCAMPI A.

(40)

- Kelas B

Metode penilaian kelas B memiliki persyaratan yang lebih rendah dari kelas A pada keandalan dan kebenaran hasil. Ada pengecekan yang lebih rendah dalam menghasilkan laporan tertentu. Akibatnya, hanya sedikit usaha yang diperlukan dalam melakukan penilaian.

- Kelas C

Metode kelas C digunakan untuk penilaian yang lebih sering dan untuk pengecekan cepat. Persyaratan dan usaha yang dilakukan lebih rendah lagi dari kelas B. Meskipun hasil penilaian kelas C tidak dapat diandalkan seperti penilaian kelas A atau B, untuk berbagai tujuan keandalannya masih mencukupi. Semakin rendah upaya yang dilakukan, penilaian dapat dilakukan lebih sering dalam rangka menngetahui kemajuan.

2.4 Kerangka Standar Kompetensi Berbasis Kinerja dari GAPPS

Global Alliance for Project Performance Standards (GAPPS) merupakan organisasi relawan yang bekerja untuk menciptakan kerangka kerja dan standar

project management dengan menyediakan forum bagi para stakeholder dari sistem , latar belakang , dan konteks operasi yang berbeda untuk bekerja sama dalam memenuhi kebutuhan komunitas global project management.

Kerangka GAPPS digunakan oleh kalangan bisnis, lembaga akademis, penyedia pelatihan , asosiasi profesi, dan standar pemerintah, serta kualifikasi badan global. Kerangka dapat digunakan sebagaimana adanya atau disesuaikan dengan kebutuhan organisasi. Adapun kerangka yang dihasilkan oleh GAPPS adalah kerangka untuk Performance Based Competency Standards for Global Level 1 and 2 Project Managers.

Kerangka ini digunakan untuk menilai ambang kompetensi dan kemampuan dalam melakukan proyek pada standar dianggap dapat diterima di organisasi . Hal ini berlaku Global Level 1 dan Global Level 2 manajer proyek di semua bidang usaha, dan tidak terbatas pada: arsitektur, bioteknologi, konstruksi , desain, pendidikan, teknik, jasa keuangan, pemerintah, kontraktor pemerintah, sistem

(41)

Tabel di bawah ini merupakan ringkasan dari unit kompetensi yang dinilai: Tabel 2.1 Unit Kompetensi

No Unit Judul Unit Deksrisi Unit

PM01 Manage Stakeholder Relationships

Satuan ini mendefinisikan Elemen yang dibutuhkan untuk mengelola hubungan stakeholder selama proyek. Ini mencakup kriteria kinerja yang dibutuhkan untuk menunjukkan kompetensi dalam memastikan tepat waktu dan ketepatan dari keterlibatan individu, organisasi, dan kelompok seluruh proyek .

PM02 Manage

Development of the Plan for the Project

Unit Proyek ini mendefinisikan elemen yang dibutuhkan untuk mengelola pengembangan rencana untuk proyek tersebut . Ini mencakup kriteria kinerja yang dibutuhkan untuk mendemonstrasikan kompetensi dalam menentukan bagaimana untuk mewujudkan proyek secara efisien dan efektif.

PM03 Manage Project Progress

Unit ini mendefinisikan elemen yang dibutuhkan untuk mengelola kemajuan proyek. Ini mencakup kriteria kinerja yang dibutuhkan untuk mendemonstrasikan kompetensi dalam memastikan bahwa proyek bergerak konstruktif menuju pengiriman produk dari proyek dan mendukung hasil proyek yang telah disepakati.

PM04 Manage Product Acceptance

Satuan ini mendefinisikan elemen yang diperlukan untuk memastikan bahwa produk, layanan, atau hasil dari proyek tersebut akan diterima oleh pemangku kepentingan yang relevan . Ini mencakup kriteria kinerja yang dibutuhkan untuk mendemonstrasikan kompetensi dalam memastikan bahwa produk dari proyek didefinisikan , disetujui , dikomunikasikan , dan diterima.

(42)

No Unit Judul Unit Deksrisi Unit

PM05 Manage Project Transitions

Satuan ini mendefinisikan elemen yang dibutuhkan untuk mengelola transisi proyek. Ini mencakup kriteria kinerja yang dibutuhkan untuk mendemonstrasikan kompetensi dalam menjalankan proyek sedang berlangsung, dalam bergerak dari satu fase proyek ke fase berikutnya, dan penyelesaian proyek hingga pada suatu kesimpulan.

PM06 Evaluate and Improve Project Performance

Unit Proyek ini mendefinisikan elemen yang dibutuhkan untuk mengevaluasi dan meningkatkan kinerja proyek. Hal ini mencakup kriteria kinerja yang dibutuhkan untuk mendemonstrasikan kompetensi dalam memastikan bahwa peluang untuk perbaikan diterapkan pada proyek ini dan dibuat tersedia untuk proyek-proyek masa depan.

Sumber: Global Alliance for Project Performance Standards (2007)

2.5 Projects in a Controlled Environment

Projects in a Controlled Environment (PRINCE2) merupakan metode manajemen proyek terstruktur berdasarkan pengalaman yang diambil dari ribuan proyek dan kontribusi yang tak terhitung jumlahnya dari sponsor proyek, manajer proyek, tim proyek, akademisi, pelatih dan konsultan. PRINCE2 dikembangkan oleh Office of Government Commerce (OGC). PRINCE2 adalah metode yang tidak- eksklusif dan telah banyak digunbakan dibanyak negara untuk mengelola proyek yang dapat diterapkan pada beragam proyek terlepas dari skala proyek, jenis, organisasi, geografi atau budaya.

Metode PRINCE2 dapat diadopsi sebagai standar subtansi suatu organisasi untuk meningkatkan kemampuan dan kematangan di beberapa bidang kegiatan usaha - perubahan bisnis, konstruksi, IT, merger dan akuisisi, penelitian , pengembangan produk dan sebagainya.

(43)

PRINCE2 merupakan sebuah framework yang terintegrasi dari proses dan tema yang membahas perencanaan, delegasi, pemantauan dan pengendalian semua enam aspek kinerja proyek (biaya, skala waktu, kualitas, ruang lingkup, resiko, dan manfaat). Adapun tiga hal yang tidak masuk dalam PRINCE2 adalah:

- Specialist aspects, kekuatan PRINCE2 adalah dalam penerapan secara luas - itu sepenuhnya bersifat umum. Akibatnya, aktivitas industri tertentu atau tipe tertentu dikecualikan.

- Detailed techniques, hanya teknik yang memiliki pendekatan spesifik PRINCE2 yang dijelaskan, misalnya perencanaan berbasis produk dan review

kualitas teknik.

- Leadership capability, Kepemimpinan, keterampilan motivasi dan keterampilan interpersonal lainnya sangat penting dalam manajemen proyek tetapi tidak disusun dalam PRINCE2.

PRINCE2 menentukan tema yang menjelaskan aspek-aspek manajemen proyek yang harus diatasi. Perhatian menyeluruh untuk tema-tema ini akan memenuhi peran secara profesional bagi manajer proyek. Berikut tema-tema yang terdapat pada PRINCE2:

- Business Case, proyek dimulai dengan sebuah ide yang dianggap memiliki potensi nilai organisasi yang bersangkutan. Tema ini membahas bagaimana ide dikembangkan menjadi proposisi investasi yang layak bagi organisasi dan bagaimana proyek manajemen mempertahankan fokus pada tujuan organisasi di seluruh proyek.

- Organization, organisasi yang mensponsori proyek ini perlu mengalokasikan pekerjaan untuk manajer yang akan bertanggung jawab dan mengarahkan sampai selesai. Proyek adalah lintas fungsional sehingga struktur fungsi garis normal tidak cocok. Tema ini menggambarkan peran dan tanggung jawab yang dibutuhkan untuk mengelola secara efektif proyek dalam tim manajemen proyek.

- Quality, ide awal hanya akan dipahami sebagai garis besar. Tema ini menjelaskan bagaimana garis besar dikembangkan sehingga semua peserta memahami kualitas atribut produk yang akan dihasilkan, kemudian bagaimana

(44)

manajemen proyek akan memastikan bahwa kebutuhan yang ada dapat terpenuhi.

- Plans, proyek PRINCE2 berjalan atas dasar rencana yang telah disetujui. Ini tema melengkapi tema kualitas dengan menjelaskan langkah-langkah yang diperlukan untuk mengembangkan rencana dan teknik PRINCE2 yang harus diterapkan. Di PRINCE2, rencana yang disesuaikan dengan kebutuhan personel di berbagai tingkat organisasi. Mereka adalah fokus untuk komunikasi dan kontrol seluruh proyek.

- Risk, proyek yang dibutuhkan biasanya lebih berisiko daripada kegiatan operasional yang stabil. Tema ini untuk mengetahui bagaimana manajemen proyek mengelola ketidakpastian dalam rencana dan dalam lingkungan proyek yang lebih luas.

- Change, tema ini menggambarkan bagaimana manajemen proyek menilai dan bertindak atas isu-isu yang memiliki dampak potensial pada salah satu aspek dasar dari proyek (yang sudah terencana dan produk yang selesai). Masalah mungkin masalah umum yang tak terduga, permintaan untuk perubahan atau misalnya kegagalan kualitas.

- Progress, tema ini membahas keberlangsungan rencana. Tema menjelaskan proses pengambilan keputusan untuk menyetujui rencana, pemantauan aktual kinerja dan proses eskalasi jika peristiwa tidak berjalan sesuai rencana. Pada akhirnya, tema progress menentukan apakah dan bagaimana proyek harus melanjutkan.

(Office of Government Commerce, 2009)

2.6 PMBOK Guide

A Guide to the Project Management Body of Knowledge (PMBOK Guide) merupakan pedoman untuk mengelola proyek-proyek dan mendefinisikan manajemen terkait konsep proyek. Hal ini untuk menggambarkan siklus hidup manajemen proyek dan proses terkait, serta siklus hidup dari proyek. PMBOK

Guide dikembangkan oleh Project Management Institute, Inc. (PMI). PMBOK