Mata Kuliah Dosen Pembimbing

RPL Rice Novita, S.Kom, M.Kom

Bedah Buku
Organisasi Model Kematangan dari CMM
Menagement Proyek untuk Perangkat Lunak
Asumsi Menagement Proyek

Di Susun Oleh : Kelompok 3 SIF4E

Ari Pujo Prayogi
Fitri Suryani
Iwan Kurniansyah
Luthfi Anroza
M Iqbal Indrawan

Universitas Islam Negeri Sultan Syarif Kasim Riau

Fakultas Sains & Teknologi
Jurusan Sistem Informasi
Pekanbaru
2019
 1. Organisasi Model Kematangan dari CMM
1.1 Pendahuluan
CMM dikembangkan oleh software Engineering Institute (SEI) dan telah dijelaskan secara
mendetail pada publikasi yang berbeda. CMM adalah kerangka konseptual yang menyajikan
menajemen proses dari pengembangan perangkat lunak. Menurut Paulk, dkk., pada tahun
1995 mengatakan CMM berisi lima tingkat kematangan, yaitu :
1. Tingkat 1, initial
Proses perangkat lunak ditandai sebagai ad hoc, chaotic, dan heroic. Proses – proses akan
digambarkan atau diikuti, dan kesuksesan proyek tergantung pada usaha perorangan. Kriteria
dari initial level adalah :
1. Tidak ada manajemen proyek.
2. Tidak ada quality assurance.
3. Tidak ada mekanisme manajemen perubahan (change management).
4. Tidak ada dokumentasi.
5. Terdapat ketergantung pada kemampuan individual.

2. Tingkat 2, repeatable
Tingakt ini meyediakan sebuah pengenalan formal, yaitu proses yang didokumentasikan.
Proses – proses menajemen dasar dibetuk untuk mengontrol biaya, penjadwalan, dan
fungsionalitas. Ciri-ciri dari repeatable level adalah:
1. Kualitas perangkat lunak mulai bergantung pada proses bukan pada individu.
2. Ada manajemen proyek sederhana.
3. Ada quality assurance sederhana.
4. Ada dokumen sederhana.
5. Ada software configuration management sederhana.
6. Tidak ada knowledge management.
7. Tidak ada komitmen untuk mengikuti SDLC dalam kondisi apapun.
8. Tidak ada stastikal control untuk estimasi proyek dan rentan perubahan struktur
organisasi.
 3. Tingkat 3, defined
Tingkat ini menyediakan dasar untuk peningkatan proses yang berkelanjutan dengan
penetapan fungsi menajemen proes untuk mengontrol parameter proses. Proses perangkat
lunak untuk kegiatan menajemen dan rekayasa didokumentasikan, distandarkan, dan
diintegrasikan kedalam standar proses perangkat lunak untuk organisasi. Ciri-ciri dari Defined
level adalah :
1. SDLC sudah ditentukan.
2. Ada komitmen untuk mengikuti SDLC dalam keadaan apapun.
3. Kualitas proses dan produk masih bersifat kualitatif atau hanya perkiraan saja.
4. Tidak menerapkan Activity Based Costing.
5. Tidak ada mekanisme umpan balik yang baku.

4. Tingkat 4, menaged
Ukuran yang terperinci dari kualitas produk dan proses perangkat lunak akan dikumpulkan.
Keduanya harus dipahami dan dikontrol. Ciri-cirinya Managed Level adalah :
1. Sudah ada Activity Based Costing yang digunakan untuk estimasi proyek
berikutnya.
2. Proses penilaian kualitas perangkat lunak dan proyek masih bersifat kuantitatif.
3. Terjadi pemborosan biaya untuk pengumpulan data karena proses pengumpulan
data masih dilakukan secara manual.
4. Sudah memiliki mekanisme umpan balik.
5. Tidak ada mekanisme pencegahan defect.

5. Tingkat 5, optimized
Peningkatan proses yang berlanjut memungkinkan umpan balik kuantitatif dari proses.
1. Pengumpulan data secara automatis.
2. Ada mekanisme pencegahan defect.
3. Ada mekanisme umpan balik yang baik.
4. Ada peningkatan kualitas dari SDM.
5. Ada peningkatan kualitas proses.
Kelima tingkatan kematangan ini menggambarkan sebuah skala asli. Masing – masing tingkat
kematangan mengindikasikan tingkat kemampuan proses.

Tingkat 2 sampai 5 dipecah menjadi 18 area proses utama (Key Process Areas [KPA]). Masing
– masing KPA diorganisasikan menjadi lima bagian yang disebiut fitur umumm, yaitu :
1. Komitmen untuk melakukan
Fitur ini menggambarkan aksi – aksi yang harus mengambil tempat di dalam organisasi
untuk meyakinkan bahwa proses dibentuk dan berfungsi.
2. Kemampuan untuk melakukan
Fitur ini menggambarkan prasyarat yang harus ada di dalam proyek atau organisasi untuk
menerapkan kemampuan proses perangkat lunak.
3. Kegiatan yang dilakukan
Fotur ini menggambarkan peran – peran dan prosedur – prosedur yang perlu untuk
menerapkan proses area utama.
4. Mengukur dan menganalisis
Fitur ini menggambarkan kebutuhan untuk mengukur proses dan menganalisis
pengukuran.
5. Pembuktian implementasi
Fitur ini menggambarkan langkah – langkah untuk meyakinkan bahwa kegiatan –
kegiatan dilakukan di dalam pemenuhan dengan prose yang telah dibentuk.
  Repeatable  Defined

1. Menajemen Kebutuhan 1. Definisi proses organisasi

2. Jaminan kualitas perangkat lunak 2. Fokus proses organisasi
3. Menajemen konfigurasi perangkat 3. Program pelatihan
lunak 4. Rekayasa produk perangkat lunak
4. Kesalahan dan penjajakan proyek 5. Peer-review
perangkat lunak 6. Koordinasi antar-grup
5. Perencanaan proyek perangkat 7. Menajemen perangkat lunak
lunak terintegrasi
6. Menajemen sub-kontrak perangkat
lunak

 Menaged
 Optimized

1. Menajemen proses kuantitatif

1. Menajemen perubahan proses 2. Menajemen kualitas perangkat
2. Menajemen perubahan teknologi lunak
3. Pencegahan kerusakan

1.2 Kelima Tingkatan CMM

1. Tingkat 1, Initial
Hampir setiap organisasi memulai dari level yang seringkali disebut anarki atau kekacauan
(chaos) ini. Pengembangan system tidak menggunakan proses yang terstruktur dan tiap
developer menggunakan alat dan metodenya masing-masing. Pada tahap ini umumnya
proses tidak dapat diprediksi, tidak berulang, sering mengalami krisis, over-budget, dan gagal
mencapai target waktu. Ciri-ciri dari fungsi initial adalah tidak ada manajemen proyek, tidak
adanya quality assurance, tidak adanya mekanisme manajemen perubahan (change
management), tidak ada dokumentasi, adanya seorang ahli yang tau segalanya tentang
perangkat lunak yang dikembangkan, dan sangat bergantung pada kemampuan individual.
Salah satu karakteristik yang menarik dari organisasi Tingkat 1 adalah bahwa menajemennya
sangat kuat, tetapi sangat tidak efisien dalam kaitanya dengan tidak adanya komunikasi.
Sebagai hasilnya, kualitas dan jadwal penyerahan produk tidak dapat diramalkan. Dalam
posisi ini, menajemen dan keputusan menajemen menjadi sangat tidak disukai di antara
praktisi (Hansen,1997). Pada tingkat 1, perbaikan menajemen untuk meningkatkan suatu
proses ditujukan untuk reorganisasi. Mereka percaya bahwa prosesnya sudah benar, tetapi
cara yang ditempuh oleh menajemen adalah proses yang salah.

2. Tingkat 2, Repeatable
Proses dan praktek manajemen proyek pengembangan system telah dirancang untuk
melacak biaya proyek, jadwal, dan kegunaan dari sistem. Pada tahap ini, fokus ditekankan
pada manajemen proyeknya, bukan pada pengembangan sistem (pengembangan sistem
bervariasi untuk tiap proyek). Kesuksesan dan kegagalan masih bergantung pada kemampuan
dan pengalaman dari tim yang mengerjakan proyek. Walaupun begitu, telah terdapat usaha
untuk mengulang keberhasilan proyek sebelumnya, dan manajemen proyek yang efektif pun
akhirnya menjadi pondasi bagi standardisasi proses level berikutnya.
Ciri-ciri dari fungsi repeatable adalah kualitas perangkat lunak mulai bergantung pada proses
bukan pada orang, ada manajemen proyek sederhana, ada quality assurancesederhana, ada
dokumen sederhana, ada software configuration managementsederhana, tidak
adanya knowledge management, tidak adanya komitmen untuk selalu mengikuti SDLC dalam
kondisi apapun, tidak adanya stastikal control untuk estimasi proyek dan rentan perubahan
struktur organisasi.

3. Tingkat 3, Defined
Proses pengembangan sistem standar (umumnya disebut metodologi) telah dimiliki atau
dikembangkan dan telah digunakan secara terintegrasi melalui unit sistem atau pelayanan
informasi organisasi. Sebagai hasilnya, hasil dari setiap proyek menjadi lebih konsisten,
dokumentasi serta penyampaian yang berkualitas tinggi, dan proses menjadi lebih stabil,
mampu diprediksi (predictable), dan berulang (repeatable).
Dengan demikian, tingkatan yang dapat di ulang menggabarkan apa yang harus dikerjakan
dan siapa yang melakukanya, tingkatan ini akan menggambarkan ketetapan ketika
melakukannya dan bagaimana cara melakukannya. Tingkat 3 menetapkan suatu pemahaman
yang umum dari proses antarorganisasi dan juga menyediakan fleksibilitas dalam kaitannya
dengan bagaimana mengubah proses dan menghubungkannya pada kegiatan yang
berkelanjutan. Tugas tersebut menyediakan fondasi untuk kualitas dari keputusan
menajemen.
Pada kematangan Tingkat 3, organisasi tidak hanya menggambarkan prosesnya dalam
kaitannya dengan metode dan standar perangkat lunak, tingkat ini juga membuat serangkaian
peningkatan metodologi dan organisiasi.

4. Tingkat 4, Managed
Telah memiliki tujuan yang terukur untuk kualitas dan produktivitas. Ukuran mendetail
mengenai proses pengembangan proses standar dan kualitas produk telah dikumpulkan
secara rutin dan disimpan dalam database. Pada tahap ini manajemen lebih proaktif dalam
melihat masalah pengembangan sistem. Jadi walaupun proyek menemui masalah atau isu
yang tidak diperkirakan, proses masih akan dapat disesuaikan berdasarkan efek dari kondisi
yang mampu diprediksi dan terukur.
Ciri-cirinya adalah sebagai berikut, sudah ada Activity Based Costing dan digunakan untuk
estimasi proyek berikutnya, proses penilaian kualitas perangkat lunak dan proyek bersifat
kuantitatif, terjadi pemborosan biaya untuk pengumpulan data karena proses pengumpulan
data masih dilakukan secara manual, cenderung belum jelas disebabkan karena manusia
ketika diperhatikan perilakuknya cenderung berubah, tidak ada mekanisme
pencegahan defect dan adanya mekanisme umpan balik.

5. Tingkat 5, Optimized
Proses pengembangan sistem terstandarisasi secara kontinu dimonitor dan ditingkatkan
berdasarkan ukuran dan analisa data di level 4. Setiap pembelajaran yang ada disebarluaskan
pada seluruh bagian organisasi dengan penekanan pada penurunan ketidakefisienandalam
proses pengembangan sistem ketika menjaga kestabilan kualitas. Sebagai kesimpulan,
organisasi telah menjadikan peningkatan proses pengembangan sistem yang kontinu bagian
dari dirinya.
Cirri-cirinya adalah sebagai berikut, Pengumpulan data secara automatis, adanya mekanisme
pencegahan defect, adanya mekanisme umpan balik yang sangat baik, dan adanya
peningkatan kualitas dari SDM dan juga peningkatan kualitas proses.

Tabel perbandingan umum tiap tingkatan CMM

Kesalahan
Kesalahan
Durasi Usaha pengiriman
Tingkat terdeteksi Total biaya
(Bulan (Bulan kepada klien
CMM selama pengembangan
kelender) orang) dan
pengembangan
pemasangan

Tingkat 1 29,8 593,5 1384 61 $5.440.000

Tingkat 2 18,5 143 328 12 $1.311.000

Tingkat 3 15,2 79,5 182 7 $728.000

Tingkat 4 12,5 42,8 97 5 $392.000

Tingkat 5 9 16 37 1 $146.000

Perbandingan kinerja tiap tingkatan CMM

1.3 Manfaat dari Pendekatan CMM

CMM mempersatukan organisasi pengembangan perangkat lunak dan menyediakan
beberapa tool kepimpinan dengan menajemen yang dapat meningkatkan proyek perangkat
lunak yang mereka kelola, yaitu :
 1. Suatu pemahaman yang jelas dari pengembang perangkat lunak mengenai apa yang
diharapkan dari mereka.
2. Kejelasan prosedur pekerjaan dan kecukupan sumber daya, keterampilan, dan
pengetahuan.
3. Proses – proses antarfungsi yang memengaruhi kualitas pelanggan yang diterapkan.
4. Peluang untuk meningkatkan organisasi, proses, dan kualitas produk.

1.4 Fitur Umum dari Key Process Area

Fitur umum CMM bukanlah konsep yang baru. Pada tahun 1931, Walter Shewhart mengenali
keluaran proses pabrikasi, yaitu subjek kepada beberapa bentuk variasi yang menyebabkan
permasalahan kualitas yang berlebihan.
Variasi terjadi sebagai hasil ketidaktepatan pada bagaian pemesinan atau material atau
karena keahlian yang dimiliki seorang operator mesin yang berbeda. Shewhart
mengembangkan sebuah metode untukmengukur variasi, dan menyediakan manajer dan
pekerja untuk menentukan apakah proses yang mereka operasikan bekerja dengan baik atau
memerlukan perhatian di dalam meningkatkan kualitas.
Kemudian ia merekomendasikan suatu tindakan untuk masing – masing kasus. Sebagai
hasilnya, seorang personel pabrikasi bisa mengindentifikasi variasi tersebut di dalam proses
dan menemukan cara untuk menguranginya. Tindakan ini dikenal sebagai Shewhart Cycle,
dan kemudian dimunculkan kembali di jepang dengan nama KAISEN (kemajuan
berkelanjutan). CMM menyediakan suatu struktur untuk KPA yang berisi hal yang umum, yang
terdiri dari tujuan, komitmen, kemampuan, aktivitas, pengukuran, dan verifikasi, dan dapat
bertindak sebagai struktur utama untuk peningkatan proses perangkat lunak.

1.4.1 Tujuan
Tujuan yang dinyatakan dalam CMM dihubungkan secara langsung kepada permasalahan dan
peluang dari organisasi pengembangan perangkat lunak. Sebagai contoh, di buku satu tujuan
CMM adalah bahwa kebutuhan sistem yang dialokasikan pada perangkat lunak dikendalikan
untuk menetapkan sebuah baseline untuk rekayasa perangkat lunak dan penggunaan
menajemen. Masalah menajemen kebutuhan adalah salah satu permasalahan yang paling
umum di dalam komunitas perangkat lunak. Pada kebanyakan perusahaan, kebutuhan tidak
dikendalikan sama sekali. Mereka mengubah semua cara melalui sikulus pengembangan
perangkat lunak, yang mencakup pengujian beta.

1.4.2 Komitmen untuk Melakukan

Fitur umu ini pada umumnya melibatkan penetapan dari kebijakan organisasi dan
memerlukan dukungan menajemen senior. Kumci pada fitur ini diharapkan mampu
menetapkan suatu hubungan antara menajemen senior dan orang – orang melakukan
peningkatan proses perangkat lunak yang menggunakan CMM sebagai penduanya.
Peningkatan proses perangkat lunak dikatakan sukses ketika komitmen dari menajemen
senior dengan sukses diuji.
Usaha pada peningkatan proses perangkat lunak memerlukan sebuah tujuan. Jika tujuan tidak
dinyatakan, proyek tidak akan fokus. Sebagai tambahan, suatu organisasi pengembangan
dengan sedikt kebijakan dan prosedur akan menunjukan kinerja dan ketidakkonsistenan.
Organisasi ini akan mengalami krisis yang ditandai dengan sebuah masalah.

1.4.3 Kemampuan untuk Melakukan

Kemampuan untuk melaukan fitur ini umum menguraikan prasyarat yang harus ada dalam
proyek atau organisasi untuk menerapkan proses perangkat lunak dengan seluruh
kemampuan yang ada. Ini berarti perlunya memiliki kemampuan untuk melakukan apa yang
sudah direncanakan.
Suatu prosedur yang didokumentasikan pada umumnya diperlukan sehingga seseorang yang
bertanggung jawab untuk suatu tugas atau aktivitas bisa melakukan dalam cara yang dapat di
ulang, dan orang lain dengan pengetahuan umum dari area akan mampu belajar dan
melakukan aktivitas atau tugas dengan cara yang sama.

1.4.4 Kegiatan-Kegiatan yang Dilakukan

Kegiatan dilakukan silih berganti dari satu organisasi ke organisasi yang lain. Aktivitas
implementasinya berbeda sebab tindakan detail, fokus organisasi, kebutuhan untuk
perencanaan, dan dokumentasinya berbeda. Fokus dari kegiatan CMM ada pada aliran proses
pengembangan perangkat lunak dan memerlukan prosedur yang menggambarkan hasil untuk
terpenuhi.
Beberapa perusahaan berjuang melalui implementasi CMM untuk sekali waktu menemukan
dirinya dialam situasi menurun dari Tingkat 4 ke Tingkat 2 sebab ingfrastruktur peningkatan
proses telah didasarkan pada ketrampilan dan usaha perorangan. Kegiatan yang dilakukan
harus dipandang dan diatur dari sudut pandang sistem. Jika demikian, menajemen perlu
memahami hubungan fungsi mereka di dalam siklus pengembangan perangkat lunak untuk
menggambarkan masukan dan kriteria untuk bagian dari siklus.

1.4.5 Mengukur dan menganalisis

Pengukuran dan analisis adalah fitur umum lain dari KPA yang menguraikan kebutuhan
untukmengukur proses dan menganilis pengukuran. Bagian pengukuran dan analisis dari
CMM pada umumnya meliputi contoh pengukuran yang bisa diambil untuk melakukan
efektivitas dan status kegiatan yang dilakukan.

1.4.6 Pembuktian Implementasi

Fitur umum pembuktikan implementasi menguraikan langah-langkah umtuk memastikan
bahwa aktivitas dilakukan sesuai dengan proses yang telah dibentuk. Fitur umum ini biasanya
berisi praktik utama yang berhubungan dengan kesalahan yang dilakukan oleh menajemen
senior, menajemen proyek, dan jaminan kualitas perangkat lunak.
Tujuann utama dari review berkala yang dilakukan oelh menejemen senior adalah untuk
menyediakan kesadaran dan pengertian yang mendalam, aktivitas proses perangkat lunak
pada suatu tingkatan abstrak yang sesuai, dan pada cara yang tepat waktu.
Lingkup dan isi dari review menajemen senior tergantung pda sebagian besar menajemen
senior yang dilibatkan pada review. Review menajemen senior bertanggung jawab pada
semua aktivitas proyek perangkat lunak dari organisasi yang diharapkan untuk terjadi pada
jadwal yang berbeda, dibandingkan dengan review oleh eksekutif senior dari keseluruhan
organisasi, review eksekutif diharapkan juga meliputi topik yang berbeda atau topik yang
sama pada tingkat abstrak yang lebih tinggi jika dibandingkan dengan review kesalahan
menajemen proyek.
1.5 Konsep Proses Utaman dari CMM
1.5.1 Definisi Proses Perangkat Lunak
Definisi proses perangkat lunak menjadi dasar jika tingkat yang lebih tinggi dari kematangan
diharapkan untuk dicapai. Suatu konsep dasar dari definisi proses di dalam CMM adalah
standar organisasi proses perangkat lunak. Standar organisasi proses perangkat lunak adalah
definisi operasional dari proses dasar yang memandu menetapkan suatu proses perangkat
lunak umum antarptoyek perangat lunak dari dalam organisasi.
Standar organisasi proses perangkat lunak menguraikan unsur-unsur proses perangkat lunak
dasar dengan masing-masing proyek perangkat lunak yang diharapkan untuk disertakan ke
dalam proses perangkat lunak yang digambarkannya. Standar ini juga menguraikan hubungan
(misalnya, pemesanan dan antarmuka) antara unsur-unsur proses dalam perangkat lunak.
Pada tingkat organisasi, standar organisasi proses perangkat lunak perlu untuk diuaraikan,
diatur, dikendalikan, dan ditingkatkan dalam cara formal.

1.5.2 Konsep Definisi Proses

Suatu konsep pokok yang mendukung pendekatan yang diambil oleh SEI dalam pekerjaan
definisi prosesnya adalah bahwa proses dapat dikembangkan dan dipelihara dengan cara
yang sama pada cara yang ditempuh oleh produk yang dikembangkan dan dipelihara/
kenutuhan meliputi suatu definisi proses untuk diuraikan, suatu arsitktur dan desain
implementasi desain proses pada proyek atau situasi organisasi, validasi dari uraian proses
via pengukuran, dan penyebaran proses ke dalam operasi yang tersebar luas di dalam
organisasi atau proyek yang menghendaki proses.
Menggunakan analogi pengembangan produk, suatu kerangka untuk pengembangan dan
pemeliharaan proses prangkat lunak telah ditinglatkan, yaitu dengan menerjemahkan konsep
kedalam salah satu atau lebih disiplin pengembangan proses (serupa untuk ketegasan istilah
yang digunakan untuk mengembangkan sistem embedded real-time versus sistem informasi
menajemen).

1.5.3 Standar Organisasi Proses Perangkat Lunak

Standar organisasi proses perangkat lunak merupakan definisi operasional dari prose dasar
yang memandu penetapan suatu proses perangkat lunak umu antarproyek perangat lunak di
dalam organisasi. Standar ini menguraikan unsur-unsur proses perangkat lunak pokok dengan
masing-masing proyek perangkat lunak yang diharapkan untuk disertakan ke dalam proses
perangkat lunak yang digambarkannya.
Hubungan antara unsur-unsur proses perangkat lunak kadang-kadang dikenal seagai suatu
arsitektur proses peranglat lunak. Organisasi standar proses perangkat lunak membentuk
dasar untuk suatu proyek yang menggambarkan proses perangkat lunak yang menyediakan
kesinambungan di dalam aktivitas proses organisasi dan sebagai acuan untuk pengukuran dan
peningkatan jangka panjang dari proses perangkat lunak yang digunakan di dalam organisasi.

1.5.4 Arsitektur Proses Perangkat Lunak

Arsitektur perangkat lunak merupakan arsitektur tingkat tinggi (ringkasan) yang menguraikan
organisasi standar proses perangkat lunak. Arsitektur ini menguraikan pemesanan,
anatarmuka, kesalingbergantungan, dan hubungan lainya di antara unsur-unsur organisasi
standar proses perangkat lunak. Arsitektur ini juga menguraikan antarmuka, ketergantungan,
dan hubungan-hubungan pada proses ekternal lain, misalnya rekayasa sistem, rekayasa
perangkat keras, dan menajemen kontrak.

1.5.5 Elemen Proses Perangkat Lunak

Suatu unsur proses perangkat lunak adalah unsur dari uraian proses perangkat lunak. Masing-
masing unsur proses meliputi suatu rangkaian tugas yang berhubungan erat da dibatasi
(misalnya, unsur perkiraan perangat lunak, unsur desain perangkat lunak, unsur pengodean,
dan unsur peer review). Uraian dari unsur-unsur proses mungkin berupa template untuk diisi,
pembagian untuk dapat diselesaikan, abstrak untuk diperbaiki, atau uraian lengkap untuk
dimodifikasi atau digunakan untuk tidak dimodifikasi.
Siklus hidup perangkat lunak merupakan periode waktu yang dimulai ketika produk perangkat
lunak dipahami dan berakhir ketika perangkat lunak tersedia untuk digunakan. Siklus hidup
perangkat lunak biasanya meliputi sebuah langkah konsep, langkah kebutuhan, tahap desain,
langkah implementasi, langkah pemeliharaan, dan kadang-kadang langkah pengunduran diri.
1.5.6 Produk Perangkat Lunak
Produk perangkat lunak adalah sekumpulan lengkap program komputer, prosedur, dan hal
yang berhubungan dengan dokuemntasi dan data yang ditunjuk untuk pemyerahan kepada
pelanggan atau pengguna akhir. Uraian proyek proses perangkat lunak yang digambarkan
pada umumnya tidak terlalu spesifik untuk dilakukan secara langsumg, walaupun uraianya
biasanya mengidentifikasi hal-hal, seperti peran (siapa yang melaksanakan tugas) dan jenis
perangkat lunak produk yang diperlukan untuk melaksanakan suatu tugas.
Rencana pengembangan perangkat lunak proyek, baik sebagai dokumen tunggal atau koleksi
rencana secara bersama dikenal sebagai suatu rencana pengembangan peranglat lunak,
menyediakan jembatan antara proyek proses perangkat lunak yang digambarkan (apa yang
akan dilakukan dan bagaimana akan dilakukan) dan menetapkan bagaimana proyek akan
dilakukan (misalnya, perorangan yang akan menghasikan produk pekerjaan perangkat lunak
yang menurut jadwal).

1.6 CMMI (Capability Maturity Model Integration)

Menurut Dennis M. Ahern, Aaron Clouse dan Richard Turner CMMI (Capability Maturity
Model Intergration) adalah suatu pendekatan yang berfungsi untuk meningkatkan proses
piranti lunak (software process) di dalam organisasi agar menjadi lebih efisien dan efektif.
CMMI merupakan salah satu model kematangan (maturity model) yang digunakan untuk
meningkatkan proses (process improvement) dalam organisasi. Tujuan dari penerapan CMMI
di dalam organisasi adalah untuk meningkatkan proses pengembangan dan perawatan
produk-produk piranti lunak organisasi tersebut.
Terjemahan CMMI adalah Integrasi Model Kematangan Kemampuan. CMMI adalah suatau
pendekatan perbaikan proses yang memberikan unsur-unsur penting proses efektif
organisasi. Praktik-praktik terbaik CMMI dipublikasikan dalam dokumen-dokumen yang
disebut model, yang amsing-masing ditujukan untuk berbagai bidang yang berbeda.
Saat ini terdapat dua bidang minat yang mencakup oleh model CMMI, yaitu pengembangan
(development) dan akuisisi (acquistion). Versi terkini CMMI adalah versi 1.2 dengan dua model
yang tersedia, yaitu CMMI-DEV (CMMI for Development) yang dirilis pada Agustus 2006 yang
ditujukan untuk proses pengembangan produk dan jasa, dan yang kedua CMMI-ACQ (CMMI
for Acquistion) yang dirilis pada November 2007 dan ditujukan untuk menajemen rantai
suplai, akuisisi, serta proses outsourcing di pemerintahan dan industri.
Terlepas pada model manakah yang dipilih oleh suatu organisasi, praktik-praktik terbaik
terbaik CMMI harus disesuaikan oleh masing-masing organisasi tergantung pada sasaran
bisnis.
Berikut ini adalah Tabel Area proses

Istilah
No Area Proses Singkatan Kategori Level
(Bhs. Indonesia

Casual Analysis and Analisis dan

1 CAR Pendukung 5
Resolution Resolusi Penyebab
Configuration Menajemen
2 CM Pendukung 2
Menagement Konfigurasi
Decision Analysis and Analisis dan
3 DAR Pendukung 3
Resolution Resolusi Keputusan
Integrated Project Menajemen Proyek Menajemen
4 IPM 3
Management Terintegrasi Proyek
Measurement and Pengukuran dan
5 MA Pendukung 2
Analysis Analisis
Organizational Inovasi dan
Menajemen
6 Innovation and OID Penyebaran 5
Proses
Deployment Organisasi
Organizational Process Definisi Proses Menajemen
7 OPD 3
Definition Organisasi Proses
Organizational Process Fokus Proses Menajemen
8 OPF 3
Focus Organisasi Proses
Organizational Process Kinerja Proses Menajemen
9 OPP 4
Performance Organisasi Proses
Pelatihan Menajemen
10 Organizational Training OT 3
Organisasi Proses
 Penjaminan
Process and Product
11 PPQA Kualitas Proses dan Pendukung 2
Quality Assurance
Produk

12 Product Integration PI Integritas Produk Teknis 3

Pengawasan dan
Project Monitoring and Menajemen
13 PMC pengedalian 2
Control Proses
proyek
Perencanaan Menajemen
14 Project Planning PP 2
Proyek Proyek
Quantitative Project Menajemen Proyek Menajemen
15 QPM 4
Menagement Kuantitatif Proyek
Requirement Pengembangan
16 RPP Teknis 3
Development Kebutuhan
Requirement Menajemen
17 REQM Teknis 2
Menagement Kebutuhan
Menajemen
18 Risk Menagement RSKM Menajemen Resiko 3
Proyek
Menajemen
Supplier Agreement Menajemen
19 SAM Kesepakatan 2
Menagement Proyek
Pemasok

20 Technical Solution TS Solusi Teknis Teknis 3

21 Validation VAL Validasi Teknis 3

22 Verification VER Verifikasi Teknis 3

1.7 Rangkuman
CMM dikembangkan oleh software Engineering Institute (SEI) telah dijelaskan secara
mendetail pada publikasi yang berbeda. CMM adalah kerangka konseptual yang menyajikan
menajamen proses dari pengembangan perangkat lunak. CMM berisi lima tingakat, yaitu :
1. Tingkat 1, Initial
Proses tingkat awal merupakan proses yang paling sering dipraktikan di dalam bisnis
perangkat lunak. Perusahaan mengembangkan proses ini dari waktu ke waktu dan
mengembangkan kepemilikan. Sampai taraf tertentu, maka menyajikan kenyataan
dari organisasi pengembangan perangkat lunak, yaitu tekanan, krisis, dan
pembatasan.

2. Tingkat 2, Repeatable
Pada tingkat ini, proses menajemen proyek dasar dibentuk untuk menjejaki biaya-
biaya, jadwal, dan kemampuan. Disiplin proses perlu dilakukan pada tempatnya untuk
mengulangi kesuksesan yang sebelumnya terjadi pada proyek dengan aplikasi yang
sama.

3. Tingkat 3, Defined
Proses peranglat lunak untuk kegiatan rekayasa dan menajemen akan
didokumentasikan, distandarisasi, dan terintegrasi ke dalam suatu organisasi proses
perangkat lunak yang luas. Semua proyek menggunakan dokumentasi dan versi yang
telah disetujui, dan proses-proses organisasi untuk mengembangkan dan memelihara
perangkat lunak.

4. Tingkat 4, Menaged
Pada tingkat ini, ukuran terperinci dari proses perangkat lunak dan kualitas produk
dikumpulkan. Keduanya, baik proses perangkat lunak dan produk, dipahami adalah
menurut banyaknya dan dikendalikan dengan menggunakan ukuran terperinci. KPA
dari tingkat ini kebanyakan tidak dipahami di dalam keseluruhan struktur CMM sebab
arah mengenai bagaimana perpindahan dari Tingkat 3 le Tingkat 4 sangat tidak jelas.

5. Tingkat 5, Optimized
Pada tingkat ini, peningkatan proses berlanjut dengan umpan balik kuantitatif dari
proses dan dari pengujian teknologi, dan ide-ide inovatif. Pada tingkat ini, organisasi
berpindah dari langkah peningkatan proses ke dalam langkah menajemen proses.
Dari kelima tingakatan tersebut, kita dapat menyimpulkan bahwa semakin tingi tingkat suatu
oerganisasi, semakin banyak keuntungan yang bisa didapat, dan dirasakan, baik oleh
porganisasi itu sendiri atau bagi pemesanan perangkat lunak, seperti resiko kegagalan yang
rendah, waktu pembuatan perangkat lunak yang semakin akurat dan lebih cepat, dan
pengeluaran biaya yang lebih rendah.
 2. Menagement Proyek untuk Perangkat Lunak
2.1 Apa itu Proyek ?

Sebuah Proyek akan dikerjakan sekali, yang sebagian besar pekerjaannya dikerjakan secra
berulang-ulang untuk mengelola pekerjaan tersebut.
Orang yang bekerja dalam proyek mungkin akan menangangi pekerjaan lain yang sudah
selesai sehingga tim bersifat sementara. Anggota tim sering kali tidak mempunyai laporan
untuk manajer proyek dalam basis tetap. Artinya, proyek tidak memiliki kekuasaan langsung
atas mereka. Situasi seperti ini memiliki serangkaian masalah.
Seorang pakar kualitas, Dr. J.M. Juran, mengartikan suatu Proyek sebagai “ Sebuah kumpulan
masalah untuk diselesaikan.”definisi ini ditujukan untuk menyelesaikan masalah dan
kegagalan untuk menetapkan masalah secara teratur yang kadang-kadang membawa kita
dalam masalah.
J.M.Juran menawarkan definisi dari sebuah masalah. Sebuah keinginan objectif tidak hanya
berupa sebuah masalah. Kunci untuk masalah ini adalah adanya hambatan yang mencegah
anda untuk mencapai tujuan anda dengan mudah. Penyelesaian masalah terdiri dari
penemuan cara-cara untuk mengatasi atau mendapatkan hambatan yang dialami.

2.2 Apa itu Manajemen Proyek ?

Manajemen Proyek adalah perencanaan, penjadwalan, dan pengendalian aktivasi proyek
untuk mencapai tujuan proyek. Tujuan utama pasti ditemui pada kinerja, biaya, dan tujuan
waktu ketika pada saat yang sama Anda mengendalikan atau memperbaiki lingkungan dari
proyek pada tingkat yang tepat.
Manajemen Proyek juga didefinisikan sebagai salah suatu metodologi yang digunakan untuk
mengontrol tugas, jadwal, dan biaya proyek (Cagle, 2005). Lingkungan waktu proyek akan
berkurang ketika anggaran dipotong dengan beberapa rencana kerja semula yang hampir
dilaksanakan. Masalah dengan lingkungan yang berubah cenderung kecil dan bertambah, dan
jika salah satu dari keduanya terjadi, anggaran biaya atau jadwal proyek akan dipotong.
Masalah ini merupakan kasus umum dari kegagalan proyek. Seorang Manajer Proyrk
bertangung jawab untuk tetap memberi informasi kepada para pemegang saham mengenai
akibat dari perubahan lingkungan proyek, melindungi mereka dari keterkejutan pada akhir
kerja, dan melindungi manajer proyek dari evaluasi pada target semula, bukan pada proyek
yang diperbaiki.
Empat tujuan Proyek adalah kinerja (kualitas kerja yang sudah dilakukan, biaya (biaya dari
proyek yang dikerjakan, berhubung langsung kepada SDM dan sumber-sumber fisik yang
diajukan), waktu (jadwal yang harus dilakukan), dan cakupan (pentingnya kinerja untuk
dilakukan). Empat tujuan tersebut dihubungkan dalam satu persamaan:

Cost= f(P,T,S)
Biaya (cost) adalah fungsi (f) dari kinerja (p), waktu (T), dan lingkungan (S). Jika P dan S
bertambah, biaya biasanya juga bertambah. Hubungan antara waktu dan biaya tidak linear.
Sesuai keteentuan, biaya meningkat ketika waktu proyek yang dilakukan berkurang dibawah
waktu optimum yang ditentukan, yaitu pada suatu keberadaan jangka waktu proyek yang
dihasilkan dalam kinerja terbaik dari semua sumber. Jika janngka waktu tersebut disingkat,
pembayaran tenaga kerja tingkat premium sebagai sebuah konsekuensi perlu dilakukan.

2.3 Sisi Manusia dari Manajemen Proyek

Para pakar menyetujui adanya 10 prinsip penyebab kegagalan proyek. Tetapi, bagaimana
dengan faktor-faktor yang mengarah pada kesuksesan? Contoh kesuksesan adalah memiliki
orang yang tepat dan mengatur mereka dengan benar. Meskipun demikian, kedua kondisi ini
sering dilanggar.

2.4.1 Orang-orang yang tepat

Proyek biassanya berjalan dalam lingkungan sumber daya yang berbagi. Model ini akan
menggunkan karyawam yang sama pada semua proyek. Ketika tiba waktunya untuk memulai
pekerjaan, siapa pun yang ada akan ditunjuk
Untuk suatu hal, menciptakan model tersebut gambaran bahwa proyek sering menempatkan
para staf secara sederhana hanya karena seseorang ada pada posisi tersebut. Kemungkinan
alokasi sumber daya merupakan satu-satuya perhatian yang paling penting dari manajer
proyek.
2.4.2 Tipe Manajemen yang Tepat
Komponen kedua majemen proyek yang sukses adalah pengelolaan orang yang tepat.
Beberapa manajer masih berpedoman pada sebuah pandangan kekuasaan yang dapat
diperinci sebagai prinsip KITA, yaitu “ jika orang-orang tidak berkinerja, anda tendang
mereka.” Pandangan mereka tentang ini sejalan dengan dengan pandangan tradisional teori
X yang ditemukan oleh McCregor, yang memandang bahwa orang-orang tidak termotivasi
(hanya termotivasi dengan uang), tidak menilai kepercayaan, dan tidak berfikir serta
memberikan kontribusi secara independen.

2.5 Langkah-langkah dalam Mengelola Sebuah Proyek

Langkah nyata dalam mengelola sebuah proyek adlah dengan terus maju, bukan
menyelesaikannya. Berikut ilustrasinya:

MENETAPKAN MASALAH
Mengembangkan Solusi pilihan

MERENCANAKAN PROYEK
Apa yang harus dilakukan?
Siapa yang akan melakukan?
Bagaimana dia akan melakukannya?
Kapan harus dilakukan?
Berapa banyak dilakukan?
Apa haru dibutuhkan untuk melakukannya?

MELAKSANAKAN RENCANA

MENGAWASI DAN MENGENDALIKAN

PERKEMBANGAN
Apa targetnya
jika tidak tercapai, apa yang harus
dilakukan?
perlukah rencana diubah?

MENUTUP PROYEK
Apa yang harus ditingkatkan?
Apa yang harus kita pelajari
Penjelasannya:
1. Menetapkan Masalah
Langkah ini akan mengidentifikasi maslah yang akan diselesaikan oleh proyek.
2. Mengembangkan Solusi pilihan
Alternatif solusi pembuka pikiran (anda dapat melakukan aksi ini sendiri atau
kelompok).
3. Merencanakan Proyek
Perencanaan berarti menjawab pertanyaan mengenai apa yang harus dilakukan,
untuk siapa, untuk berpa banyak, bagaimana, kapan, dan lain-lain.
4. Melaksanakan Rencana
Segera dilaksanakan, setelah rencana dibuat.kebanyakan orang-orang berusaha keras
untuk bersama-sama membuat trencana, kemudian gagal menjalankannya.
5. Mengawasi dan Mengendalikan perkembangan
jika perkembangan tidak diawasi, anda tidak dapat yakin bahwa anda akan berhasil
seperti menggunakan peta jalan untuk mencapai tujuan, tetapi mengacuhkan tanda
dataran tinggi.
6. Menutup Proyek
Jika tulisan sudah selesai, proyek akan selesn, dengan mudah ada sebuah langkah
terakhir yang harus diambil.

2.6 Sistem Manajemen Proyek

Manajemen proyek yang lengkap meliputi 7 komponen, jika salah satu komponen tersebut
tidak ditempatkan atau tidak berfungsi dengan memuaskan, anda akan kesulitan dalam
mengelola proyek.

2.7 Faktor Manusia

Suatu piramida yang ditopang oleh subsistem manusia digunakan untuk menunjukkan bahwa
semua subsistem yang lain merupakan komponen pendukung.agar berhasil, seorang manajer
proyek harus mampu membagi secara efektif semua bagian subsistem yang meliput:
1. Kepemimpinan
2. Negosiasi
 3. Pembentukan tim
4. Motivasi
5. Komunikasi
6. Pembuatan keputusan
Mengetahui bagaimana mengubah sebuah kelompok menjadi tim juga sangat penting.
Mereka lebih setia pada manajerdaripada proyek. Sementara manajer tidak dapat
memberikan motivasi pada anggota tim, mereka harus mengetahui bagaimana mendirikan
kondisi kerja yang menggambarkan motivasi apa saja yang dimiliki.
Para manajer tidak mempunyai masalah komunikasi, seluruh kesalahan terletak pada
pengikut yang semata-mata tidak mendengarkan. Kemampuan pembuatan keputusan tak
hanya mencakup pembuatan keputusan perorangan, tetapi juga untuk mengetahui kapan
keputusan terbaik dibuat oleh sebuah kelompok dan kapan oleh perseorangan hingga saat
ini, para manajer autokraksilah yang membuat seluruh keputusan.

2.8 Metode-metode
Metode-metode merujuk pada alat-alat pekerjaan anda atau apa saja yang anda gunakan
untuk bekerja. Contoh, CAD (alat bantu desain komputer) merupakan sebuah alat.

2.8.1 Kebudayaan
Budaya organisasi mempengaruhi segala hal yag anda lakukan. Kebudayaan dibentuk oleh
nilai-nilai, keyakinan,sikap, tingkah laku, dan tradisi orang-orang didalam perusahaan.

2.8.2 Organisasi
Setiap organisasi harus berhadapan dengan penugasan dan definisi dari kekuasaan masing-
masing orang, tanggung jawab dan pertanggungjawaban.

2.8.3 Perencanaan
Perencaan yang baik itu penting untuk keberhasilan. Namun para manajer lebih sering
berbicara perencanaan namun menjalankan kenyataan.
2.8.4 Informasi
Kebanyakan organisasi bermasalah dengan organisasi dalam dua hal Data Historical yang baik
diperlukan untuk merencanakan proyek sementara kebanyakan organissasi tidak menyimpan
catatan-catatan yang baik sehingga mereka tidak memiliki cukup informasi mengenai sejarah
sendiri

2.8.5 Pengendalian
Subsistem pengendalian didukung oleh subsitem perencanaan dan subsistem informasi.
Keduannya dibutuhkan untuk mencaai pengendalian karena pengendalian dilatih dengan
membandingkan antara dimana anda sekarang dengan dimana anda seharusnya.

2.9 Rangkuman
Manajemen proyek adalah perencanaan, penjadwalan, dan pengendalian aktifitas proyek
untuk mencapai tujuan proyek. Tujuan utama pasti ditemui pada kinerja, biaya, dan tujuan
waktu, ketika pada waktu yang sama Anda mengendalikan atau memperbaiki lingkungan dari
proyek pada tingkat yang tepat. Idealnya, lingkungan dari proyekharus mengingatkan seluruh
kehidupan konstan dari pekerjaan. Secra alami, kondisi ini jarang terjadi. Salah satu kunci dari
kandungan kesuksesan inii adalah dengan memiliki orang yang tepat dan mengatur mereka
dengan baik.
1. Sebuah proyek merupakan sebuah masalah yang didaftrkan untuk penyelesaian
2. Jika permasalahan tidak didefinisikan dengan benar, anda mungkin akan menemukan
penyelesaian yang tepat pada masalah yang salah
3. Fokus pada hasil yang diinginkan, bagaimana anda tahu kapan akan mencapainya
4. Cobalah untuk belajra dri setiap proyek dengan melkaukan audit akhir
 3. Asumsi Menajemen Proyek
3.1 Pendahuluan
Dalam menganalisis interaksi antara pengembangan perangkat lunak dan manajemen proyek,
kita telah mempersiapkan pengujian dari karakteristik unik pengembangan manajemen
proyek. Langkah berikut merupakan pengujian fitur-fitur yang cocok dari manajemen proyek,
yaitu:
1. Manajemen ruang lingkup
2. Manajemen waktu
3. Manajemen biaya
4. Manajemen kualitas
5. Manajemen risiko
Mungkin Anda tertarik dengan perbedaan-perbedaan antara proyek pengembangan
perangkat lunak dan jenis-jenis proyek lainnya sehingga tidak melihat area-area manajemen
proyek yang menunjukkan bahwa perbedaan-perbedaan menjadi tidak terlalu penting.Topik-
topik berikut tidak tercakup karena perbedaan-perbedaan tersebut akan dianalisis :
1. Manajemen integrasi lingkup,
2. Manajemen SDM,
3. Manajemen komunikasi,dan
4. Manajemen pengadaan

3.2 Asumsi yang Tersembunyi

Di bagian ini kita akan mencari asumsi yang tidak sempurna dalam kenyataan pengembangan
proyek perangkat lunak karena mungkin merupakan alasan yang sangat berarti mengapa
proyek perangkat lunak sering kali gagal.Oleh karena itu, kita akan membandingkan beberapa
asumsi yang dapat kita temukan dalam 12 kuci karakteristik dalam pengembangan perangkat
lunak.
Proyek-proyek bisa gagal karena beberapa alasan, antara lain SDM yang kurang dan tidak
efektifnya manajemen. Namun, faktor ini tidak terlalu terperinci dalam pengembangan
perangkat lunak dan tidak menjelaskan mengapa perngembangan perangkat lunak sangat
sering menemui kendala. Kita ingin mencari tahu mengapa proyek perangkat lunak bisa gagal
bahkan padansaat kondisi yang memungkinkan ketika ada keahlian dan motivasi tim, dan
ketika ada harapan pengguna yang sebenarnya.
Analisis ini diterapkan pada berbagai pekerjaan proyek untuk pengguna dan pelanggan
internal. Proyek perangkat lunak dijalankan oleh pengembangan pemilik perusahaan yang
tidak ingin gagal seperti yang dialami oleh kontraktor luar. Faktor utama yang sangat
menentukan perbedaan ini adalah proyek untuk pelanggan luar yang selalu terikat kontrak,
bahkan dalam bentuk perjanjian yang sedang berjalan atau per proyek kontrak (isu tertentu
untuk kontrak proyek perangkat lunak akan dicatat).
Manajer proyek yang berpengalaman mengetahui saat untuk mengambil tindakan dan saat
melanggar peraturan. Banyak proyek perangkat lunak mampu ditangani dan hasil yang
banyak dapat diterima. Tetapu, pengalaman dan kegagalan adalah cara yang menyakitkan
untuk dipelajari. Jadi, biarkan menjadi catatan dalam pikiran sebagaimana terlihat dari disiplin
manajemen proyek dan mencari perubahan yang harus diterapkan jika ingin proyek
perangkat lunaknya berhasil.

3.3 PMBOK
PMBOK adalah singkatan dari Project Management Institute’s Project Management Body of
Knowledge. Proyek ini menjadi suatu acuan untuk menjelaskan bagaimana seharusnya
manajemen proyek bekerja. PMBOK telah diterbitkan dalam berbagai versi, sejak tahun 1987,
dan sejak itu menjadi standar American National Standards Institute (ANSI), PMBOK ini
bertujuan untuk mengidentifikasi pekerjaan yang baik dan menetapkan terminologi umum
untuk manajemen proyek.PMBOK menjabarkan manajemen proyek ke dalam sembilan topik
(area pengetahuan).
Pmbok menjelaskan bagian terpenting dari manajemen proyek secara metodologi yang telah
berhasil dikembangkan pada proyek-proyek industri yang berbeda-beda, pada batasan yang
luas. Karena PMBOK direncanakan untuk digunakan dalam berbagai situasi, PMBOK akan
diadaptasi dalam berbagai situasi pengembangan perangkat lunak.

3.4 Cakupan Manajemen

Cakupan didefinisikan sebagai proses untuk memecahkan poin masalah utama secara total
(atau kebutuhan) dari sebuah proyek menjadi lebih kecil, lebih mendekati tujuan tertentu.
Setiap tujuan pada suatu tingkatan diselesaikan menjadi bagian tujuan berikutnya dan
demikian seterusnya. Penjelasan mendetail dari tujuan-tujuan ini dikumpulkan ke dalam
kamus struktur penyelesaian kerja. Struktur penyelesaian kerja digunakan untuk
menghasilkan biaya dan durasi waktu yang diperkirakan.

Penyeberangan Pejalan Kaki

Tanda-tanda jalan
Rambu-rambu Lalu Lintas
Pos Rambu-rambu Lalu Lintas
Kabel-kabel Listrik
Jembatan
Fondasi
Tiang
Tempat Jalan
Perputaran Jalan, dan lain-lain

Gambar : Bagian dari contoh struktur penyelesaian kerja untuk proyek pembangunan jalan
baru

Asumsi : Ruang lingkup dapat dijelaskan secara utuh.

Pertanyaan-pertanyaan tersebut merupakan pertanyaan yang penting karena menurut

PMBOk langkah selanjutnya berisi penerimaan formal untuk dokumen cakupan. Definisi
cakupan sering kali menjadi bagian dari kontrak untuk proyek. Dalam hal perselisihan ini
terdapat proses pengadilan dan hukuman keuangan. Oleh karena itu, kita mempunyai
motivasi masing-masing untuk memastikan bahwa proses tidak akan disesali.
PMBOK (PMI 2000) memberikan masukan yang masuk akal untuk melakukan proses definisi
cakupan : “Definisi cakupan yang benar-benar dibutuhkan adalah kritikan pada proyek yang
sukses. Ketika ada definisi cakupan yang kurang, proyek akhir membutuhkan biaya yang
diperkirakan jauh lebih tinggi karena perubahan pasti menggangu irama proyek yang
disebabkan pekerjaan yang berulang-ulang, peningkatan waktu kerja, rendahnya
produktivitas, dan moral dari para pekerja itu sendiri.”
Menurut PMBOK, definisi cakupan yang kurang adalah sesuatu yang tidak lengkap atau tidak
akurat. Tetapi, perangkat lunak merupakan suatu hal yang sudah mendasar dan kompleks
sehingga definisi cakupan untuk pengembangan perangkat lunak harus dilakukan secara
mendetail. Implikasi yang mendetail setidaknya lebih membantu untuk menetapjan item
yang paling cocok. Perangkat lunak sejak proses kebutuhan tidak selalu lengka, lebih banyak
detail definisi pertanyaan yang mengkritik : “Akankah lebih baik untuk memasukkan detail
yang sudah kita ketahui salah?Atau, akankah menjadi lebih baik menghilangkan tingkat detail
ini pada tingkat awal?”
Pada Praktiknya, ketidaktepatan akan selalu menghasilkan pekerjaan yang berulang. Kecuali
jika pengguna tidak peduli atau menyerah dan pasrah, mereka akan selalu membuat
perubahan pada perangkat lunak untuk memastikan bahwa hal itu dilakukan sebagaimana
yang telah dipikirkan.
Definisi cakupan yang sangat mendetail akan menimbulkan hasil perubahan yang lebih
banyak. Perubahan-perubahan yang ditunjukkan hanya pada satu hal yang buruk dan hanya
berkonsekuensi negatif pada hal yang didiskusikan. Perubahan ini lah musuh terbesar dari
PMBOK.

3.4.1 Kapan Sebaiknya Definisi Cakupan Terjadi ?

Asumsi : Definisi cakupan dapat dilakukan sebelum proyek

dimulai

Asumsi lain yang tersembunyi adalah proses definisi cakupan yang cukup membingungkan
dan dapat dibentuk di luar konteks proyek semula. Kita dapat membaginya dengan tujuan
untuk membuktikan aktivitas yang kita harapkan untuk pelaksanaan selama proyek.
Bagaimanapun, dalam pengembangan perangkat lunak, definisi cakupan dapat menjadi
proporsi substansial dari durasi dan biaya proyek. Mayoritas pekerjaan dilakukan berdasarkan
kebutuhan dan kemudian diterjemahkan ke dalam cara kerja perangkat lunak.
Pada praktiknya, pendekatan ini tidak bekerja dengan baik seperti yang diharapkan. Begitu
puj juga dengan proses kontral perubahan yang sangat dipaksakan. Didalam Kasus ini, aliran
atau peningkatan permintaan perubahan melalui proses kontral perubahan dilakukan dengan
sis-sia. Untuk pengembangan perangkat lunak, kebanyakan isu yang muncul adalah untuk
memperbarui detail-detail yang lebih kecil sehingga memerlukan biokrasi. Tetapi, jika langkah
definisi cakupan awal mengalami perubahan yang singkat dan jika definisi cakupan
 berkelanjutan merupakan hal yang tidak lazim, kemudian pada bagian apa cakupan dapat
dengan jelas digambarkan? Jika klien dan pengembangan tidak pernah mendapat
kesempatan, apa yang diberikan proyek tersebut dalam mendapatkan tujuan-tujuannya
untuk dapat diterima oleh kedua belah pihak ? Supaya adil, edisi ketiga dari PMBOK
(PMBOK2004) kembali dari pemberitaan hard-line dari edisi kedua (PMI, 2004), dan
mengatakan bahwa “permintaan-permintaan akan mengurangi detail secara umum pada
tahap awal dan lebih mendetail pada tahap selanjutnya sebagai karakteristik produk yang
mengalami peningkatan yang lebih teliti lagi. Dengan bentuk dan substansi dari kebutuhan
yang akan berubah, hal ini akan selalu menyediakan detail penting untuk mendukung
perencanaan proyek selanjutnya.”Walaupun demikian, PMBOK tidak secara spesifik
membuat ini terjadi.

3.5 Manajemen Waktu

Pada bagian ini menjelaskan empat aktivitas utama di dalam area manajemen waktu yang
akan ditunjukkan pada gambar dibawah.

Menajemen Menajemen
Lingkup Waktu

Defisi Defisi Urutan Aktivitas Pengemba

Lingkup aktivitas aktivitas Perkiraan ngan
Durasi Jadwal

Menajemen Lingkup

Perencana Perkiraan
an Sumber Biaya
Saya

Gambar : Aktivitas-aktivitas utama di dalam manajemen lingkup, waktu, dan biaya

3.5.1 Definisi Aktivitas
Aktivitas didefinisikan sebagai tugas utama dalam manajemen waktu yang terjadi setelah
definisi cakupan. Definisi cakupan merinci tujuan-tujuan dan kebutuhan proyek ke dalam
hirerki Work Breakdown Structure, sedangkan aktivitas merinci pekerjaab proyek ke dalam
daftar Aktivitas.

Asumsi : Pengembangan perangkat lunak terdiri dari aktivitas-aktivitas yang jelas

berbeda

Disamping pengembangan perangkat lunak, ada juga aktivitas yang kurang penting, seperti
konfigurasi layanan produksi, pelatihan pengguna, dan pemasangan perangkat lunak,
walaupun termasuk tugas penting dan benar. Satu-satunya aktivitas substansial adalah
pengembangan melaksanakan pengembangan perangkat lunak itu sendiri, tidak seperti yang
anda harapkan dari contoh diagram yang diberikan dalam PMBOK, yang terdiri dari aktivitas
seperti, perancangan, kode/konstruksi dan pengujian unit (unit test).
Untuk membuat perangkat lunak atau membuat produk lain, yakinlah bahwa hal pertama
yang harus dilakukan adalah merancangnya, menyusunnya, dan kemudian mengujinya. Jika
ada pengujian yang gagal dan kemudian fitur baru telah merusak beberapa produk fungsional
yang telah ada sebelumnya, kesalahan tersebut harus diperbaiki. Ketika penyusunan
pengujian ini telah selesai dilakukan, ia akn memindahkan kode ke dalam tim penympanan
perangkat lunak sehingga tugasnya telah selesai dan semua sitem telah bekerja denngan baik
dan sempurna.
Cockburn (1999) menemukan bahwa “ proses momen ke momen yang diikuti tim itu sangan
rumit dan tidak mungkin ditulis semua.” Pengujian unit ini mungkin akan diperluas seperti
yang ia tulis pada kode dan dikemas dengan cara baru fiturnya bisa gagal.

3.5.2 Mengapa Proyek Perangkat lunak bisa Gagal ?

Seseoorang berpendapat bahwa tugas ini sebenarnya merupakan kumpulan dari aktivitas yang
berbeda-beda. Kita dapat melihat pengembang mengumpulkan kebutuhan-kebutuhan, menulis
unit pengujian, dan menyusun fitur ke dalam sistem.
3.5.3 Pembagian Aktivitas
Setelah membagi aktivitas-aktivittas, langkah selanjutnya adalah mengidentifikasi
ketergantungan di antara aktivitas tersebut dan mengurutkannya sehingga masing-masing
aktivitas dilaksanakan hanya setelah aktivitas yang tergantung telah selesai. Pembagian
aktivitas diartikan sebagai hal yang sangat sederhana dalam kontruksi bahwa ketergantungan
yang berubah ada diantara variasi tugas.
Asumsi : Aktivitas-aktivitas pengembangan perangkat lunak dapat diurutkan.
Kemampuan ini akan secara normal disimpan terpisah dari logika bisnis (business logic) atau
lapisan tengah (middle layer) dari aplikasi. Sebagai contoh, perusahaan asuransi mugnkin
menetapkan aturan bisnis untuk nilai dari mobilnya. Aturan ini dimasukkan pada layer
terpisaah sehingga dapat digunakan oleh beberapa layar (screen ) antarmuka pengguna yang
membutuhkannya. Layer terendah mempunyai hubungan dengan penyimpanan data (data
storage) dan pengembalian (retrieval). Layer ini berfungsi untuk koneksi pada basis data atau
untuk aplikasi mainframe legacy lama yang sangat mahal untuk digantikan (seperti,
pengendalian inventaris).
Untuk kode level tertinggi (higher-level), pengembang umumnya menggunakan “potongan”
untuk mengisolsai kemampuan dari layer terendah yang belum ditulis. Suatu potongan adalah
rutin yang menampilkan fungsi hanya pada cara ketika menggunakannya, tetapi tidak benar-
benar dilakukan pada pekerjaan rill mana pun.
Situasi terburuk terjadi ketika proyek telah dibagi kedalam aktivitas perancangan, konstruksi,
dan pengujian selama definisi aktivitas. Aktivitas ini tidak mempunyai ketergantungan alami
terhadap yang lainnya,, dan Anda dapat membangun urutan diagram aktivitas yang terlihat
luar biasa dan tertata rapi. Walaupun begitu, hal ini bukan merupakan cara yang terbaik
untuknya. Model pengembangan yang digunakan adalah model air terjun (waterfall model)
dari pengembangan perangkat lunak karena lebih mudah menjalankannya dari satu langkah
ke langkah selanjutnya daripada harus mencobanya untuk kembali lagi ke kondisi semula
“upstream”.
Teknologi komputer sering menyebut model air terjun mempunyai tujuan untuk digunakan
dalam menyamakan inovasi-inovasinya. Teknologi komputer dewasa ini telah didiskreditkan.
Beberapa perkembangan perangkat lunak yang termasuk di dalamnya lebih banyak
menggunakan model tersebut.
 KEBUTUHAN

PERANCANGAN

KONSTRUKSI

PENGUJIAN

Isu lain adalah setiap aktivitas harus menghasilkan seluruh artefak sebuah produk yang aktual,
seperti spesifikasi, rencana, atau dokumen lainnya yang akan dimasukan untuk aktivitas
berikutnya dalam urutannya. Hanya konstruksi aktivitas yang menghasilkan sesuatulah yang
secara aktual bermanfaat bagi klien. Aktivitas analisis, arsitektur, dan perancangan masing-
masing menghasilkan suatu dokumen yang hanya digunakan sekali saja, dan kemudian
dibuang. Aktivitas seperti ini bukanlah cara yang efektif untuk mengembangkan perangkat
lunak.
Pendekatan terbaik ada pada urutan aktivitas sehingga layer terendah akan terlengkapi
sebelum kerja dimulai pada layer yang lebih tinggi, membangun aplikasi “dari bagian atas”.
Cara ini menghindari beberapa masalah dari pendekatan air terjun, tetapi masih
memperkenalkan suatu ketergantungan artefak yang tidak disukai untuk disamakan. Tetapi,
cara terbaik untuk mengatur proyek adalah dengan meyakinkan bahwa tugas dengan level
yang lebih tinggi mempunyai risiko yang harus pertama kali dikeluarkan.

3.5.4 Perkiraan Durasi Aktivitas

Langkah ketiga dalam proses manajemen waktu adalah perkiraan durasi aktivitas. Proses ini
muncul tepat setelah pembagian aktivitas. PMBOK menyarankan bahwa perkiraan tersebut
harus berasal dari individu dengan aktivitas khusus.
Asumsi : Selalu ada cara untuk menghasilkan perkiraan bermanfaat
3.5.5 Jumlah Berdasarkan Durasi
PMBOK membatasi tiga teknik untuk memperkirakan durasi aktivitas. “Jumlah berdasarkan
Durasi” adalah suatu cara yang dapat Anda tambahkan untuk meningkatkan jumlah produksi.
Teknik ini juga dapat menghasilkan perkiraan yang paling tepat. Sebagai contoh, dalam
pengembangan rapid, mcConnell (1999) menjelaskan cara untuk memperkirakan jadwal
perangkat lunak dari pekiraan jumlah baris kode dalam menyelesaikan perangkat lunak.
Bagaimanapun juga, data yang disajikan masih berdasarkan pada proyek pengembangan
perangkat lunak pada tahun 1970-an dan 1980-an. Tidak ada framework aplikasi perusahaan
dan hampir semua kode diitulis dari kode yang sebelumnya. Sejak perkembangan teknologi
kebanyakan yang mulai ketinggalan (karakteristik ke-7), proporsi besar dari peralatan yang
akan menjadi baru bagi pengembang dan kemampuan alat tersebut dapat memberikan
wacana yang hanya dapat diterjemahkan oleh para ahli. Kondisi ini sering kali menjadi
pengalaman pahit karena suatu proyek yang berkembang diperkirakan sejak adanya batasan
yang tidak terlihat dan masalah di dalam teknologi baru.

3.5.6 Analogi Perkiraan

Teknik kedua, yaitu analogi perkiraan menggunakan durasi yang aktual dari yang sebelumnya,
yaitu aktivitas yang sama untuk memperkirakan durasi aktivitas dalam proyek yang sedang
direncanakan. Teknik ini bekerja dengan baik ketika ada sejumlah proyek yang setipe maupun
sama perkembangannya, jika tidak dalam detilnya. Pembangunan jalan akan menjadi contoh
terbaik dalam hal ini.
Analogi perkiraan dapat dipercaya ketika aktivitas sebelumnya sama pada kenyataan dan
bukan hanya dalam penampilan, dan orang-orang yang mempersiapkan perkiraan
membutuhkan keahlian. Tetapi untuk proyek pengembangan perangkat lunak, baik dalam
kondisi seperti ini kejujuran akan lebih disukai. Jika perangkat lunak sebelumnya masih sama
dibandingkan dengan penggunaannya, komponen dan kodenya akan langsung digunakan
kembali dalam proyek yang akan datang. Akurasi jadwal akan berantakan, tetapi peningkatan
ini akan menawarkan biaya tabungan yang cukup dapat dipertimbangkan.
3.5.7 Pengujian Ahli
Yang terakhir dari PMBOK adalah menyarankan “Pengujian Ahli” untuk menggunakan
pertanyaan yang berkelas dalam pengujiannya. PMBOK (PMI 2000) menindaklanjuti
pernyataan tersebut ketika memaparkan bahwa pengujian ahli dibimbing oleh informasi yang
bersejarah dan harus digunakan bila memungkinkan. Sebuah proses yang diperkirakan sulit
dilakukan adalah memperkenalkan risiko kepada proyek (manajemen risiko akan dibahas
pada bagian berikutnya). Bagaimanapun juga, PMBOK tidak dimunculkan untuk asumsi
tersembunyi yang berarti perkiraan dapat menghasilkan sesuatu atau yang lainnya. Apa yang
tidak memungkinkan? Tidak adanya persediaan dalam PMBOK untuk merencanakan proyek
yang tidak memiliki sesuatu yang diperkirakan.

3.5.8 Jadwal Pengembangan

Perkiraan durasi aktivitas digunakan masukan untuk tugas jadwal pengembangan, yang
merupakan langkah terakhir dalam proses manajemen waktu. Pada langkah ini, kebanyakan
“peralatan besar” dalam manajemen proyek telah siap untuk dilakukan, dan jarak yang luas
dari peralatan dan teknik-teknik tersedia untuk perencanaan dan pengoptimalan jadwal
proyek.
Asumsi : Ukuran dari tim proyek tidak memengaruhi proses pengembangan
Brooks (1995) memberikan pendapatnya bahwa ”proyek pemrograman yang besar akan
membuat masalah manajemen yang berkualitas menjadi lemah dann berbeda daripada
proyek yang kecil karena pembagian tenaga kerja, integritas produk perangkat lunak yang
sangat kritis dan sulit secara konsep, namun memungkinkan pencapaian integritas
konseptual” . Tantangan yang paling besar adalah ketika pengembangan perangkat lunak
datang untuk mempertahankan kompleksitasnya dan mendiskusikannya dengan anggota lain
dalam tim. Peningkatan jumlah tim juga meningkatkan jumlah masalah. Itulah yang
sebenarnya terjadi, tetapi apa yang tidak mungkin sebenarnya hanya bagaimana
pengembangan bisa cepat berkembang.
3.6 Manajemen Biaya
Bagian ini meliputi aktivitas utama dalam area manajemen biaya sumber perencanaan dan
perkiraan biaya. Setelah membicarakan sumber perencanaan, kita juga akan membicarakan dua
masalah yang berhubungan dengan manajemen biaya, yaitu dokumentasi perangkat lunak dan
produktifitas pengembang.
Dua tugas manajemen biaya adalah langkah terakhir yang harus diselesaikan dalam rencana
proyek. Keduanya membangun keluaran dari ruang lingkup manajemen dan proses manajemen
waktu.

3.6.1 Perencanaan Sumber Daya

Perencanaan sumber daya pengembangan perangkat lunak menjadi lebih besar dari proses
persetujuan orang-orang dalam beraktivitas. Manajer proyek memutuskan untuk menyetujui
orang terbaik yang memungkinkan bagi setiap tugas. Perencanaan sumber daya digunakan
sebagai hasil dari, dan terjadi langsung setelah pengembangan penjadwalan.
Proses ini tentu membutuhkan waktu agar anggota tim belajar untuk bekerja sama dan untuk
mendalami bagiannya. Setiap proyek sangat unik dan begitupun halnya pada perseorangan
yang membutuhkan waktu untuk menunjukan pengaturan yang terbaik bagi mereka.
Peningkatan yang umum adalah membagi sejumlah peraturan. Dalam wacana ini, sebuah
aturan telah dikhususkan dengan seseorang yang mungkin mengkonsumsikannya selama
proyek pengembangan perangkat lunak, contohnya aristek, pengamat bisnis, pemrograman
dan penguji.
Masalahnya adalah bahwa dengan membuat perbedaan, Anda mengurangi peningkatan
komunikasi antara tim dan Anda dalam menjalankan proses pengembangan model air
terjun.”Beberapa tenaga kerja pada akhirnya ditambahkan pada proyek yang terlambat”.
Pernyataan tersebut adalah slogan terkenal Fred Brooks (1995). Pengembang yang
berpengalaman mengetahui seberapa benar hal ini. Karena perangkat lunak sangat kompleks,
perangkat lunak membutuhkan waktu untuk membutuhkan waktu untuk belajar mengenai
cara untuk menjelajahi seluruh sistem. Latar belakang pendidikan lainnya diperlukan bagi
anggota tim baru, antara lain :
1. Kebutuhab pelanggan,
2. Asumsi proyek,
3. Sistem dan lingkungan TI,
 4. Budaya pelanggan,
5. Hubungan sejarah dengan pelanggan, dan
6. Hubungan
Tanpa adanya pengertian pada hal-hal yang disebutkan, pemborosan biaya dan kesalahan-
kesalahan yang fatal akan terjadi. Solusinya adalah menangani kelanjutan proyek tersebut,
termasuk memotong proyek yang berkelanjutan yang membawa tim pada situasi yang sulit.

3.6.2 Dokumentasi Perangkat Lunak

Dibagian ini kita membahas topik kontroversial dari dokumentasi. Dokumentasi akan muncul
sebagai solusi terbaik untuk topik sebelumnya yang disebutkan di dalam perencanaan sumber
daya. Dokumentasi akan menjadi tempat bagi pengetahuan tim dan tetap menjadi milik tim,
bahkan ketika orang-orang meninggalkannya. Buka tidak mungkin bahwa dokumentasi
memiliki sisi tradisional yang mempunyai andil dalam proses pengembangan perangkat lunak.
Masalah yang mungkin muncul dadlah ketidaksukaan pengembaang pada dokumentasi.
Mereka tidak suka membacanya dan pada umumnya lebih tidak suka menulisnya.Asumsi yang
tersembunyi disini adalah bahwa dokumentasi merupakan cara yang terbaik dan sejalan
dengan proyek perangkat lunak.

3.6.3 Produktifitas Pengembangan

Asumsi : Satu pengembang sama dengan pengembang lainnya
Isu dari produktifitas pengembang juga memengaruhi perencanaan sumber daya. Sumber
daya dapat secara individu dialokasikan pada kegiatan yang membawanya dengan asumsi
bahwa satu pengembang dapat mengganti pengembang lainnya. Harapan satu-satunya
adalah pengembang senior diharapkan dapat lebih produktif dari pengembang juniornya.
Para individu selalu menunjukan kemampuan mereka dalam area yang spesifik seperti
pekerjaan yang lebih teliti atau komunikasi antarmuka. Boehm (1984) membuat rekomendasi
dalam buku terlarisnya, Software Engineering Economics :
1. Bakat teratas yang digunakan dengan lebih baik untuk beberapa orang,
2. Pekerjaan yang sesuai dengan tugas dan keahlian serta motivasi, dan
3. Penyeimbangan tim, orang yang terpilih akan melengkapi dan menjaga
keharmonisasian dengan yang lain.
3.6.4 Perkiraan Pengeluaran
Asumsi : Perkiraan yang akurat dapat diterima dan dapat ditinggalkan
Isu terakhir yang menyangkut ruang lingkup manajemen biaya adalah kekurangan yang
sangat dramatis antara keakuratan perkiraan yang diharapkan dalam manajemen proyek
yang sangat memungkinkan terjadi pada pengembangan perangkat lunak menurut penelitian
industri.

Akurasi Pengembangan Perangkat Lunak

Akurasi Manajemen Proyek
( dari Rapid Ddevelopment, McConnell,
( dari PMBOK edisi 3, PMI, 2004 )
1996 )

30% kebawah sampai 75% kebawah sampai

Konseptual Konsep Produk Awal
50% keatas. 300% keatas

20% kebawah sampai 50% kebawah sampai Definisi produk yang

Persiapan
30% keatas 100% keatas disetujui

15% kebawah sampai 33% kebawah sampai Spesifikasi

Kepastian
20% ke atas 50% keatas Kebutuhan

10% kebawah sampai 20% kebawah sampai Spesifikasi

Kontrol
15% keatas 25% keatas Rancangan Proyek

Kita dapat melihat bahwa pengembangan perangkat lunak merupakan proses yang berjalan
dari penelitian untuk menemukan kebutuhan konsume dan menemukan alat-alat yang
mempunyai kemampuan.

3.7 Manajemen Kualitas

Suatu kepercayaan yang utama dari sebuah perencanaan proyek berlanjut pada cakupan
berikutnya, yaitu waktu dan pembiayaan aktivitas manajemen yang harus kita
pertimbangkan. Selama aktivitas ini, seorang manajer proyek harus menghabiskan waktu
perencanaan dari manajemen kualitas dan strategi manajemen resiko.
3.7.1 Metrik
Menurut PMBOK, dua alat utama yang akan dibuat ketka proses perencanaan kualitas adalah
definisi pengaturan operasional ( atau kualitas metrik) daan perubahan kualitas yang tertera.
Asumsi : Metrik cukup dibutuhkan untuk menilai kualitas perangkat lunak
Dilihat dari segi kinerja, hanya metrik nyata untuk perangkat lunaklah yang jumlah dan
dampaknya ada dalam perangkat lunak. Metrik lain yang didiskusikan dalam literatur adalah
metrik untuk proses, bukan metrik untuk produk tersebut, yaitu peningkatan yang sedang
direncanakan, permintaan pada perubahan setiap waktu, usaha yang direncanakan,, dan
sebagainya. Disamping itu Metrik masih merupakan alat yang berharga, bahkan jika sebuah
aplikasi bekerja dengan baik, pengguna akan tetap memprotes jika mereka menemukan cara
kerja yang masih lamban. Oleh karena itu, pengawasan respon dari aplikasi yang masih
dibawah standar(penampilannya), dan jumlah pengguna yang dapat menerima
penampilannya dan dapat menanganinya merupakan halyang sangat penting.
Metrik kedua mencakup penambahan kegunaan, penambah produktivitas , dan keuntungan
bisnis. Metrik tersebut sangat bermanfaat, tetapi mereka juga sangat sulit untuk dipastikan
ketika perangkat lunak dikembangkan.

3.7.2 Daftar Periksa

Alat lainnya, yaitu sekumpulan daftar periksa kualitas, justru menjadi masalah. Menurut
PMBOK, daftar periksa merupakan “alat yang tertata, biasanya digunakan secara khusus
untuk membuktikan bahwa langkah yang harus digunakan secara khusus untuk membuktikan
bahwa langkah yang diharuskan telah siap ditampilkan dan digunakan untuk memastikan
konsituensi dalam tugas yang dilakukannya (PMI,2000)”. Jelas bahwa pengembangan
perangkat lunak meminta proses jaminan kualitas pada semua hal yang disarankan dalam
PMBOK.

3.8 Manajemen Risiko

PMBOK menyarankan empat teknik untuk menghadapi proyek yang berisiko, yaitu :
1. Menerima Risiko
Memindahkan batas waktu dan atau menyimpan yang dapat berguna untuk
mengurangi dampak buruk jika resiko terjadi.
 2. Pemindahan Risiko
Mengetahui tanggung jawab terhadap risiko pihak lain
3. Penolakan Risiko
Menemukan proses alternatif yang bukan termasuk risiko
4. Menghadapi Risiko
Menemukan jalan keluar untuk membuat risiko dapat terkendali atau mengurangi
akibat yang terjadi karena risiko tersebut.

3.8.1 Menerima Risiko

Manajemen risiko terhadap risiko yang telah diketahui dilakukan dengan dasar bahwa risiko
dapat diprediksi. Risiko sejenis yang didaftarkan pada proyek pengembangan perangkat lunak
meliputi :
1. Kebutuhan menjadi tidak lengkap dan ruang lingkup proyek akan berubah.
2. Peralatan dan komponen pihak ketiga tidak bekerja sesuai dengan yang diharapkan.
3. Pengembangan mengurangi kemampuan dan keahliannya.
4. Kemunculan masalah, pengunduran diri, dan proyek lainnya akan mengurangi jumlah
dari orang-orang yang dapat bekerja pada proyek.
Risiko yang sering kita temukan dalam penilitian adalah menemukan bahwa apa yang terjadi
lebih rumit daripada apa yang ada dalam pikiran anda, dan resiko tersebut tidak dapat
dipastikan. Anda tidak dapat memprediksi bagaimana rumitnya masalah atau solusi apa yang
mungkin muncul.

3.8.2 Pemindahan Risiko

Penerimaan risiko hanya satu-satunya cara dalam PMBOK untuk merespon rencana terhadap
risiko. Untuk organisasi lain, pemindahan risiko merupakan cara terakhir, dengan catatan
bahwa tanggung jawab harus tetap diberikan kepada seseorang. Pemindahan ini dapat
diputuskan oleh pelanggan, kontraktor, atau bagian kontraktor dengan penerima yang masih
harus menanggung risiko tersebut.
3.8.3 Penolakan Risiko
Untuk ulasan sebelumnya, risiko seperti itu sangat umum dan tidak dapat dimungkiri untuk
proyek pengembangan perangkat lunak. Sebagai contoh, beberapa kontrak sesuai untuk klien
dalam membuat perubahan, tetapi situasi seperti ini jarang berakhir dengan baik. Anda
mungkin dapat mencari pengembang yang mengetahui segala hal yang berhubungan pada
proyek Anda, tetapi Anda akan sulit untuk menemukannya.

3.8.4 Menghadapi Risiko

Saran Terakhir dari PMBOK adalah penerimaan yang “terlihat mengurangi kemungkinan
dan/atau konsekuensi dalam menghadapi risiko dengan menerimanya” (PMI, 2000). Dengan
menjelaskan bahwa proyek perangkat lunak tergantung pada pembagian atas risiko yang sama,
kita dapat menemukan respons penerimaan proyek pengembangan perangkat lunak pada
umumnya.
Model manajemen risiko dalam PMBOK sangat lengkap dan berdaya guna, dan terlihat bahwa
tidak ada asumsi khusus yang tersembunyi yang mencegahnya untuk digunakan dalam proyek
perangkat lunak. Oleh karena itu, proyek perangkkat lunak mempunyai karakter khusus yang
membuatnya sulit untuk ditambahkan sesuatu.

3.9 Rangkuman
Dalam bab ini kita telah mempelajari tahap-tahap untukmengerti mengapa proyek perangkat
lunak sering gagal. Analisis tentang manajemen proyek mempunyai sepuluh asumsi
tersembunyi yang tidak muncul apabila tidak terbaca dalam proyek pengembangan perangkat
lunak, yaitu :
1. Definisi lingkup dapat dilakukan sebelum proyek dimulai
2. Ruang lingkup dapat dijelaskan secara utuh
3. Pengembangan perangkat lunak terdiri dari aktivitas-aktivitas yang jelas berbeda
4. Aktivitas-aktivitas pengembangan perangkat lunak dapat diurutkan
5. Selalu ada cara untuk menghasilkan perkiraan yang bermanfaat
6. Ukuran dari tim proyek untuk memengaruhi proses pengembangan
7. Anggota tim dapat dialokasikan secara individual pada aktivitas
8. Satu pengembang sama dengan pengembang lainnya
9. Perkiraan yang akurat dapat diterima dan dapat ditingkatkan
10. Metrik cukup dibutuhkan untuk menilai kualitas perangkat lunak